Just in general an option to collapse a commentless trigger would be useful.

Huh, you're right, I just tried it and it does. I have no idea WTF I was thinking. Spent a long time typing all that out, too...

Playing around with the option dropdowns - right now they are set so they don't disappear if you hit enter or click outside of them when an invalid option is selected, only escape will close them. Should clicking outside also close them and discard the types (invalid) value?

Please make it so that you don't have to have at least one player/condition/action to change tabs.

I had removed the 1 condition / 1 action requirement a while ago. I won't remove the 1 player requirement until the parent UI has some way of displaying orphaned triggers (So those with no players selected)

Ahh, haven't used like the last 10 versions so I didn't notice lmao. Also, I feel it'd be fine if you just made it so that the trigger couldn't be made if no player is selected (disable the OK button or something).

Is this where we request making all strings not used by the game not count towards the string limit? O_O

Any chance of raising/removing the trigger condition/action limit?

Also, mirroring my query about custom trigger conditions/actions. I know you're planning to add EUD-specific ones, so I'll throw in a few personal requests. Some are/may not be EUD related, and some may require mod support.



Lastly, if modders wish to add custom trigger data (as will probably be necessary for some of the above requests), how should we go about doing it? Presumably we'd have to wait until you've finished the update to the editor.

Post has been edited 2 time(s), last time on Feb 16 2018, 4:08 am by Pr0nogo.

I have some ideas which I may try to achieve this while retaining backwards compatibility to plugins that I mentioned earlier. I am not sure if they actually would work well though, so no promises.

Not really, the trigger struct sizes are hardcoded. EUD maps do that by manually changing the next trigger pointer, which is beyond the scope of scmdraft. At some point in the future I likely will add access to a bunch of scratch vars backed by EUD data which should ensure you don't run into the switch limit though.


For now I only plan on adding EUD triggers/conditions that affect data with a fixed offset that is DWORD sized. Unfortunately most of your examples aren't things that can be done via a single EUD condition/action, but require many triggers to accomplish.



Its unlikely I'd make the trigger editor modible. I'll definitely take requests for simple EUD triggers/conditions that meet the above criteria (DWORD aligned, fixed offset)

Cool! Make sure to mark them somehow so it's obvious what a classic condition/action and what an EUD is.

I currently have two implemented in the latest alpha, and they both are named "EUD: "[...]

Question: Should closing the text editor in classic trigedit via the [X] button save the updated string, or revert changes? Right now it is treated as cancel.

Just disable the X button and then there's no ambiguity

Having a hotkey (like ctrl+enter) to save and close would be good.

Or it could pop up a message box "Would you like to save your changes?"

Ugh, that's worse. When people click x they generally just want to get out of wherever they are. So disabling x isn't a great solution, but nagging people with popups is just annoying.

Ya and it will be followed by "Are you sure?" "Are you completely sure" "Do you maybe want to change your mind?"

Somewhat tempted to remove the auto EUD trigger action / condition morphing code, now that the UI caches the last entered values on trigger action / condition type switch - thoughts?

I'd be in favour of dropping that.

One thing I've come across and I don't know exactly whether it's TrigEdit doing it or TrigEditPlus (since I've been collaborating with someone else on their map and not sure what they are doing with it on their end) is that my EPD actions, eg "Set Deaths("Int:334773", "Terran Marine", Subtract, 2147483648);" are getting morphed into classic EUD equivalents, which is annoying, eg it becomes (at some point) "Set Deaths("Player 10", "Int:27897", Subtract, 2147483648);".

If TrigEdit is doing this in some manner, it'd be great if it didn't.

That seems to be the problem of TrigEditPlus. That's intended one. Someone requested that because old SCMDraft were not very happy with EPD actions. IIRC the classic trigger crashed w/ epd actions.

Since TEP converts all EUD conditions/actions to Memory/SetMemory, I don't think there's any much bad consequences for that.

Could you change it to not do that? Maybe make it a menu option if you want to support new versions of TrigEditPlus on old versions of Scmdraft (not sure that's a realistic combination to support, though).

It's incredibly annoying having all of the values changed from what I originally entered - anyone seriously doing new EUD maps in particular won't be using old versions of scmdraft because of the earlier limitation, as well as because it had bugs that simply destroyed any values >= 2147483648 anyway.