Battle.net lag owns even triggers

[Mille25]

just found another serious problem while testing some dialogs in multiplayer.

because of the bnet lag it seems to be possible to make triggers work as they shoudnt work.

a very easy example for you:

i want that a player can click a button 5 times, after that the button gets disabled. disabled items are not clickable any more.

trigger:

• click
  • Events
    • Dialog - Any Dialog Item is Clicked by Player Any Player
  • Local Variables
  • Conditions
    • (Used dialog item) == btn
  • Actions
    • Variable - Modify clicks: - 1
    • General - If (Conditions) then do (Actions) else do (Actions)
      • If
        • clicks == 0
      • Then
        • Dialog - Disable btn for (All players)
      • Else
    • Dialog - Set lbl text to (Text(clicks)) for (All players)

everytime a player clicks the button, the variable will be reduced by 1. if the variable is 0 the button will be disabled. so in theory its not possible to click the button more then 5 times.

if you test this in singleplayer all works fine. it doenst matter how fast you click, the button will only be clickable 5 times.

but see whats possible in multiplayer:

we just clicked the button 7 times, what should not be possible.


so what can we do?

rewirting the trigger helped me to solve the problem:

• click
  • Events
    • Dialog - Any Dialog Item is Clicked by Player Any Player
  • Local Variables
  • Conditions
    • (Used dialog item) == btn
  • Actions
    • General - If (Conditions) then do (Actions) else do (Actions)
      • If
        • clicks > 0
      • Then
        • Variable - Modify clicks: - 1
      • Else
        • Dialog - Disable btn for (All players)
    • Dialog - Set lbl text to (Text(clicks)) for (All players)

like this it seems to be good in multiplayer, too.

discuss. :O

 

[EnderA]

Good catch. Reminds me of the differences between all the spell casting events in WC3.

 

[Dr Super Good]

WC3 had this as well.

You could display dialogs locally for players and it would still register button click events. Using a packet editor script you could infact even register button clicks in dialogs which NEVER are displayed to any user. Sc2 probably also has this same problem whereby in lag, the click order is sent multiple times and could be sent infinitly via a script to modify your outgoing packets. Ofcourse such a script may result in a ban but also might not.

The end conclusion is your buttons should only ever do something when clicked if they are meant to be able to be clicked. For example you turn on the click event handlers only when displaying an interface to a user.

As for handeling lag.... You simply add code that catches excess clicks and discards them. In this case a condition that only runs the code while it is greater than 0.

WC3 also had the same lag issue with orders, where it would be possible to unload a unit more than once from a transport despite in singleplayer the orders and unloading happening instantly.

 

[Mille25]

i think the reason why the first one can be clicked 7 times is the following:

if you click the button very often in 150ms (or whatever the bnet responsetime is) the clicks will get increased for every click, but even if they get five and the button gets disabled its already to late because of the 150ms.

for example if you got 1 click left, and make 2 clicks in 150ms, the trigger will run 2 times and modify the variable 2 times. but the button will disabled after a delay of 150ms, when its already to late.

thats my explanation for this. the second trigger checks the variable itself so its save.

 

[Dr Super Good]

No, its cause the event runs when a button click order is recieved. Due to the lag you can send out multiple button click orders before the first one reaches everyone and takes effect. Further more you could via a hack send out button click orders even if the button is not present as it does not validate if the player can actually click a button but only if a button appears to have been clicked.

This is the truth.