Local EUDs Made Multiplayer Merry April Fools Everyone
Intro
As many of you are aware, there are some very useful EUDs that you can't use in multiplayer without causing a desync. Lethal and I found a way around this a few months ago but never bothered to share our knowledge officially on the SEN forums.

How It Works:
In order to understand how this works, you first must understand why local EUDs cause desyncs. Each client connected together in a Starcraft game simulates what should be happening in the game, based on Starcraft's "physics" (mechanics) and the inputs of every other player. When these simulations don't match up it results in a desync and the computers disconnect. Local EUDs (like detecting keyboard presses and screen position) themselves don't cause desyncs, but rather the differences they make (desyncing actions).

If you have a trigger like this:
CONDITIONS:

• Keystroke "L" is pressed (EUD shorthand)

ACTIONS:

• Create 1 Zergling at Location 1 for Player 1

It creates a zergling for the player that presses "L" and not for the others, causing a desync. Technically if every player pressed "L" at the exact same time, the zergling would be created and there would be no desync. Local actions also don't cause desyncs (display text, center view, etc), meaning you can have pressing the key "K" display the message "You pressed K!" just fine without desyncs.

Unlike most units, when the action "Kill X Zerg Egg for Player Y" occurs it sends a cancel order for the egg rather than going through the normal kill script. Like most of the mechanics we abuse, this is because of a bit of laziness on Blizzards part, as it keeps them from having to do some messy clean up with the Zerg Egg states. Consequently, when a Zerg Egg 'dies' (via trigger actions) for a client, instead of causing a desync, the other clients accept the death as a cancel order input and update themselves by killing the Zerg Egg in their runtimes as well- SO LONG AS THE ZERG EGG BELONGED TO THE PLAYER THAT HAD THE ZERG EGG DIE FOR THEIR CLIENT (this part is important, otherwise it'll cause a desync like always).

Now, we can abuse this by using Zerg Egg deaths as indicators of local EUD events. Example:
TRIGGER 1:
CONDITIONS:

• Keystroke "L" is pressed (EUD shorthand)

ACTIONS:

• Kill 1 Zerg Egg for Player X at CurrentEggLocation
  
• Preserve Trigger

TRIGGER 2:
CONDITIONS:

• Player X Brings At most 0 Zerg Egg at CurrentEggLocation

ACTIONS:

• Display Text ("HEY EVERYONE, PLAYER X PRESSED THE L KEY")
  
• Move 1 Zerg Egg from EggStorageLocation to CurrentEggLocation
  
• Any other actions you want, like casting a spell
  
• Preserve Trigger

To restate, the other clients accept the Zerg Egg Kill command as a cancel input, rather than a disparity thats cause for desync. This in turn sates the condition for trigger 2, and everyone sees the message "HEY EVERYONE, PLAYER X PRESSED THE L KEY" displayed to their screen.

There are a few problems though. For one, Zerg Eggs can't be detected by the Bring condition, so you have to detect its absence in more round about ways (I just used bring in the example for ease of comprehension) like continually moving a Reaver (arbitrary ground unit) where the egg is and if the Reaver finally exists where the egg should've been, then move the Reaver away and activate the Actions you wanted.

Secondly, if any player presses "L" the Zerg Egg will be killed for Player X, and if you were paying attention, if any player other than Player X kills Player X's Zerg Egg locally, it will cause a desync. This can be remedied in a couple ways- either each Player has a different local EUD triggers (IE P1 presses L and P2 pressed K) or you have another local EUD condition to delineate between the players so that its impossible for them to activate other's EUD events. In my test maps, I used the EUD condition for, in essence, "Is Player 1", "Is Player 2" to delineate, as seen in the following example:

Example
In the following example vespene gas acts as a health potion counter. If player 1 or 2 press Q, it subtracts a vespene gas and they are healed. No desyncs occur, despite using local EUDs.


PROS:

• Any Local EUD can be used as a condition in Multiplayer maps without causing a desync
  

CONS:

• Like all maps that use EUDs, patches may ruin map
  
• Every player needs their own storage of preplaced Zerg Eggs, which can really add up
  
• You can only used the local EUD event as many times as you have stored eggs
  
• Each type of local EUD needs a separate "CurrentEggLocation"
  
• If you want to pass something like screen position (which has a range of values, not just ON/OFF), you'll have to have multiple Egg pools to kill from to act as a binary sequence
  

I'll get my test map in a presentable state real quick and attach it.

This is absolutely fantastic. You could kill the egg for "Current Player" to distinguish players, correct? For example, if everyone has an egg and Player 2 presses the L key, only his egg will die and it will be perfectly legal, and we would know that Player 2 pressed the key because he no longer has an egg.

Something like:

Description:	Press L Key
Players:	All Players
Conditions:	(Current Player presses L Key)
Actions:	Kill Egg for Current Player

Description:	Player 1 Pressed L Key
Players:	Player 8
Conditions:	Player 1 commands exactly 0 Egg
Actions:	(Action to execute)

Description:	Player 2 Pressed L Key
Players:	Player 8
Conditions:	Player 2 commands exactly 0 Egg
Actions:	(Action to execute)

Edit: Wait, that wouldn't work; it would kill all eggs for one client.

Quote from Roy

This is absolutely fantastic. You could kill the egg for "Current Player" to distinguish players, correct? For example, if everyone has an egg and Player 2 presses the L key, only his egg will die and it will be perfectly legal, and we would know that Player 2 pressed the key because he no longer has an egg.

No, this is where it gets tricky. Current Player refers the the player the triggers are being run for, not the player that the client is playing.

If you had a trigger that used current player and Player 1 and Player 2 owned the trigger, it would be identical to there being 2 triggers, one for each player with Player 1 and Player 2 substituted in place of Current Player. That means that if any player presses the L key, it activates the trigger for each player that owns the trigger, and consequently kills the egg for every player, causing a desync.

Thats where the last bit comes into play.

EDIT: And it seems you've realized your error already

Computer with lots of larva and AI building units that never finish, then give eggs?

Thinking about it though, you could put all your "Current Player" triggers nested in a switch that contains the player delineator.

Example:

TRIGGER 1:
PLAYERS: Player 1
CONDITIONS:
Client is Player 1 (eud shorthand)
ACTIONS:
Set Switch 1

TRIGGER 2:
PLAYERS: Player 2
CONDITIONS:
Client is Player 2 (eud shorthand)
ACTIONS:
Set Switch 1

TRIGGER 3:
PLAYERS: Player 1, Player 2
CONDITIONS:
Switch 1 is Set
L is pressed
ACTIONS:
Kill Egg for Current Player

TRIGGER 4:
PLAYERS: Player 1, Player 2
CONDITIONS:
Switch 1 is Set
Current Player Commands 0 Zerg Eggs
ACTIONS:
Actions!

TRIGGER 5:
PLAYERS: Player 1, Player 2
CONDITIONS:
Switch 1 is Set
ACTIONS:
Clear Switch 1

Quote from O)FaRTy1billion

Computer with lots of larva and AI building units that never finish, then give eggs?

I haven't tried, is there a good script for that? I'm not very familiar with Campaign Scripts, but theoretically that might work.

Quote from Kaias

Quote from O)FaRTy1billion

Computer with lots of larva and AI building units that never finish, then give eggs?

I haven't tried, is there a good script for that? I'm not very familiar with Campaign Scripts, but theoretically that might work.

Any of them?

giveeggs.scm (38.67 kb) -- 9 hits

I just did drones because I figured they'd build a lot of them. I'm not really sure how the AIs work, so other units might work better ...

Nice work!

I've scanned the abyss for something like this for some time with absolutely no good results

Don't have time to fuss with math atm, but remember that you have a second variable to manipulate here, Time!!! Have the host that reads the local EUD wait till the cycle of the desired value pops around before you send anything (if you can tolerate the extra cycles with no loss of functionality, that is).


edit:
Probationary math: range for send-able integers = 2^eggs * 2^(tolerable cycles-1)

edit2:
Almost forgot! these may or may not be able to increase your networking efficiency Cyclical Countoffs (possibly less eggs)

Quote from O)FaRTy1billion

Quote from Kaias

Quote from O)FaRTy1billion

Computer with lots of larva and AI building units that never finish, then give eggs?

I haven't tried, is there a good script for that? I'm not very familiar with Campaign Scripts, but theoretically that might work.

Any of them?

giveeggs.scm (38.67 kb) -- 9 hits

Wow, that was a lot better than I expected. Its pretty fast too.

Though, if you're passing a Screen Position and Cursor Position coordinates combination, for example, the Egg demand could get really high. There's actually a (mostly concept) map that would be amazing if it used this that Lethal (primarily) and I made. It uses screen position and mouse position pairs to figure out where your mouse is on the map, which, without a regenerating Egg supply, couldn't feasibly use this on. I'll ask Lethal about posting the map when he gets online.

...Do the eggs have to be created by a Larva morphing, or do other ways work too? (Like a preplaced egg, or one summoned by a modified AI script.)

Regardless this is amazing. Wheeeeeeeeeeeeee!

Wow I am definitely going to be using this in my RPG, this is great news!

Quote from jjf28

Don't have time to fuss with math atm, but remember that you have a second variable to manipulate here, Time!!! Have the host that reads the local EUD wait till the cycle of the desired value pops around before you send anything (if you can tolerate the extra cycles with no loss of functionality, that is).


edit:
Probationary math: range for send-able integers = 2^eggs * 2^(tolerable cycles-1)

edit2:
Almost forgot! these may or may not be able to increase your networking efficiency Cyclical Countoffs (possibly less eggs)

This is true. Location, time and number of Eggs can all be used for transferring information.

Cyclical Countoffs, very interesting.

ok so:

Quote

[11:56 pm] Kaias -- At this point I feel compelled to tell you Local EUDs Made Multiplayer is my April Fools Prank

Slight disappointment aside: make note that Alliance Status is not an immediate desync contrary to http://farty1billion.dyndns.org/euddb/?pg=ref&a=actions, this is one of my lines of research put on hold, seeing as how alliance status actually does something, it may be worth looking into


yes reporters, it happens to be past 12:00am SEN time ;p and I'm putting fourth something that could possibly make this thread useful.

Quote from jjf28

Slight disappointment aside: make note that Alliance Status is not an immediate desync contrary to http://farty1billion.dyndns.org/euddb/?pg=ref&a=actions, this is one of my lines of research put on hold, seeing as how alliance status actually does something, it may be worth looking into

I think there's supposed to be a note for that stating that it only desyncs when the differing alliances cause the state of the game to desync (e.g., combat auto-attack).

I actually had a lot of fun building a system for this, and it was a great excuse to take a break from EUDGen.

Flawless 4-Player WASD map using the egg system (including chat/menu checks):

It was an April Fools Prank. Sorry about getting anyone's hopes up. If there is some action out there which the other clients simply accept like I suggested then this concept would in fact work. But until we find such a thing its just a dream. Until next year!

Quote from Roy

Quote from jjf28

Slight disappointment aside: make note that Alliance Status is not an immediate desync contrary to http://farty1billion.dyndns.org/euddb/?pg=ref&a=actions, this is one of my lines of research put on hold, seeing as how alliance status actually does something, it may be worth looking into

I think there's supposed to be a note for that stating that it only desyncs when the differing alliances cause the state of the game to desync (e.g., combat auto-attack).

I actually had a lot of fun building a system for this, and it was a great excuse to take a break from EUDGen.

Flawless 4-Player WASD map using the egg system (including chat/menu checks):

That's pretty awesome. I see you did two events, press and release, per key which is a lot smarter than continuously killing Eggs every loop that the button is pressed. As far as I can tell, this map would work perfectly if the concept was real. It really is a pity that it isn't.

Aye, I kept running out of eggs, which led to the press/release idea. I thought it was going to be simple, but then I had a whole mess of the local and global switches getting desynchronized, so you could end up hitting down to go up, or you're always running left unless you hold down the right key. The fix for that was moving all the egg-killing to triggers that simply check for if the local and global switches are desynchronized; if they are, the appropriate egg is killed to flip the global switch to match the local one. This way, the global game state will inevitably synchronize with each player's local state.

At the very least, I'm ready in case we do discover an exploit like this. I know there is a way to accomplish local EUDs in multiplayer by abusing the lag timer, if you want to play Russian Roulette. Maybe something more practical will eventually come along...

Despite this being an April Fools joke, I've been asked to keep this thread open for any relevant discussion regarding the original point of it. Keep the posts relevant to that point.

To elaborate on my prior mention of alliance status...

What we really need to make something like this work is a single value - binary or otherwise - that gets sent between hosts as the sole result of triggers

This list gives a rough outline of what is available (under actions that don't desync) most of these are entirely useless as they bring us full circle (such as unit speech, mission objectives, etc), they only execute something that matters locally, however, I think we have two actions (excluding overflow actions for the moment) that have possibilities for something getting transferred, THIS IS NOT PROBABLE, don't assume something will magically happen, it's merely possible.

- Set Alliance Status
- Set Invincibility

Both of these have a unique property that allows them to change the nature of orders given to certain units, I think it's remotely possible that when an order is placed by a human, some kind of shorthand is used... rather than sending the xy coordinates of the click, when you tell a unit to attack another unit, something like the ID of the unit targeted is sent, I think it's possible to harness the mismatch in orders prior to Starcraft sensing a mismatch in unit position, and then (getting even deeper into improbabilities) correct the units' positions prior to a desync occurring, and using the data that could only possibly be there if the first host had one of the above actions performed (you know what this data is because you mapped it in!), sync for a global action.

Again, very improbable; but possibly incredibly rewarding!

Interesting. I would have to do some testing as I am not positive about the nature of how the orders are sent. Does one player's computer check what a unit is doing and then send it? Pretty sure each player runs it for himself. Maybe make a unit that you cannot target because of vision but you have every ability to? The EUD activates and it gives vision so you fire and kill it? This would only work if it shares the attack command as if you had ordered it. I mean I suppose you could spoof that command with a program couldn't you (GOGOGO FARTY)? Alternatively you could own a unit you don't see and have it near another player's unit. When you do the EUD it unallies you and then causes you to fire. This would only work if the "attack" command is shared rather than the vision.

Meh. My 2 cents

Time to play Devil's Advocate...

Quote from jjf28

Both of these have a unique property that allows them to change the nature of orders given to certain units...

And when there is an inconsistency between clients, a drop will happen, just like any other unsafe action. The only difference is that these two actions don't immediately force the drop, not because the inconsistency is acceptable, but because the inconsistency hasn't yet caused the game states to be different between clients.

Quote from jjf28

... I think it's remotely possible that when an order is placed by a human, some kind of shorthand is used... rather than sending the xy coordinates of the click, when you tell a unit to attack another unit, something like the ID of the unit targeted is sent...

The player changes the unit's orders, which are part of the unit struct. You could do the same thing safely with EUD actions. I believe the target orders take in an optional ID for the target, which the X and Y will automatically update to match. I don't see how this provides us anything useful regarding this topic.

If you make a unit invincible for only one client, and then bring a hostile unit in range of that unit, the hostile unit for the other clients will attack the unit, which will not match the client who has the unit as invincible, causing the desync.

Quote from jjf28

I think it's possible to harness the mismatch in orders prior to Starcraft sensing a mismatch in unit position, and then (getting even deeper into improbabilities) correct the units' positions prior to a desync occurring, and using the data that could only possibly be there if the first host had one of the above actions performed (you know what this data is because you mapped it in!), sync for a global action.

I don't understand this bit. Are you suggesting we somehow detect the desynchronization between clients before the game does? That is quite impossible. We can't detect desynchronization across clients because the triggers we write will always tailor to each client individually and assume the data is the same across all other clients.

Quote from TiKels

Interesting. I would have to do some testing as I am not positive about the nature of how the orders are sent. Does one player's computer check what a unit is doing and then send it? Pretty sure each player runs it for himself.

As I mentioned earlier, the unit struct table is shared among all clients. Any command a player makes gets sent through the network and synchronized before anything is written to memory. This is why we have latency: everyone needs to know about what commands other players have sent. If there was no latency at all, the game would lag each time a command was sent until everyone was able to receive the command, which would essentially lead to waiting on the slowest horse. This is why setting the game to a higher latency will reduce or remove lag, as it provides more time for each player to send and receive the commands (and it is also why lag caused by a slow computer instead of a slow network connection will not change if you increase or decrease the game latency).

The way I visualize Battle.net's operation (which is not to be taken factually) is as follows:

1. Player sends any commands he has to Server. Server adds it to a list of commands for the next update (determined by game latency).
2. When the next update is expected, Player asks Server for all commands (other than his own). Server sends Player all commands performed from other players. If this process takes a while, the game will freeze until it is complete (network lag).
3. Player executes all commands. If this process takes a while, the game will freeze until it is complete (processor lag).

That is approximately what happens. And now I forgot why I explained it... Hopefully it's an interesting read, at the very least.

Quote from TiKels

Maybe make a unit that you cannot target because of vision but you have every ability to? The EUD activates and it gives vision so you fire and kill it? This would only work if it shares the attack command as if you had ordered it.

How would you give it vision? Running a script or creating a unit would cause a desync.

Quote from TiKels

I mean I suppose you could spoof that command with a program couldn't you (GOGOGO FARTY)?

Yes, you could make a program that executes commands; that's how AI bots work. You wouldn't"spoof" it, but you'd actually be executing the command as if you had done it yourself. This is just going into some bizarre hotkey idea now.

Quote from TiKels

Alternatively you could own a unit you don't see and have it near another player's unit. When you do the EUD it unallies you and then causes you to fire. This would only work if the "attack" command is shared rather than the vision.

The unit would only attack on your client because the other clients believe it is still allied and therefore won't auto-attack (i.e., you're not sending the command, so it won't synchronize across clients), causing you to desync from everyone else.