Quote from staxx

I think Roy meant when v1.4 is ready. at least thats what i gather from...

Quote from Roy

Don't bug me about adding new types of EUDs to the program yet (believe me, that list is long enough already). Once I push out this next release, I'll start on upgrade/tech EUDs, more unit EUDs, more text-related EUDs, key press EUDs, etc.

I am just being ignorant and demanding. Having to do this shit by hand is tedious enough already and my maths is bad, so I need this.

Surprise!

I've been making more time for this project, so I'm quite a bit further than where I last left off.

Quote from Roy

Here's the current rundown for the next release features:

• Support creating and managing multiple EUD triggers - Done
  
• Support multiple EUD conditions and actions for a single* trigger - Done
  
• Support exporting trigger data into an existing map - Not Done

* May actually be more than one trigger (e.g., display text detection requires 11 triggers) - Got this worked out

I have the following issues I'm working on:

• Selecting ranges for the Unit Index ID causes trigger generation to fail.
  
• Still got some EUD Actions to enter (not really a big deal).
  
• Have to verify some outputs (I could use some help on this, see below).
  
• I want to add support for unsigned integer values (right now only signed ints work).
  
• The export button does nothing at the moment because I haven't implemented it yet.
  
• Some explicit ranges could be collapsed into a single condition line (this is pretty low priority, though).

Now, as for how you could help: testing! Just pick up [LINK REDACTED] and play around a little bit; try to break it if you can. Also, I had to correct a lot of mistakes I made in the data entry process, so if you spot an output that is wrong (for example, the condition says Memory at +12345 instead of at +12333), I'd greatly appreciate it if you could let me know. An easy way to do this would be to open the executable side-by-side with File: EUD Generator 1.3 and seeing which outputs are different.

If you spot an issue, please let me know via PM. And again, any feedback on the current design/functionality is appreciated.

Wow! This is a really cool thing, how didn't I spot it earlier?.. Is it possible to detect whether a unit is cloaked (personal cloaking) or not? The same with enshare, plague, blind, stim pack, lockdown, stasis and other unit abilities/effects.

P.S.

Quote from Roy

Don't bug me about adding new types of EUDs to the program yet (believe me, that list is long enough already). Once I push out this next release, I'll start on upgrade/tech EUDs, more unit EUDs, more text-related EUDs, key press EUDs, etc.

Oh, sorry. But upgrade/tech EUDs would be really cool and useful! Hope they are close to the start of the list =) Anyways this is really cool stuff, because I'm usually too lazy to figure out EUDs that I need for myself

Quote from Wormer

Is it possible to detect whether a unit is cloaked (personal cloaking) or not? The same with enshare, plague, blind, stim pack, lockdown, stasis and other unit abilities/effects.

Yes, the older version can even do that.

A number of those listed can be seen here:



However, cloaking seems harder as it's just a 'bit' stored among other items

Quote from Unitnode Structure

+0xDC - Status (32 bits total)
10th bit - checked for cloak?

There's no simple way to read a single bit but perhaps with a series of triggers you could accurately read the 10th bit...

Quote

10th bit - checked for cloak?
11th bit - deals with doodad states? if set, is disabled
12th bit - Unit cloaking doesn't need energy decrease
13th bit - Unit is in unbreakable code section? Cannot receive orders
14th bit - Set by nobrkcodestart
16th bit - cannot attack if set

18th bit - Is a Building?

27th bit - Invincible

29th bit - Speed upgrade
30th bit - cooldown upgrade

Assuming all other bits are empty, need to filter out bits 11-14, 16, 18, 27, 29, 30; 9 values, would require 512 triggers... bit unreasonable; Assuming 13, 14, and 16 are constant for this endeavor we're down to 6 values, 64 triggers, still don't like those numbers, have doodad state (11th) and isBuilding (18th) as checkboxes in EUDGen, horrah! 16 triggers, with something like the following method:

Need to filter bits: 12, 27, 29, 30.
8th adds 128
1st-7th add up to 127

Triggers would have to be something of the like:

Status is at least 2^12+2^27+2^29+2^30+128, status is at most 2^12+2^27+2^29+2^30+255
Status is at least 2^12+2^27+2^29+128, status is at most 2^12+2^27+2^29+255
...
...
Status is at least 128, status is at most 255

Thank you.

Quote from jjf28

Assuming all other bits are empty, need to filter out bits 11-14, 16, 18, 27, 29, 30; 9 values, would require 512 triggers... bit unreasonable; Assuming 13, 14, and 16 are constant for this endeavor we're down to 6 values, 64 triggers, still don't like those numbers, have doodad state (11th) and isBuilding (18th) as checkboxes in EUDGen, horrah!

Are those bits 13, 14, 16 really never change during the game? Then it's probably not necessary to check for 27 (Invincibility), since you can know every time if unit is invincible (unless stasis sets that flag, but even then probably not all maps use stasis). Then I think 29 and 30 only matter for Zerglings, Zealots, Vultures, Scouts, Shuttles, Observers, Overlords (Speed) and Marines (Cooldown), right? Anyways, thanks alot for the breakdown!

Quote

Are those bits 13, 14, 16 really never change during the game?

Oh I have no idea when they get changed; but whoever made the Unitnode Reference sheet must have seen or forced them to change by some means to understand what they are - in my example I simply assumed that they were all cleared, would probably require further investigation to create reliable cloak detection (also should note that bit 10 has a question mark for cloaked, casts a little doubt)

More of the bits may always be constant during a given game; the more you can say are constant, the less triggers you'll need; however having too many options in a program like EUDGen could get confusing/tedious fast. Perhaps three options for every flag, "set, cleared, either", would give the option for reducing the number of triggers in a specific map but not require the user to choose.

I was told to suggest looking into the Secondary Order ID field for cloaking. We do not know if it will work, but the Secondary Order IS is used to issue cloaking orders and could possibly be used to check them. The nobrkcode stuff in the status field has to with units pausing to execute certain animations and is changed often.