EUDGen2
Feb 10 2013, 5:22 am
By: Roy
Pages: 1 2 35 >
 

Feb 10 2013, 5:22 am Roy Post #1

An artist's depiction of an Extended Unit Death

EUDGen2

Extended Unit Death Generator 2


About

EUDGen is a program used to generate triggers that go beyond the capabilities of regular StarCraft mapmaking. It does this by taking advantage of an overflow exploit in the unit field of the Deaths condition (hence the name Extended Unit Deaths), as well as overflowing of the player field of the same condition (Extended Player Deaths). The goal of this project is to allow all mapmakers to have the opportunity to use EUDs/EPDs in their maps if they so choose, while reducing the learning curve required to do so.

This program is the successor of EUDGen1, also known as EUD Generator. If you are more interested in the work that goes behind calculating EUDs, or just to get a better understanding on EUDs in general, please refer to the following resource: http://www.staredit.net/topic/14226/.
Features
  • Calculate several EPD/EUD conditions and actions (see full list below)
  • Manage multiple triggers, conditions and actions in a familiar trigger editor interface
  • Save and load EUDGen projects for quick and easy modifications
  • Generate EUDs for ranges of values
  • Export triggers to an SCMDraft trigger text file, a .TRG file, or even inject the triggers directly into a map
  • Options to retain or discard descriptive comments on your triggers, both on an individual level and global scale (when exporting)
  • Set Switch option for a convenient way to mark an output that spans across several triggers (like display text)
Full Generation List
Frequently Asked Questions
Screenshots
Download and Dependencies

This program requires the .NET Framework 4 to run. If you're on an older machine and cannot get .NET 4 on your machine, send me a PM and I'll see if I can get it compiled on an older version of the framework.

This download contains two files: the executable (EUDGen2.exe) and an external library (MapExport.dll by FaRTy1billion). While MapExport.dll is not required for the program to run, some export options will not be available if the DLL is not found.

Download EUDGen2 from Sen's database
Extras
To-Do List

Alright, you can start bugging me about new EUDs now. Here's the current list:

Yellow = In Development
Blue = Complete
Green = Deployed Into Latest Version

EUD Requests:
  • Upgrades
  • Technologies
  • Game Pauses
  • Player Vision
  • Unit Flingy Speed (EUDA)
  • Unit Build Queue
  • Game Is In Multiplayer Mode
  • Location Coordinates
  • Selection Circle Color (EUDA)
  • Unit Color Table (EUDA)
  • Minimap Color Table (EUDA)
  • Game Name

Feature Requests:
  • Make action add/subtract more meaningful
  • Make "Between" modifier more meaningful (i.e., "All Between" and "Any Between")
  • Include player groups and special players (Current Player, Force 1, etc.) for death counter conditions/actions
  • Switch conditions
  • Preserve Trigger action
  • Remember "Add Comment" selection when adding conditions/actions
  • Configuration settings to disable protection-through-limitation

Bug Reports:
  • Player Name fails to generate (2.0.2 only)
  • The Irradiate/Stasis/Plague/Storm statuses are reading off the wrong memory block
  • Key Press: The value for Numpad + is incorrect
  • Unit Index range doesn't calculate properly when using index 0.
  • Set Deaths action adds "Int:" in front of unit names.
Version History
Download here: DLDB Link


Post has been edited 68 time(s), last time on May 20 2020, 12:41 am by Roy.




Feb 10 2013, 6:18 am Pr0nogo Post #2



Excellent.

So, the things under the To-Do list are not implemented? I'd like to have local key press events in one of my maps. I know it's been done before but this programme seems like it'd do what I need quicker than copying them down by hand.

Thanks for sharing your work.




Feb 10 2013, 6:22 am O)FaRTy1billion[MM] Post #3

👻 👾 👽 💪

Congratulations on finally releasing it! :awesome:



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Feb 10 2013, 6:39 am Roy Post #4

An artist's depiction of an Extended Unit Death

Quote from Pr0nogo
So, the things under the To-Do list are not implemented? I'd like to have local key press events in one of my maps. I know it's been done before but this programme seems like it'd do what I need quicker than copying them down by hand.
Correct. I know a lot of people really want upgrades, but key press detection is also one of my priorities.

I was gonna hold back on the release because it doesn't have many new EUDs over the old one, but I figured making you guys wait even longer would be unfair. The main utility this has over the old one is generating ranges of triggers.




Feb 11 2013, 3:40 am Leeroy_Jenkins Post #5



Thanks Roy! Nice program!



None.

Feb 11 2013, 5:13 am Lanthanide Post #6



Why did you create EUDGEN2? What can it do that #1 didn't?



None.

Feb 11 2013, 5:27 am Roy Post #7

An artist's depiction of an Extended Unit Death

I just said it...
Quote from Roy
I was gonna hold back on the release because it doesn't have many new EUDs over the old one, but I figured making you guys wait even longer would be unfair. The main utility this has over the old one is generating ranges of triggers.
For example, compare creating triggers to check all 1700 unit indexes to see that they have at least 10 HP in both programs.

Additionally, I have listed features that the old program does not have. A prime example is the exporting feature, and the save/load feature.

And some of the existing EUDs from the old program have additional options in this program. Latency, for example, now has a preset for an "Extra Low Latency," and Unit Status now includes acid spore, plague, parasite, irradiate, stasis, and even if a unit is under Psi Storm.

Please review the original post for the features included in this release that you may have noticed didn't exist in its predecessor.

(As for why I started basically from scratch to make a new program, I discussed this in the old topic, but the gist of it is that the old code was messy and hard to maintain.)




Feb 11 2013, 8:38 pm Kaias Post #8



I saw that EUDGen was headed in this direction, which is why I wanted to convert you to Oreos, so you would be able to create your macro EUD functions in an environment more suited for it.

Anyway, it isn't obvious how multi-trigger conditions stack. For instance, if I create the trigger:
"IF Unit #between 10 and 20 has 0 health AND Unit #between 1 and 5 has 0 kills THEN Set Switch 5"
My expectation is that Switch 5 will be set when all of the units 10-20 have no health and all of the units 1-5 have no kills, not that Switch 5 will be set if ANY of units 10-20 have no health AND Any of units 1-5 have no kills. I wouldn't have known that it behaved this way if I hadn't looked at the triggers it generated. You could rewrite the comment to be:
"IF ANY Unit #between 10 and 20 has 0 health AND ANY Unit #between 1 and 5 has 0 kills THEN Set Switch 5"
Except, it still wouldn't behave how I'd expect because the conditions combine multiplicatively. "Unit #between 10 and 20 has 0 health" generates 11 condition triggers, "Unit #between 1 and 5 has 0 kills", generates 5 triggers, but if you use them both in the same "trigger" they combine to make 55 triggers (rather than additively to be 16 triggers plus a couple more for handling). If my action was "Modify Unit #1's heath: add 20", making the trigger:
"IF ANY Unit #between 10 and 20 has 0 health AND ANY Unit #between 1 and 5 has 0 kills THEN Modify Unit #1's heath: add 20"
I would expect that if [any of 10-20 had 0 health] and [any of 1-5 had no kills] then unit #1 would gain health once in a loop. In reality it could happen as many as 55 times. For example, if unit #16, #17 and #18 had 0 health and units #1-3 had no kills I would gain 20 health nine times over.



None.

Feb 12 2013, 12:30 am Roy Post #9

An artist's depiction of an Extended Unit Death

Quote from Kaias
I saw that EUDGen was headed in this direction, which is why I wanted to convert you to Oreos, so you would be able to create your macro EUD functions in an environment more suited for it.
I don't think Oreos is designed to be abstracted into an intuitive GUI (intuitive meaning clear and easy for someone who doesn't understand how for loops or declaring variables work) that wouldn't ultimately limit its potential to something relative to what I have. The goal of the original EUDGen was to try to keep it as familiar as possible to how the classic trigger editor makes conditions. When it came to improvements, people wanted ways to generate large ranges of conditions in an environment that posed a relatively small learning curve, which is what I tried to do here, all while retaining the familiarity of the classic trigger editor.

Quote from Kaias
Anyway, it isn't obvious how multi-trigger conditions stack. For instance, if I create the trigger:
"IF Unit #between 10 and 20 has 0 health AND Unit #between 1 and 5 has 0 kills THEN Set Switch 5"
My expectation is that Switch 5 will be set when all of the units 10-20 have no health and all of the units 1-5 have no kills, not that Switch 5 will be set if ANY of units 10-20 have no health AND Any of units 1-5 have no kills. I wouldn't have known that it behaved this way if I hadn't looked at the triggers it generated. You could rewrite the comment to be:
"IF ANY Unit #between 10 and 20 has 0 health AND ANY Unit #between 1 and 5 has 0 kills THEN Set Switch 5"
Except, it still wouldn't behave how I'd expect because the conditions combine multiplicatively.
That's an interesting semantic issue you bring up. Generally, in SC when you are making triggers and you're trying to add one single condition, it doesn't apply across a set or even a range of values unless it's an actual value field (for example, you can't make a condition checking that a player brings 1 [Terran Marine - Zerg Scourge] to a location), so I used the same idea behind that for ranges that are not specifying the pure value of the condition. I found it to be consistent with how SC would handle it if you had to roll it out manually.

If you wanted it to be an AND, you should be adding them separately like you would normally with other conditions. If you want it to be an OR, you should know this requires making multiple triggers manually, so the program should be expected to make multiple triggers.

That was my line of thinking, at least. I can see how it's confusing because I use the same modifier "Between" for both types of operations (as an OR if it changes the address, and as a quick macro for "at least" / "at most" if it's just a value of the EUD). Perhaps I could eliminate the "Between" option for pure value fields and make the user create separate "at least" and "at most" conditions for clarity.

As for actually treating ranges as ANDs instead of ORs, I find it unlikely to be the case that you'd want to AND a consecutive range of addresses in the first place, but I could make the option available. Perhaps changing "Between" to "Any Between" and adding a new modifier called "All Between" would be more intuitive?

Quote from Kaias
"Unit #between 10 and 20 has 0 health" generates 11 condition triggers, "Unit #between 1 and 5 has 0 kills", generates 5 triggers, but if you use them both in the same "trigger" they combine to make 55 triggers (rather than additively to be 16 triggers plus a couple more for handling).
If your intent is to have this be additive and you plan on creating another trigger to figure out if both items have been tripped, how would you handle this normally? You'd create one trigger group with "Unit #between 10 and 20 has 0 health" and one with "Unit #between 1 and 5 has 0 kills," each group setting some variable, and then a final trigger checking that both variables are set (plus a cleanup trigger).

EUDGen works the same way: you'd create one trigger for "Unit #between 10 and 20 has 0 health" and one with "Unit #between 1 and 5 has 0 kills," and the generator will make both groups separate since you've specified to do so. The reason it's multiplicative if you put ranges in the same trigger is because that's essentially what you're telling the program you want to do: all combinations with no fancy optimization logic. That was my reasoning, but I can understand if you disagree with me here.

Quote from Kaias
If my action was "Modify Unit #1's heath: add 20", making the trigger:
"IF ANY Unit #between 10 and 20 has 0 health AND ANY Unit #between 1 and 5 has 0 kills THEN Modify Unit #1's heath: add 20"
I would expect that if [any of 10-20 had 0 health] and [any of 1-5 had no kills] then unit #1 would gain health once in a loop. In reality it could happen as many as 55 times. For example, if unit #16, #17 and #18 had 0 health and units #1-3 had no kills I would gain 20 health nine times over.
Again, you have to think from a regular mapmaking perspective on how this would be implemented: if you had two separate triggers checking if UnitTypeA or UnitTypeB is brought to a location and the action was to give the player 1000 minerals, you shouldn't be surprised when bringing both UnitTypeA and UnitTypeB to that location gives the player 2000 minerals. To remedy your situation described above, you could flip a switch and have a trigger checking the switch to do the health addition.

I'm not trying to sound defensive, and I apologize if I've come across as such; I greatly appreciate your criticism.




Feb 12 2013, 12:35 am FoxWolf1 Post #10



Anyone else getting a "fail to load file" error when trying to use the thing from the "extras" section?



None.

Feb 12 2013, 12:43 am Roy Post #11

An artist's depiction of an Extended Unit Death

Oh, my mistake; I accidentally uploaded a test file I had laying around. Try downloading the euddb file again. Sorry about that.




Feb 12 2013, 12:54 am FoxWolf1 Post #12



Seems to work now. Thanks!



None.

Feb 12 2013, 1:41 am Azrael Post #13



Quote from Roy
Perhaps I could eliminate the "Between" option for pure value fields and make the user create separate "at least" and "at most" conditions for clarity.

Please don't. The same hypothetical potential for initial misunderstanding would still exist, at the cost of functionality and convenience.

Post has been edited 1 time(s), last time on Feb 12 2013, 3:24 am by Azrael.




Feb 12 2013, 2:40 am Leeroy_Jenkins Post #14



I think another really useful eud condition to have would be unit orders given to a specific unit. These can be used as a keypress detection system for multiplayer, so if there's ever a eudgen3 :P



None.

Feb 14 2013, 3:19 pm LoveLess Post #15

Let me show you how to hump without making love.

I would really appreciate a feature that allows me to paste/load text in TrigEdit syntax into the EUDGen. If you did this, I would create things that would blow minds. Because learning a new syntax (Oreo) isn't something I want to do when I am so fluent in TrigEdit.



None.

Feb 16 2013, 11:16 pm Roy Post #16

An artist's depiction of an Extended Unit Death

Well, the latest version has just been released. Those that were looking forward to key press detection will be happy to see the version log.
Version 2.0.1:
  • New Conditions:
    • Unit Order
    • Unit Target
    • Text Detection for Unknown Player Name
    • Next Display Text Line
    • Key Press Detection
  • New Actions:
    • Unit Order
    • Unit Target
    • Next Display Text Line
  • Text padding is much more flexible
  • Can select individual rows for text detection

I'm going to be working on getting upgrades and technologies worked out next week. There's also a change request on splitting the sender/receiver for chat detection that I'll try to get into the next release.

Text Padding

The text padding is necessary for most applications of text detection (you can read on why in Section 7.3 of my tutorial). In order to effectively pad your text, you need at least two characters (in which case you'll need to enforce in-game that the padding must be exactly 2 characters). The rules are as follows:
  • If you enter no characters for padding, it won't pad the text at all. This can be problematic for scenarios where padding is necessary to properly detect the text, but it's still an available option.
  • If you enter one character, it assumes the old functionality (at least three padding characters at the end of the message), and it functions the same as if you enter three of the same padding character.
  • If you enter two characters, it assumes the players will always be typing two characters at the end of the message. It will use the null character as the last padding character where necessary.
  • If you enter three characters, it will check up to what is necessary for the given message.

Padding characters will be truncated off of the message where applicable, whereas the message itself is always assumed to require a full reading. If you want to have no padding characters and just rather have your message itself be truncated, enter the last two or three characters of the message as your padding.


Post has been edited 3 time(s), last time on Feb 18 2013, 5:57 am by Roy.




Mar 2 2013, 7:20 pm Roy Post #17

An artist's depiction of an Extended Unit Death

Sorry, no upgrades / technology yet.
Version 2.0.2:
  • New Conditions:
    • Deaths (For death counters)
    • Hallucination (Unit Status)
    • Current Player Id
  • Actions:
    • Set Deaths (For death counters)
    • Set Current Player Id
  • Can select Sender/Receiver individually for player chat
  • Descriptions for triggers will always display in the trigger list, even if you have comments disabled (no more blank lines)
  • Fixed an issue regarding editing items with custom values
  • Fixed minor styling issues
  • Fixed input for numeric boxes.

Just a quick debriefing on text display:
DISCLAIMER: Almost all of the information I learned about below is a direct result of Azrael's hard work and testing with the player chat system. I take no credit for his discoveries and only offer the analysis we concluded from his findings.

Display text detection is not technically a global EUD: if you send a display text message to only one player, you can desync them by detecting that text and doing a global action off of it. In the same respect, player chat is not technically a global EUD: players can send and receive whispers or send to allies / a specific player in-game. Therefore, the player chat generation provided by this program isn't necessarily "safe" in this regard.

Furthermore, timing for messages sent and received by players is not synced to the game (unlike Display Text Message): messages are sent to the server, which then broadcasts it to the players as soon as it can. This has been measured (thanks to lil-Inferno and Origin for helping me and Azrael with measuring these numbers) to vary by as many as 5 hypertrigger cycles (and potentially more) to be received by all players. The reason this is an issue is because it means some triggers can fire on earlier trigger cycles for some players than for others, which would cause a desync on the end of that particular cycle. I currently do not know a remedy to this issue, and if you want to have chat detection as a mechanic in your multiplayer game, you'll have to regulate using a global timer when to execute chat actions (e.g., have a countdown timer and queue chat commands to run when the timer hits 0) and rely that your players won't attempt to send a chat command near the time that processing the actions occurs.

For this reason, player chat detection is significantly less effective than I had originally realized. Chat detection works pretty well has a noticeable chance of working without desynchronizing for a single chat command in maps that do not have hyper triggers, because the chances that the trigger will execute when not all players have received the message are decreased significantly. Raw chat detection on a map with hyper triggers will desync without fail.

TL;DR: Fuck text detection.

Also, the extras section in the OP has been updated for those interested.

Post has been edited 3 time(s), last time on Mar 3 2013, 12:05 am by Roy.




Mar 2 2013, 9:28 pm Azrael Post #18



Quote from Roy
to vary by as much as 5 hypertrigger cycles (and potentially more)

There was a test in which the variance was 8 cycles, but it could still be even more than that.

Quote from Roy
rely that your players won't attempt to send a chat command near the time that processing the actions occurs.

I developed a solution to this already, in which the other players can't be desynced by someone timing their command poorly. The design has been completed, it just needs to be implemented when I have time to complete my system (which is already "functional" in the sense that it'd work if chat was synced properly). The modifications will make the system safe, so that someone couldn't choose to desync others even if they wanted to.

Quote from Roy
Chat detection works pretty well in maps that do not have hyper triggers, because the chances that the trigger will execute when not all players have received the message are decreased significantly.

I'd say "works pretty well" is a bit misleading. There is still a 20% chance of desync for every command used, even when the players are only a few cycles apart. In situations where they are 5+ cycles apart, which doesn't seem to be uncommon, it's going to be around 30% and higher.




Apr 27 2013, 9:31 pm Thanase Post #19



I have a trigger:

between p1 and p6 has name: yoo
(sending)player "yoo" says on row between 1 and 11 "set round 15"

actions:
clear switch 1
set switch 15


In game with other people, the message I set for switch 15 pops up after i type the command, but about half a second after the trigger works, i get dropped from the game. Apparantly its only me because everyone i whispered said it was only me that dropped from the game.



None.

Apr 27 2013, 9:47 pm Azrael Post #20



That trigger is only working for you, because you're checking for "sending". You're the only person who is sending the message, the other players are receiving it.

Since it's only happening for you, you get desynced from the other players, and drop.

Theoretically, you can fix this by changing "sending" to "between sending and receiving".

In reality, if you're using hyper triggers, it'll make everyone desync because chat messages are received at slightly different intervals for each player. If you're not using hyper triggers, there's a lower chance of causing desync, but it still has pretty good odds of happening.




Options
Pages: 1 2 35 >
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[07:27 pm]
NudeRaider -- everyone gets their own message! How thoughtful! :wub:
[12:42 pm]
Vrael -- do these guys realize the effort they're putting to advertise to like 15 people?
[12:25 pm]
Zoan -- hard at work for dem minerals
[2024-10-08. : 7:53 pm]
Zoan -- I'm in Georgia; somehow it seems to have been a lot worse for you guys even though you're all more north
[2024-10-08. : 7:52 pm]
Zoan -- Ultraviolet
Ultraviolet shouted: My town right now (a few days ago at this point). It's crazy here, day 12 with no power or running water.
daaaang man
[2024-10-08. : 6:40 pm]
Ultraviolet -- My town right now (a few days ago at this point). It's crazy here, day 12 with no power or running water.
[2024-10-07. : 11:00 pm]
Oh_Man -- https://youtu.be/h6ORd1FA6V8 we saved the gays (this map was exceedingly korean)
[2024-10-07. : 3:18 pm]
Zoan -- Oh_Man
Oh_Man shouted: and then he replaced every time i said free will or the self with "gubble gubble gubble" XD
lool
[2024-10-06. : 3:32 pm]
Vrael -- everyone knows that
[2024-10-06. : 3:32 pm]
Vrael -- IDGAF: Intentionally Depleted Galactic Ardor Frankfurters
Please log in to shout.


Members Online: Roy, Vrael