After scrolling though some Korean SC:R gameplay videos, I found that one of the maps had a jaw-dropping discovery.
https://www.youtube.com/watch?v=iemLoSWXxyA
It seems they have made a tetris map that is controlled entirely by EUD key-presses. This is strange because experiments done by me and Cool-Knight confirmed that such a thing is impossible in multiplayer (Local player EUD conditions cannot successfully trigger global actions).
I have managed to find and download the map that was shown, and will make it available here. If y'all got any ideas on how they pulled this off, I really want to know.
(Translated map name: "Little Tetris b51")

Attachments:

Set Death/Set Score/Set Switch are actually local actions. In conjunction with another trigger, these values can be used to apply a global action. However, you will have to do some testing as to not cause desyncs. I haven't personally used this, but I know its possible.[/quote][/quote][/quote]

This is only partially correct. Setting a death on a local state is just fine, but you can't use it in conjunction with another trigger to perform a global action, because the condition(s) would only be met for the player that locally set the death, which would cause the desynchronization.

So even with that level of indirection, key press detection would normally cause a desync on a global action.

From the Shoutbox:
These sound like plausible scenarios. Either the author found a way to execute arbitrary code (which is what Blizzard has been trying to prevent), or they discovered a different way to detect key presses (possibly a detection method that was introduced when Blizzard implemented APM features; is APM broadcasted to other clients, and with key values? That doesn't seem likely, but you never know).

Someone would have to take a deeper dive into the map and examine exactly what EUDs are being used.

Well I did manage to open the map. (I also managed to get info, this is all made by: EUD Editor v2.)
Here is all of the map Triggers.

http://cool-knight.eu.org/MapTriggers.txt

Good luck decoding this. lol.

There are 2 conditions present:
Memory 13
Memory 15388

http://farty1billion.dyndns.org/EUDdb/?pg=entry&id=408

It appears it's pointing to the string section. Clearly the map is done almost entirely in EUD and EUD actions, as there are no create triggers, not that you could make perfect squares like that with create anyway. I believe there are zerglings that are being modified to look like cubes.

The pylon, photon cannon, and zerg eggs that appear beside each board must be playing a role in the EUDs. While browsing around the Korean "EUD Editor 2" I found a list of functions in the "TriggerEditor" page. Some noteworthy names include: COrderUnit, AddStatusFlags, RemoveStatusFlags, MorphLarva, TrainUnit, BuildDrone, BuildProbe, BuildSCV.
The functions used in the map are possibly morphing/training. These require a "UnitPTR" followed by a "unit to create". Perhaps by knowing the index of the pylon/cannon/eggs, a keypress could send a train/morph order to these units, thus fires off some other trigger with the desired actions.
The "Unit Order Emulation" theory is more plausible with this evidence.

Edit: There are also some EUD/EPD actions of note in the editor.
-ChangeStarText: Change any string in the game data
-ChatWrite: EUD "display text message" with an additional "line #" parameter [cannot get it to work yet]
-ChatAnnouncement: Unknown Displays white text at center screen (where notifications about minerals/gas/supply are put)
-Display/Make CText: Unknkown, may have similarities with ChatWrite, also has a "keep chatting" paramenter (Unknown)

I will eventually experiment with ChatWrite. This may be how the maker kept the game-controls text permanently at the top line.

Post has been edited 3 time(s), last time on Aug 18 2018, 8:49 pm by MTiger156.

Like I could see detecting orders or selection being used here. You can fully detect right clicks, which is as close to key detection as we will get outside editing the command cards. Like rightclicking on the eggs to determine rotation, direction, then fall/speed up.

Though as the mouse doesnt move, I suspect it's just command card editing of some kind... Which it cant be, because no units are selected...

The map is made by 우마 (EDAC).
epScript Source code: https://github.com/b10li/starcraft_USM_Tetris/tree/master/src

Related BWAPI resource: https://github.com/bwapi/bwapi/blob/master/bwapi/BWAPI/Source/BWAPI/GameCommands.cpp

You can make anything desync to sync via QueueGameCommand.
(Discovered by trgk, first tool NQC by PPS, I'm maintainer of MurakamiShiinaQC, euddraft plugin featuring desync to sync and working in SC:R)
MurakamiShiinaQC is included in EUD Editor 2, plugins menu, so anyone can use it easily without understanding how it works.

Simple explanation

Initialization
Create (invisible air) unit(s) to each players and save *CUnit address alphaID.

Send process
①Save previous selection to memory.
②Select (invisible air) unit.
③Send RightClick to wanted coordinates. (Say if you press Q, add 2**0 to X, if you press W, add 2**1, ...)
④Select previous selection.

Receive process
①Read (invisible air) unit's move waypoint. If it isn't initial value, subtract coordinate and add player's deaths(sync).
②Set unit's waypoint to init value.

Post has been edited 3 time(s), last time on Aug 21 2018, 6:16 am by Arta(M).

Keep chatting iirc will use the text lines starting at the top that won't get 'pushed up' due to normal chat messages, unlike display text.

Check out my tutorial here: http://www.staredit.net/topic/17735/

It's likely that the key press detection was using the MurakamiShiinaQC plugin for EUD Editor 2. I was recently informed about this and was asked to post a guide on how to replicate it here: [EUD] Multiplayer Key Press Detection.

As for how it works: black magic. It seems to somehow be pushing the DC data in sync with the game's turn rate, so the death counter is syncing across clients, making it stable for changing game state.

Post has been edited 1 time(s), last time on Feb 3 2019, 10:19 pm by Roy.