Why not prevent the unit being created in the first place? Count how many of the unit the type the player owns and only make another if less than 1. If you want to limit training of a unit to only 1 then use a requirement on the train ability, see WoL Mothership for details.
It is a unit that is spawned after the player chooses a Starting Hero, problem is if the player clicks fast enough or lags enough can manage to get more then one. Just trying to find some way to fix this issue :/
It is a unit that is spawned after the player chooses a Starting Hero, problem is if the player clicks fast enough or lags enough can manage to get more then one. Just trying to find some way to fix this issue :/
Create a global boolean array with size 16 (or max player count) and initial value false. When the player "chooses a Starting Hero", set the array at the player's number index to true. All hero selection triggers check the value of the array at the player's number index and will only run if it is false. Any repick trigger removes all the player's stuff and then sets the variable to false again to allow hero selection to work for the player again. If the player "clicks fast enough" then only the trigger will run the first time as after that the boolean array at the player's number index will be true and so subsequent selections are discarded.
If you are using a custom dialog system for hero selection that is hidden the instance a selection is made then you can achieve something similar to above simply by testing if the dialog is visible to the triggering player. Dialog events can still fire on hidden dialogs but such events can also be easily filtered out with a condition that tests if the triggering dialog is visible to the triggering player. After a hero selection is made and the dialog hidden, any subsequent event firing caused when the player "clicks fast enough or lags" will be discarded.
Instead of the boolean array, the system that keeps track of player selection could be used. If something has already been selected (not default values in the system) then you can ignore subsequent selection attempts. For example if the player has a hero unit, then you can check if the array referencing his hero unit has already been set and if so do not make any more units for him as he has already chosen.
I'm not sure that this solution will work well. The problem here is that when the lag happend, both event, both triggers will run at the same time and both will check if the variable is false or true, whatever the way it is set to prevent extra unit creation and both triggers will create the unit.
Another way could be adding the player to a player group variable and have another trigger that during the selection it checks if the player group variable is empty, if not look which player has choosed. This way you make sure even during a lag, the player will be added to the player group variable (the players that are choosing) and it will cycle.
Such system also allows hero picking for many player at the same time that can prevent 2 or more players picking the same because of lagging ui. Both players would get added at the same time in the player group in some order, but will not get both the same hero as the first one will get it, the other will be discarded as already picked.
I'm not sure that this solution will work well. The problem here is that when the lag happend, both event, both triggers will run at the same time and both will check if the variable is false or true, whatever the way it is set to prevent extra unit creation and both triggers will create the unit.
Only 1 trigger will run at any given time. Although Galaxy has the concept of "threads" it still uses a non pre-emptive scheduler with 1 execution unit. As such there is a very strict and predictable ordering to stuff being executed. Yes the trigger may fire twice on the same frame, but the second time can see the results of the first time it run. Hence why one can test if the units were created and not create any more and it will work.
Another way could be adding the player to a player group variable and have another trigger that during the selection it checks if the player group variable is empty, if not look which player has choosed. This way you make sure even during a lag, the player will be added to the player group variable (the players that are choosing) and it will cycle.
This is no different from using a per player boolean array...
Such system also allows hero picking for many player at the same time that can prevent 2 or more players picking the same because of lagging ui.
This can be done with a per selection boolean array. If it is true then the hero cannot be picked and any orders to pick that hero, eg as the result of lag, can be discarded.
Both players would get added at the same time in the player group in some order, but will not get both the same hero as the first one will get it, the other will be discarded as already picked.
Then one player ends up with no hero... Far better to use a boolean array.
Couldn't I do some sort of hard cap on how many of the unit can be on the map. And since the trigger thats run after they choose a hero creates the hero they choose it should in theory return back an error if it trys to fire off a 2nd or 3rd time?
Something like condition if unit = hero1 >1 return false?
I swear I had a setup in the past that worked something like that I just can't remember how I did it.
Couldn't I do some sort of hard cap on how many of the unit can be on the map. And since the trigger thats run after they choose a hero creates the hero they choose it should in theory return back an error if it trys to fire off a 2nd or 3rd time?
Triggers cannot process errors well, only throw them to be logged. Rather use a trigger condition to stop the trigger firing the actions if it has already done so and given the player a unit.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
What I am looking to achieve is a way to fix more units being spawned then intended when the players choose a unit.
Wanted to set it up something like if (triggering player) has > 1 of specific unit, remove/kill all of that unit type past 1.
Would any1 be able to point me in the right direction? Thanks in advance!
Why not prevent the unit being created in the first place? Count how many of the unit the type the player owns and only make another if less than 1. If you want to limit training of a unit to only 1 then use a requirement on the train ability, see WoL Mothership for details.
It is a unit that is spawned after the player chooses a Starting Hero, problem is if the player clicks fast enough or lags enough can manage to get more then one. Just trying to find some way to fix this issue :/
Create a global boolean array with size 16 (or max player count) and initial value false. When the player "chooses a Starting Hero", set the array at the player's number index to true. All hero selection triggers check the value of the array at the player's number index and will only run if it is false. Any repick trigger removes all the player's stuff and then sets the variable to false again to allow hero selection to work for the player again. If the player "clicks fast enough" then only the trigger will run the first time as after that the boolean array at the player's number index will be true and so subsequent selections are discarded.
If you are using a custom dialog system for hero selection that is hidden the instance a selection is made then you can achieve something similar to above simply by testing if the dialog is visible to the triggering player. Dialog events can still fire on hidden dialogs but such events can also be easily filtered out with a condition that tests if the triggering dialog is visible to the triggering player. After a hero selection is made and the dialog hidden, any subsequent event firing caused when the player "clicks fast enough or lags" will be discarded.
Instead of the boolean array, the system that keeps track of player selection could be used. If something has already been selected (not default values in the system) then you can ignore subsequent selection attempts. For example if the player has a hero unit, then you can check if the array referencing his hero unit has already been set and if so do not make any more units for him as he has already chosen.
I'm not sure that this solution will work well. The problem here is that when the lag happend, both event, both triggers will run at the same time and both will check if the variable is false or true, whatever the way it is set to prevent extra unit creation and both triggers will create the unit.
Another way could be adding the player to a player group variable and have another trigger that during the selection it checks if the player group variable is empty, if not look which player has choosed. This way you make sure even during a lag, the player will be added to the player group variable (the players that are choosing) and it will cycle.
Such system also allows hero picking for many player at the same time that can prevent 2 or more players picking the same because of lagging ui. Both players would get added at the same time in the player group in some order, but will not get both the same hero as the first one will get it, the other will be discarded as already picked.
Working on projects:
Only 1 trigger will run at any given time. Although Galaxy has the concept of "threads" it still uses a non pre-emptive scheduler with 1 execution unit. As such there is a very strict and predictable ordering to stuff being executed. Yes the trigger may fire twice on the same frame, but the second time can see the results of the first time it run. Hence why one can test if the units were created and not create any more and it will work.
This is no different from using a per player boolean array...
This can be done with a per selection boolean array. If it is true then the hero cannot be picked and any orders to pick that hero, eg as the result of lag, can be discarded.
Then one player ends up with no hero... Far better to use a boolean array.
Couldn't I do some sort of hard cap on how many of the unit can be on the map. And since the trigger thats run after they choose a hero creates the hero they choose it should in theory return back an error if it trys to fire off a 2nd or 3rd time?
Something like condition if unit = hero1 >1 return false?
I swear I had a setup in the past that worked something like that I just can't remember how I did it.
And by the way thanks for throwing ideas out
Triggers cannot process errors well, only throw them to be logged. Rather use a trigger condition to stop the trigger firing the actions if it has already done so and given the player a unit.