i read before on sen that euds are not as badass as they seem because they are limited and they have many problems associated with it.
i read this on the wiki
Wiki: "not including single-player actions (for obvious reasons), these are all of the actions will not drop (brute-testing, ftw):
Preserve Trigger, Wait*, Transmission, Play WAV, Display Text Message, Center View, Set Mission Objectives, Set Switch*, Set Countdown Timer*, All Leader Board (and Goal), Set Score*, Minimap Ping, Talking Portrait, Mute Unit Speech, Unmute Unit Speech, Move Location*, Set Invincibility**, Set Deaths*, Comment, Pause Timer*, Unpause Timer*."

Set Switch, Set Score, Set Deaths seem pretty badass to me if theres no strings attached so my question is what is the problem with these 3 actions. I did not understand the asterisk
Wiki: "* Be cautious if you have any other desynching triggers that are dependant on these or use them in any way because they may cause a desync."
can someone explain this?

Post has been edited 1 time(s), last time on Apr 18 2010, 4:47 pm by Warlord_Master.

First of all, when you quote something please wrap it into quote tags so it's easier to read.

Well a switch doesn't do anything by itself and thus does not drop you but if you execute dropping actions depending on a switch that was only set for your starcraft by EUDs then you will still get dropped.

Set switch, score, and deaths don't inherently DO anything. They just change one number in the memory. They can be used in other triggers as a condition, but if you do anything that needs to be the same on all copies of SC, and only one computer runs them, then you have a problem.

A useful thing for them is to link multiple EUDs together, such as you have 10 different EUD conditions and you have a bunch of triggers all of which run on those same conditions. Make one trigger which sets a switch based on those 10 conditions and run the rest of the triggers off the switch to save yourself time.

If you have a non shared value like this:

Memory(non shared value is true);
Set Deaths(cantina, set to, 1);

This trigger will run fine, nobody will drop.

You can then call it back by saying:
Deaths(cantina, at least 1);
Display text("text text text");

However if you do this:
Deaths(cantina, at least 1);
Create Unit("terran marine", anywhere);
the player who runs the trigger will drop.

Does setting mission objectives cause players to drop? I don't think displaying text does.

EUDs Wiki:

Just in case this was about EUD enabler.

EUD actions won't desync other players. (Unless not everyone got EUD enabler and the map executes an EUD action.)

EUDs in general don't desync if everyone is running the EUD enabler.

except if you run a non shared condition and desyncing action. Unless of course, the eud enabler prevents desyncs, but it doesn't matter because there will still be two distinctly different copies of SC running.

Oh. With the enabler, there are still non-shared conditions? I thought it globalized stuff or something. What the hell do I know talking out of my ass.

Farty would have to add in shared data for screen position, player 1 account name, etc...

If you edited it to work, eventually there would be something that wasn't possible to be identical (otherwise how would player 1 be different than player 2).

What I meant was that EUD actions don't desync, only the EUD condition.

EUDs are only indirectly responsible for desynchronizing.
In order to have a clear grasp of what will desynchronize and what will not, you need to understand how two Starcraft clients maintain synchronization.

http://en.wikipedia.org/wiki/Synchronization

If two pieces of data directly affiliated with the highest level of the game are different between clients, they will desync (for example, two different scores, or unit A moves in two different directions). Even if a trigger is not run for all players, it is still executed by all clients. So if a trigger is owned only by player 2, player 1 will execute that trigger for player 2 at the same time player 2 executes that same trigger. If the data represented at the location of the EUD condition is different between clients, then the trigger will only execute for one of those players and inevitably cause a desync (if not instant, it will later).

Still, even with this limitation, EUDs are very powerful and have a seemingly infinite number of uses (currrent EUDs are barely touching the surface compared to its full capabilities).

Just something I've been curious about; is it possible for an EUD action to change an instruction in StarCraft like changing a JMP to a NOP or does it not work like that?

I don't think it would work(triggers DEP exception?). You could however overwrite function pointers in the data segment to execute your own custom code that does anything you want it to, as long as the code is written in a memory location that allows both write and code execution (Storm's SCode and SBltRop3 functions for example).

However, I could be mistaken.