Yes, this is almost always the case, but I think we can change which data is possible to send via these semi-safe actions, whenever the data is revived/sent, you would know a local condition must have fired.

Clearly i'll need an example to illustrate my still-vague thoughts:

- Force humans to send the data only when a condition is detected (really an intermediate goal that would make more useful methods worth exploring):

1. Place bunker somewhere, ally host A and host B, set bunker to invincible on host A
2. When local EUD occurs, set bunker to invincible on host B
3. Tell host B to select the marine and right click the bunker... have it somehow IMPOSSIBLE to issue the command on host B until invincibility is set (perhaps issuing a right click on some unit would do nothing under the non-unique invincibility's/alliances (because nothing would occur, no command sending would be necessary))
4. When command occurs it will perform an identical action on both clients, that could not possibly occur without the local EUD firing invincibility (so when the action occurs, you know to perform global actions)

^-- this is me brute forcing improbable possibilities, I don't actually expect stuff like this to work


I don't like the word impossible, nor do I think you're justified in using it in this context namely because the noticeable part of desync occurs consistently about 2 seconds after data is misaligned on the hosts

Here's how my imagination goes with synchronization:

- data that is to be checked for mismatch is streamed from/to both hosts (likely via UDP to save on what used to be, precious bandwidth)
- both hosts line up the data and drops all the sections that are identical, and then requests any sections that were missing (now via TCP) or were misaligned this time
- if any sections still don't match up, the host that detected the mismatch sends a desync message and stops communicating with every host he didn't match all his data sections with

I would contend that it's entirely possible to detect that the game is about to try to double check data for mismatch, and repair the relevant data by, say, moving a unit back to a static location on both hosts; unless you know something I don't (which i'll bet you do )

^-- again, working with improbable possibilities


Latency is very tricky in Starcraft...
- In-game latency changes tell every hosts to change their local latency values, however...
- Latency is not synchronized (as something like health would be), that is to say: two people can play with different latency's without desync (hackers can theoretically play on Lan-Lat, while forcing everyone else to be on extra-high lat)

Because of the above I don't think that latency works quite in the way you described (waiting for everyone to get the commands, then firing them) since the hosts must not work in harmony

Post has been edited 5 time(s), last time on Apr 3 2012, 6:06 am by jjf28.

So... You start with the two clients desynchronized, and then B does something that happens to synchronize himself with A. In this instance, A or B would have had to have done something to desynchronize in the first place, and when B synchronizes with A again, they are effectively in the same game state again. This either means:

1) A did something, and then B did the same thing
2) B did something, and then B undid whatever he did.

Both of these scenarios lead to uninteresting results.

Furthermore, you can accomplish the same effect of not dropping immediately by a simple trigger restructuring. For example, you could make the local EUD set a switch, and then later in the game it would check if the switch is set before doing the global action. Unless I'm missing something, the delay for alliances and invincibility don't give us anything new to work with.


That information would be located in dynamic memory, so we couldn't write workable EUDs for it.

I don't see how that specifically contradicts my description (which was describing communication to the server, rather than exactly how latency works), though I'll admit what I said is simplified to the point of being incorrect. I don't state that the player waits on everyone; it waits for the server to receive all commands that have been sent, and the server will lag the game if a player hasn't received the data of a command that is going to be executed. The commands would likely have data for the time it should be executed, of course (which would be time sent + latency delay); a player could indeed have no latency or a very high latency without any desynchronization issues. However, there can be lag issues caused from this, like if a very low latency player is about to execute his command but other players haven't received it yet. I've also lagged out by setting my latency to a large number, which makes me believe it affects how often you ask the server for command updates as well. Thinking about this, though, it doesn't make too much sense to only check for commands when the latency time is expiring, and I'm fairly sure that's not what happens, so I can only assume the lag out was from the value being unstable.

I don't know the innards of SC by any extreme measure, mind you.

Starting and keeping a value de-synchronized is quite easy (map attached) and re-synchronizing wouldn't help transfer information at all, I agree - sorry if this is not actually a point of confusion but it seemed so from the context.

Forgive me, but as far as I can tell you didn't grasp the crux of the method - the fact that the action can only be performed if the semi-safe actions of invincibility/alliance are changed.

- Host B always thinks that host A can perform action X
- In reality, host A can perform action X if and only if invincibility is set
- When a local EUD condition is satisfied, set invincibility on host A
- Have host A perform action X
- When action X is performed, you (the mapper) know that invincibility was set on host A and therefore can perform whatever global action you want as a result of the local condition

Action X itself is also unique, it must do something along the lines of returning null (sending no command to other hosts) unless invinc is set, otherwise we ofc get desync's, this is where the improbabilities come in, I'm not sure any null-returns actually exist. Action X is also (in this example) a human-sent command, not by triggers (which would most likely result in a desync)

Ultimately the above is not an example of information be transferred automatically, and is not very significant on its own, it's just an intermediate goal that proves there's something there to work with here

Attachments:

Post has been edited 4 time(s), last time on Apr 3 2012, 2:37 pm by jjf28.

You're right, I'm not grasping the point of this level of indirection. What benefit does the game get from B thinking A can do something, but A ultimately cannot unless conditions are met? You may as well have the conditions met on a global scale, as it is much safer and accomplishes the same thing. If you're going to trigger the action by a command from the player, you don't need any tricks; you can detect that in the unit struct.

The only reason your idea would work is because you're ultimately running a safe trigger (EUD detecting a unit's order, player selection, etc.). The whole invincibility thing is pointless indirection.

It does occur to me that selections are synced; might it be possible to use that to transmit stuff? You can iirc deselect a unit by Giving it to another player and immediately back... So it might be possible to trigger that when a local EUD is met, transmitting it? Not very useful because the player has to actually have a specific unit selected, if it even works, ofc. >.>

Yes, selection detection works for multiplayer; I even made a sample map with WASD movement using selection detection. I'll attach it. Never mind, I deleted it apparently.

I see where your idea is coming from, but I'd have to say that again it wouldn't work. Your suggestion is that when the player fires their local EUD, it will cause a selection to happen, which can then be detected safely to fire the appropriate trigger, correct? This won't work for the same reason setting a switch doesn't work: the client firing the local EUD will see the unit as selected, but all other clients will not because the selection wasn't broadcasted across the network. (And besides, this method would require EUD Actions to be enabled.)

In short, there's no known way to make a local EUD that will communicate across the network. The reason Kaias' original post would have worked is because the other clients would receive the notification of an egg being cancelled. The reason jjf28's post won't work is because it does nothing to let the other clients know about the local client's change.

Ultimately, any local EUD must lead to the player executing an action manually if you want there to be a global effect. In this sense, you cannot have key press detection multiplayer without requiring the player to do something else that can be appropriately used. For example, the key press could center view on a unit and instruct the player to select it to actually execute the effect.

Though I should point out that if you have a local EUD trigger that gives a unit to one player and immediately gives it back, it won't cause a desync (excluding certain combat situations, presumably). I made a music toggle using this method, where players could select (using a local EUD address instead of making a global one for each player) a Uraj Crystal to toggle whether the music should play or not, and it would immediately deselect afterward because of the give/give. I would assume this would work for any action that can be completely undone in the same trigger cycle (e.g., Create/Remove, Add/Subtract deaths/resources/score, Pause/Unpause timer, etc.). Not sure if anyone can find something useful from this. Trying to detect the deselect wouldn't work, because the other clients will believe you still have the unit selected.

Post has been edited 2 time(s), last time on Apr 3 2012, 9:18 pm by Roy.

I’ve clearly stated this is not automatic data transfer, it’s a step towards it; it’s a potential proof that local conditions can manipulate when data can get sent, it is similar to having the player shout something to transfer data, but distinct, in fact... the following is close to describing it


However there are two significant differences with my method,

1) Data transfer is safe and secure, whereas systems that lack, say, invincibility changes, must either be safe (allow players to cheat) or secure (desync players when they try to cheat)
2) Data transfer has the potential to be worked into regular actions (which is practically automatic transfer)

And so there’s absolutely no confusion... here is the exact layout of what happens in my method:



Post has been edited 4 time(s), last time on Apr 3 2012, 10:52 pm by jjf28.

Maybe I'm not seeing something, but are you not talking about the same scenario I described?


Of course in my example I didn't specify how to control preventing the player from selecting the unit (though it could be inferred that the screen is always locked on something as a possible implementation); I think your focus is on this control.

I'm gonna make a test map to see if invincibility does actually buy us anything in regards to control.

I just tested (thanks to Raitaki) and confirmed that invincibility doesn't buy you anything in terms of control. If you tell your unit to attack something that is invincible only for yourself, the other clients will still interpret the order as a successful order to attack, causing the desync. I'm not sure if it desyncs on the actual attack or on the order, as that wasn't what I was testing. In any case, that detail is negligible, because there is no way to distinguish a difference in a unit's behavior when told to attack an invulnerable/vulnerable target on differing clients.

I'll post the test map so you can check for yourself if you'd like. I included local triggers to make the depot vulnerable for Player 1 for the hell of it (Press W when not typing or in a menu), and invulnerable (Press S when not typing or in a menu). Player 2 will always see the depot as vulnerable, and they start as desynchronized.

Attachments:

tried some stuff like that way back, that's why my current thinking is to find some situation with a null-return, that is, a player tries to perform an action, but on their host doing so does nothing, so no command needs to be sent to the other players hopefully that would mean no command is sent (since the command would do nothing), unless the invinc conditions or something are met.

The only way it can work is if triggers can change something that the client will update the others with without desyncing. If there is something where the clients update the others with the state rather than the action of something, then it could work. For instance, the give/ungiving of a selected unit would work if the way selection detection works is if every so often the clients tell the others what they have selected, rather than telling them only when they make a selection or deselection action. I don't know of anything that actually works this way.

Just in case, I had tried with a bunch of different scripts like unload/load transport, or order (only your own units) and the give/ungive your selection idea. As expected these didn't work.

Interestingly, if you give/ungive deselect very quickly after selecting a unit the selection condition will remain "true" even locally even though the unit is deselected, until you make a new selection. I don't know what to make of that.

Post has been edited 1 time(s), last time on Apr 4 2012, 5:17 am by Kaias.

The only possibility I see is if a programmer makes a program that will spoof an order packet in conjunction with a locally-conditioned eud action of the order.

Yeah, I did a test for give/ungive and that seemed to be less forgiving on a Zergling; maybe it had to do with the fact that the Uraj Crystal is a power-up, or that I was trying to give the player an upgrade with the Zergling give/ungive. In any case, it's certainly not a step towards globalizing local EUDs.

If we're bringing external programs into the mix, you may as well just make a hack or a mod. I thought the point of this discussion was to find a way to make local EUD conditions work in multiplayer without requiring any external component, so that the only thing you need to download for the map to work is the map itself.

Yes, your suggestion is a possibility, but only in the same sense as "Let's make a SC2 map instead."

Excuse me but this thread has posts with lots of info in them so I didn't read everything but the original post was an april fools, can someone summarize what's going on by now?

Real attempts to connect local EUDs globally were made. So far, no good.

I once read that people generally think of what is there, rather than what is not.

That being said, what if one were to devise a system where the identifying variable, i.e. what the rest of the players detect, based on the lack of x, rather than x?
The triggers which all players would execute in sync to perform global action Q might look something like this:

Code

Trigger: Player P: Input
Condition:
[EUD] -=- //Button A is *not* pressed. (Or any other local EUD condition)

Action:{
Set Invincibility State of Unit u to 0.  <---
Unit a attacks unit u. (Or any appropriate order o that *can be interrupted*. <---
Set Invincibility State of Unit u to 1. (Or, the negation of o)}  <---



Trigger: All Players: End sync
Condition:
[EUD] -=- //Unit u is not attacked (i.e. HP is not falling, multiple ways to detect)

Action:
Q

That is the template I came up with... The <-- command is where things may become problematic. Perhaps, the setting of invincibility will *always* be performed by all players, except for one time Player P does not join in... causing a cancellation, or a desync?, maybe refuting that issue.

The ultimate question is, does it automatically perform the order of cancellation, along with the necessary packets? If not, one would need to find something that does; the bracketed code might hopefully be replaced with a better respective order o and interrupt, like recall and statis, queen infestation, etc.

My general premise is that it might necessary to look up. Thank you for taking the time to read this.

Post has been edited 1 time(s), last time on Apr 8 2012, 10:44 am by Hatsumei.

That would desync. You're welcome to try it out but I'm 99% sure that would just desync.

The problem with this is that Unit U will be attacked for everyone who doesn't see it as invincible, and won't be attacked for the ones that do see it as invincible. Those two groups of people will desync from one another at the moment the attack begins.

A more detailed summary:

• Kaias' April Fools, had the information been factual, would have worked because there was communication between the players across the network of the change caused by the local EUD.
  
• jjf28 observed that setting alliance status or invincibility doesn't cause a drop until a combat situation occurs, and theorized that this would buy us something in terms of using EUDs.
  
• After some testing, I found that these changes do not allow us to send different information across the network at any future point in time, so jjf's theory has thus been proven to be wrong.
  
• TiKels suggesting making pairs of values to commands that would be automatically executed using a third party program. This would work, but it's the same as suggesting to make a mod or hack for SC that everyone needs to play the map.
  
• Hatsumei suggested that looking at the problem backwards would provide a solution, but Azrael pointed out it still doesn't solve the communication issue, so the two parties would drop from one another.

In conclusion: There is no discovered way to run a local EUD trigger that will lead to a necessary network communication automatically. The effect can be "faked" by giving the player instructions when they execute a local EUD trigger to manually execute the global trigger, but there's no proven method to prevent the player from executing the global trigger without executing the local EUD trigger.

Example: Player 1 presses the 'V' key (local EUD trigger). The game center views onto a Barracks and tells the player to make a Marine. When a Marine is created (global trigger), the game ends in victory.

In the above example, it simulates Player 1 pressing the V key to win the game. This is as close as we currently are at getting local EUDs to work in multiplayer. You may notice that the victory is actually triggered by building a Marine, so really, Player 1 doesn't need to press the 'V' key at all. There isn't a known way to safely make it impossible to build the Marine (or an implementation of enabling some other global trigger) until the local EUD is executed (though you could prevent the player's screen from looking at the Barracks, and automatically deselect the Barracks if they select it without first running the local EUD to make it very difficult for the player to do this).

I would say it is in the realm of possibility for some player variable existing that 1. the other clients can detect, and 2. the other clients do not care about. The 'shared' that shows up in this particular reference (My hat to you, yoonkwun) leads me to believe Starcraft goes through these values.



I'm going to test whether the <--- part is automatically shared via a memory editor. I'm not sure if it can be automated.

Post has been edited 1 time(s), last time on Apr 8 2012, 10:58 pm by Hatsumei.