Would love EUD support with Draft

More like parsed EUD support. i.e.
"<Add|Subtract|Set> <number> to <location>'s <left|top|right|bottom> attribute."
"Set <location> flags to <locationFlags>."
"Set <slowest|slower|slow|normal|fast|faster|fastest> frame time to <number> milliseconds."
"Set damage multiplier for <damageType> against <sizeType> to <number>."
"Set button page for <unitType|extra> to <buttonset>."
"Set fog of war update counter to <number>."
"Set trigger update countdown to <number> frames."

"<Add|Subtract|Set> <number> to unit id <slotNumber>'s <attribute>."
"Unit id <slotNumber>'s <attribute> is <AtLeast/AtMost/Exactly> <number>."

.. Then there's all the other stuff for max supply, DAT properties, and presumably more.


EDIT:
You can change "current player" to work for p9-12, effectively emulating or running triggers owned by those players by changing the current trigger player variable (mentioned in my prev post). I'm assuming you can do the same for players that are not currently playing. You could also turn an empty player slot into a computer and make them take the position of that player.

You can set p9-12 to rescuable, which I think is super useful, so that it doesn't take a player slot. You can give a unit from p1-8, retaining the original colour, and then rescue it from p9, also retaining the original colour. So you can make things super confusing and rainbow if you wanted to.

You can also run junk yard dog and some misc. ai scripts for p9-12 if you make them a computer. Full AI scripts will crash the game however.

EDIT2:
You can turn off the stars in space tileset by changing the tileset id. Similarly you can turn on stars for other tilesets (only appears over null/black terrain) by setting the tileset id to space.

Post has been edited 3 time(s), last time on Dec 10 2017, 3:13 am by Heinermann.

How does that player colour deal work? Has it always been if you give a unit to a rescuable player, it remains the original colour? Or is the behaviour you're describing a generic result of changing a P9-12 player to rescuable, or did you do that + some other specific changes to make the colours sticky?

This would be quite neat for Desert Strike, if the computer player controls the units but they retain the original player's colours. Would let you distinguish between 2 zerg players on your team for example (and give you an idea as to which of them was contributing the most to the game).

That's specific to p9-12, which retain the colour it was given. Unfortunately it's not possible for computer players to "rescue" other players. HOWEVER, you can change the computer to HumanOccupied to rescue them briefly, and then change it back to Computer. This will break any AI scripts being run though.

It has EUD support, both in classic and text trigedit, but only using raw offsets. Parsed EUD support is on the long term todo list.


You can change a specific unit's color with EUDs by just updating the player color field of the unit struct. Takes a bunch of triggers though.

Post has been edited 1 time(s), last time on Dec 10 2017, 10:33 am by Suicidal Insanity.

Since many things require *huge* amounts of triggers that contribute to overall trigger lag, I wonder if there is a way to make some triggers completely disabled for a period of time? With "completely disabled" I mean somehow they aren't even considered to check their conditions - completely skipped like there are none.

I think you can use EUDs to set the 'Disabled Trigger' bit in triggers

That's doable with eudplib. I'll write some tutorial later if I can.

Oh, thanks, trgk! I will appreciate. Though, I mean to disable a big chunk of triggers without requiring even more triggers to do that

SI, oh you're making me think to disable/enable a Never condition through EUD, but flag is better :-)

Do you guys think a disabled trigger flag would help against trigger lag? I mean how much effort is taken to see if trigger is disabled this way or to test switch in conditions for instance?

Since I believe non-preserved triggers are considered disabled this way, I can actually do some tests to see that.

I think the tool trgk mentioned may even be able to remove // add em to the linked list of triggers.

Oh I have been using it since added, but yeah it's pretty crude. You also cannot use the text editor with them, it gives back invalids.

Not entirely sure what you mean - but lets figure that out in PMs.

I've only done stuff with EUD's but the googledoc uses EPD's. How do I do stuff for specific Unit Index's, e.g. there is unitsdat_UnitDirection with EPD 219299. The next thing after this is unitsdat_isBroodwarUnit, which starts at 219357.

However I know there are more than 58 possible Unit Indexes, obviously, so... how do you reference a unit's direction, given that Unit's Index?

For example, would doing "Deaths: ('Int:219299', "Zerg Zergling", "Exactly", 18)" reference the Unit Index that is (whatever the Unit ID of Zerg Zergling is)?

Uploaded a fix for classic trigedit for both player and unit ID parsing.

Is whatever property that makes P9-12 retain the original unit colour, EUD controllable, so P1-8 could be modified to have the same behaviour?

Those values are 1 byte and a death is always 4 bytes, so 4 values are in each death. Also using a unit other than marine will very much break it.

I don't think so. You could do what SI suggested and change the owner property of the unit structure though to get the same effect.

Is that realistically possible if you've just created 100 units in a particular location and you want to change the ownership (colour) of them all?

I thought the unit structure stuff for EUDs only really works for pre-placed units, or if you know the precise order that the units are created in-game. Neither applies for my use case.

Possible? Very much so. Realistic? Depends on the tools you're using I guess. I didn't think it through when I wrote that.
For it to be feasible you'd need 1700 triggers, one for each unit slot. You would then check that their x/y is within a specific range, and then set the owner. But given that the owner is 1 byte, it would be more feasible to know the prior owner (you need to create the unit for the player whose colour you want, and then change the owner to whoever will control the unit). You could probably create it in several locations to distinguish the original owners because IIRC just setting it to whatever will throw up that EUD error message. Otherwise you would give it to one of p9-p11 and then change the owner from there.

Alternatively you could use the current player trick to cut down on the number of triggers, but iterating the entire unit array would be slow. You can supposedly keep track of the first empty unit pointer, and if a new unit is created it will fill the slot, and then you can iterate through each next pointer, but I have no idea how it would be done efficiently if those fields are marked as readonly.

Sorry I'm just throwing out random ideas, had no idea it would be that involved. IMO using one of p9-p11 as a rescuable player seems way easier.

Except I ultimately need the rescued units to be controlled by a computer player (currently P4 and P8 in the map), and swapping those players to be human so they can rescue the P9-12 units isn't really feasible if it breaks AI behaviour - I'm assuming that would include any currently active 'patrol' command orders? Or did you just mean AI scripts?

I think the best option here is to re-write the map so that P9 and P10 are the active computer players. Would actually allow the game to become 4v4 instead of 3v3 as well.

Would be quite a lot of work though, since there are a variety of systems that rely on the computers being P4 and P8 (vis-a-vis their relation to the human players in 1-3 and 5-7), and also P9-P11 DCs are used for various systems as well.