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

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.

Congratulations on finally releasing it!

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.

Thanks Roy! Nice program!

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

I just said it...
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.)

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.

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.

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?

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.

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.

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

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

Seems to work now. Thanks!

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.

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

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.

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.

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.



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

Sorry, no upgrades / technology yet.

Just a quick debriefing on text display:

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.

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


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.


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.

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.

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.