Actually, the above trigger idea is a much simpler and better version of mine xD As he said, just make your main trigger increase a variable by 1, and each second check that variable and if its greater than 0 increase teh upgrade level by 1 and reset the variable.
Anything to do with dialogs can be spam clicked for increased (but "illegal") effectiveness because bnet has a minimum latency of 125 ms, variables won't get updated before those 125 ms so you can run the trigger over and over again during that time period without anything changing because triggers go over bnet and aren't handled locally afaik
they are managing to do it before the price raise... i could i guess do it in the first line of code, but will it really make a difference?
I said above that you need TWO triggers, the one that fixes it runs shortly AFTER the one that got spam clicked.
With units you have surplus units, but the important part is that i checked a NUMBER in a variable (number of units in unit group), for upgrades you can use an integer. Make the first line of code in your trigger (integer + 1), and the last line "Run trigger (The one that makes sure it went right)"
Second trigger: "If (integer) > 1" reduce the upgrade level (you can use a global variable that stores the upgrade level, make sure to remove the spam clicks from it, and then "Set upgrade level of (ur upgrade) to (integer) for player (you'd need another global variable)"
Also, always make sure to set the integer to 0 in the fixing trigger.
Oh, and plz answer Vexals latest questions :) Maybe there's another way we can help or i got it wrong
This happens with all dialogs (blame bnet latency), you'll need a trigger that somehow manages to monitor the effects of the "dialog item is used" trigger and notice if it runs too many times, and then get rid of the surplus things.
For example:
If a dialog creates a unit, spam clicking will run the trigger multiple times (even if the trigger is supposed to be turned off after the first click)
Use a global variable of unit group and add created units to it in the main trigger, then 0.3 seconds later run a second trigger. If number of units in (unit group variable) > greater than 1, pick each integer from 2 to (number of units in (unit group variable)) and do kill (unit (picked integer) of (unit group variable))
Do something like that for whatever your dialogs do.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Actually, the above trigger idea is a much simpler and better version of mine xD As he said, just make your main trigger increase a variable by 1, and each second check that variable and if its greater than 0 increase teh upgrade level by 1 and reset the variable.
Anything to do with dialogs can be spam clicked for increased (but "illegal") effectiveness because bnet has a minimum latency of 125 ms, variables won't get updated before those 125 ms so you can run the trigger over and over again during that time period without anything changing because triggers go over bnet and aren't handled locally afaik
I said above that you need TWO triggers, the one that fixes it runs shortly AFTER the one that got spam clicked.
With units you have surplus units, but the important part is that i checked a NUMBER in a variable (number of units in unit group), for upgrades you can use an integer. Make the first line of code in your trigger (integer + 1), and the last line "Run trigger (The one that makes sure it went right)"
Second trigger: "If (integer) > 1" reduce the upgrade level (you can use a global variable that stores the upgrade level, make sure to remove the spam clicks from it, and then "Set upgrade level of (ur upgrade) to (integer) for player (you'd need another global variable)"
Also, always make sure to set the integer to 0 in the fixing trigger.
Oh, and plz answer Vexals latest questions :) Maybe there's another way we can help or i got it wrong
OR you lag an click during the lag.
This happens with all dialogs (blame bnet latency), you'll need a trigger that somehow manages to monitor the effects of the "dialog item is used" trigger and notice if it runs too many times, and then get rid of the surplus things.
For example:
If a dialog creates a unit, spam clicking will run the trigger multiple times (even if the trigger is supposed to be turned off after the first click)
Use a global variable of unit group and add created units to it in the main trigger, then 0.3 seconds later run a second trigger. If number of units in (unit group variable) > greater than 1, pick each integer from 2 to (number of units in (unit group variable)) and do kill (unit (picked integer) of (unit group variable))
Do something like that for whatever your dialogs do.