I don't know anything much about EUDs or SC technical stuff. I understand that we can use EUD conditions, but can't use actions because they work only on local machine and desync or something? I just thought of tank changing it's state. Tank mode and siege mode are 2 different units, jet SC reads HP of tank mode and write HP of siege mode upon change. If we could somehow mask an EUD action as tank/siege change, maybe it would work. Or make the change write more than just the tank HP. Like if we knew when exactly a tank if going to change, smuggle some data along with the tank HP. It's a wild guess from a dude without proper knowledge, sorry.

EUD actions can't be run period in the current, un-edited version of Broodwar. You need to have some sort of 'hack' running like Farty's EUD Action Enabler for them to work (and then only on computers in the game that are running said hack).

When a tank enters Siege Mode, it still has the same index ID.

What does that mean? HP is somehow connected to the ID? It's still a different unit, with it's own name and stats.

more thoughts/responses:


We can't run global actions based on local EUD conditions because if the local EUD conditions (such as display text) are different for two players, one of them will run the global actions and one will not, causing two separate versions of the game to emerge (ex: one game that has a marine in it, and one that does not) and a desync occurs. Roy explains better: Synchronization


While this wouldn't do much for trying to run EUD actions, there's a minute possibility that such a change could be used to transfer data from local EUD conditions, and thus be able to run actions based on events like keypress (very minute IMO, a players computer would in all likelihood read the hp as it shows up in his memory, not as it shows up in a different players').

There is a current method of transferring local EUD conditions that I consider very clever, actually generates lag with local actions, and uses the length of the lag spike to perform global actions.

I think there are other, unexplored avenues for transferring local data, if a player was running an EUD Action Enabler, for instance, I would think it possible for him to generate an order for a unit to move somewhere (as if the player had did it himself), and then all the computers could use a bring condition and run global actions (non-EUD) based on that.

I've also dreamt of some other glitchy ways to transfer data, inspired by methods used to desync oblivion users in certain maps based on the use of fog... Changing alliance status locally (which is NOT an immediate desync btw, contrary to this list) for instance, may be able to simulate an order from a player which could be read on other computers (though initial tests suggest the possibility is bleak). And there are always other overflows to explore that might tap into something that gets transferred.


If it still has the same ID then there would be no need to read and write HP (same goes for unit position, whether it is plauged, matrix'd, etc), it would exist in the same space in the memory as before, it would only be neccesary to have other values changed like what sprite is displayed, what name is has, its attack range, etc.

Ok, could we somehow trick it to change these other values the way we want it and possibly along with other data?

A desynchronization happens when the information being sent from client to client has a mismatch. In order for both clients to always have the same outcomes during run-time, both copies must be the same. You will need two un-modified copies of SC, or two copies modified in the exact same way.

You can't "hide" an EUD action within anything because even you somehow attempted to modify how your client works, an opponent's client won't work the same way resulting in a packet mismatch.

Once a mismatch is detected, the game ends communication with the player it is having a mismatch with, by design.

No, because there's no way to send this data. If we wanted to inject something into SC that would let us do this, we could, but that's a hack and wouldn't work on a non-hacked computer.

The reason EUD actions used to work before they were patched is because we would overflow the "Set Deaths" action, which actually let us set other values in SC's memory, like the HP of a unit. However, after this was patched, we can no longer set data outside of the unit death table (without an enabler).

EUD conditions won't help here because all they do is check a value; they don't set anything.

Your idea is asking to change the way SC works, which is not a map thing but rather a mod thing. If you're going to take this route, you may as well just make a mod, because everyone is going to need to download and run whatever you make (as you couldn't put it in the map itself) if you don't want them to drop.

I'm just brainstorming. You're the smart guys in terms of SC mechanics.

There are 2 types of EUD condition triggers.

Shared EUD conditions
Local EUD conditions

Shared EUD conditions are pretty safe. What you do is read data that is the same on every single computer. That way, the action you have runs on all those computers.

Local EUD conditions are the ones that can easily cause desyncs. When you run a local EUD condition, the condition is not true for all computers in the game. For example, a normal trigger might be "Player 1 brings exactly 1 marine to location 0". It's a bit counter intuitive, but Player 2's computer ALSO has to run that trigger, even though it's player 1's trigger. So when you run an EUD trigger "Current player presses 'x'", player 2 has no way of knowing when and where player 1 pressed x. Thus, the trigger will only run on Player 1's computer, but not player 2's computer. If the action is something that is shared like creating a unit, then Player 1's computer will have a unit created, but Player 2's computer will have no unit created. This means that Player 2 has no way of knowing what that unit does. At this point, the game becomes impossible to play theoretically, so the game splits up. If all the players press "x" at the same time, then the value is essentially shared, and the game won't desync.

EUD actions are not possible because it is impossible to "write" data outside of the normal location. It is still possible to write data, but extremely difficult, and impossible through triggers. Units, for example, will write data, which is why we can use units owned by extended players to give supply. The "give supply" and "build score" areas are very close together, so when player 255 owns a unit, it tries to put down that its build score is a certain amount at a certain location in memory that is based off the player number. Likewise, extended units have strange properties if they don't crash.

Sounds like exploiting bad programming.

It's not bad programming if it is something outside of what should normally happen ...

Well if you use a pointer that was freed, or allow spilling outside a buffer, isn't that something that potentially compromising?

Blizzard's program (staredit.exe) did not allow for this overflow. The UI the user is provided doesn't allow the input for this abuse, and it is only possible to accomplish this in third party programs. Unless you're telling me that not writing a test case for everything the user isn't allowed to do is bad programming, I'm afraid you'll have to either desist from your original suggestion or admit that everyone is a bad programmer. (Granted, the checks should have been at a lower level than the UI; if that is the argument you're actually presenting, then yes, I agree that it is a design flaw, but again, the only issue it causes is when someone creates something beyond the actual scope of the project.)

Anyway, this isn't a discussion on Blizzard's design practices in the 90's. Let's try to stay on topic.

Siege Mode is not a trigger we can write, meaning that any revelation that may come from this idea would be completely independent of EUDs. Since maps don't have this level of control on how units use their abilities, I'm very certain we cannot add anything to the ability. Detecting a tank going into Siege Mode would be easy to do with EUDs, but it would be even easier to just use the "Command" or "Bring" conditions.

Post has been edited 1 time(s), last time on Mar 6 2012, 11:01 pm by Roy. Reason: "Add anything additional" is redundant

Erm, uh... This kind of is a necro, and... I don't know if the original idea would, uh, work, but you can force a tank to unsiege by running Move Unit on it... So... >.> Might that help at all?

Your suggestion would only buy us something if something was bought by unsieging the tank at all. If you look back on the previous posts, the conclusion is that the transition between the two Siege Tank units cannot be harnessed in any useful manner. We could use an EUD to check when a Siege Tank has sieged or unsieged, but we also can check that without using any EUDs, so that's completely useless to us. Moreover, there's no way we can use triggers to send "extra data" to a function when we cannot send any data to it at all in the first place; there's nothing to work with, and therefore nothing to "abuse" or overflow.

In conclusion to the original topic: