i'm getting bug reports, that people have manage to get a upgrade 99 times. in the first 5 min. i've personally tested and retested these dialog functions. i don't see how they can do it that fast. there no wait times and the price for the upgrade goes up each time. i could maybe see one or 2 but 99?
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.
its a upgrade button that spends points for armor upgrade. its not suppose to deactivate and it cant easy check for too many upgrades.the first 3-4 lines of code calculates and raises the price. the next lines of code sets the player's variable data and gives the upgrade.
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?
short hand code.
event:dialog button is used
variable: x placeholder
variable: price
condition: if dialog button=x
action:
set x placeholder*globalvariableupgrade[triggeringplayer]
set x* 1.5
if x<= points[triggeringplayer]
then modify globalvvariableupgrade[triggeringplayer]+1
give upgrades and adjust more variables.
else
you dont have enough.
its the 4th line of code. and ya with units u can check overstock but this i don't think you can without doing something massively elaborate?
on a positive note, i got the player name and reported him for cheating. at most players can get 50, i got 80 once trying very hard at the end. but he got 99 in the beginning.
on a positive note, i got the player name and reported him for cheating. at most players can get 50, i got 80 once trying very hard at the end. but he got 99 in the beginning.
If this is caused by some bug in the map, this is probably not the best course of action.
Try to test those lag issues with some debug messages to find out, what exactly happens, when players click those buttons while lagging.
I had this problem. Dialogs are local to the client. Notice you can manipulate them in replays. You need to make them require some non-local check to run, such as the value of a variable if you want their use to be synced.
@vexal: wouldn't the price of the upgrade be the non-local check? before trigger runs it checks global variable for the proper amount?
@kueken: i've tried to spam click it when i have lag and when other people have lag and when battle net lags. i get maybe 1-2 false upgrades as i break my mouse buttons.
Do you use a trigger to change the price of the upgrade? Why don't you have an effect of the ugprade itself be to modify its own price? That's what I generally do.
Or are you using trigger-based currency? Where is your condition? If the price is modified inside the trigger that runs when you click, and it's executed multiple times in a single timestep, the condition will not see the modified price.
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
@vexal: i'm a programmer at college. i'm new to data editor but the triggers and the galaxy code i understand a lot of. i'm still trying to figure out the data editor. please, by all means submit a tutorial on how to do it, i would gladly change it.
@thealmaity: took me a second but i think i understand. its kinda elaborate especial with 20 buttons. i will keep what u say in mind for future projects.
Soul, the clicking problem can be fixed in the data editor. Under the requirements for the upgrade, make it so that it's unavailable while queued. Also, give the upgrades like a 0.5 or 1 second research time. Not enough to burden the players, but enough to make sure they can't instant-queue during lag.
Alternatively, you could make the upgrades dummy abilities that add an integer to a variable each time they are clicked. Then you can check the variable in a trigger and if it's greater than 1, set the value of it to 1 and execute.
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.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
i'm getting bug reports, that people have manage to get a upgrade 99 times. in the first 5 min. i've personally tested and retested these dialog functions. i don't see how they can do it that fast. there no wait times and the price for the upgrade goes up each time. i could maybe see one or 2 but 99?
A macro autoclicker maybe? Try setting wait time to be 0.5 - 1 second and see whether there still are any such bug reports.
that may be few and far between but i will a 1 second delay
probably a programmable mouse i have one you can set the delay to 0.001 is the lowest
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.
its a upgrade button that spends points for armor upgrade. its not suppose to deactivate and it cant easy check for too many upgrades.the first 3-4 lines of code calculates and raises the price. the next lines of code sets the player's variable data and gives the upgrade.
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?
short hand code.
event:dialog button is used variable: x placeholder variable: price condition: if dialog button=x action: set x placeholder*globalvariableupgrade[triggeringplayer] set x* 1.5 if x<= points[triggeringplayer] then modify globalvvariableupgrade[triggeringplayer]+1 give upgrades and adjust more variables. else you dont have enough.
its the 4th line of code. and ya with units u can check overstock but this i don't think you can without doing something massively elaborate?
on a positive note, i got the player name and reported him for cheating. at most players can get 50, i got 80 once trying very hard at the end. but he got 99 in the beginning.
If this is caused by some bug in the map, this is probably not the best course of action.
Try to test those lag issues with some debug messages to find out, what exactly happens, when players click those buttons while lagging.
@SoulTaker916: Go
I had this problem. Dialogs are local to the client. Notice you can manipulate them in replays. You need to make them require some non-local check to run, such as the value of a variable if you want their use to be synced.
@vexal: wouldn't the price of the upgrade be the non-local check? before trigger runs it checks global variable for the proper amount?
@kueken: i've tried to spam click it when i have lag and when other people have lag and when battle net lags. i get maybe 1-2 false upgrades as i break my mouse buttons.
@SoulTaker916: Go
Do you use a trigger to change the price of the upgrade? Why don't you have an effect of the ugprade itself be to modify its own price? That's what I generally do.
Or are you using trigger-based currency? Where is your condition? If the price is modified inside the trigger that runs when you click, and it's executed multiple times in a single timestep, the condition will not see the modified price.
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
@vexal: i'm a programmer at college. i'm new to data editor but the triggers and the galaxy code i understand a lot of. i'm still trying to figure out the data editor. please, by all means submit a tutorial on how to do it, i would gladly change it.
@thealmaity: took me a second but i think i understand. its kinda elaborate especial with 20 buttons. i will keep what u say in mind for future projects.
Soul, the clicking problem can be fixed in the data editor. Under the requirements for the upgrade, make it so that it's unavailable while queued. Also, give the upgrades like a 0.5 or 1 second research time. Not enough to burden the players, but enough to make sure they can't instant-queue during lag.
Alternatively, you could make the upgrades dummy abilities that add an integer to a variable each time they are clicked. Then you can check the variable in a trigger and if it's greater than 1, set the value of it to 1 and execute.
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.