The next project on my list is cleaning up, refactoring, and improving classic trigedit. This code hasn't been significantly changed since 2007 or 2008, so it can use a bit of work. This may include partial unification of the internal logic with text trigedit in preparation for an overhaul of that in the future. I've got a couple of 4-5h train trips coming up which I plan on using to sketch out a new design.

Before I do that I wanted to gather requests for changes to classic trigedit in a dedicated topic, so post suggestions and wishes here. Post non-trigger related stuff in the normal thread.


EUD Support:
Tentative plans: Detect EUD conditions / actions as any death condition or action that has either player number, unit type overflowing the corresponding limits, or has the combined offset overflowing the table.

When changing the address, the existing unit type will be kept, and the player group will be set to an appropriate value.

Post has been edited 1 time(s), last time on Jan 21 2018, 3:48 pm by Suicidal Insanity.

Great news! This goes both for classic and text trigedit. Wish deaths/memory conditions (and actions now?) were different from each other. The logic to detect memory for only Terran Marine fails sometimes - you put deaths and read a memory condition. Is there a way to mark some unused hidden bit in the condition (or it's data?) somewhere to completely separate those two?

Added info on how I plan to detect EUDs in the future. I hope that will fix that issue. Let me know if you think it won't.

Make window non-modal;
Place copy of action under target action, not at the end of list (like whole trigger copying works);
Ability to use default units names;
Maybe some sort of searching by comments?

sorting by comments

There is an annoying bug when trying to click small text fields. For example, a single digit number. You have to click over the exact spot for it to work properly. Making the clickable space would be amazing. Another is the drop down boxes. If you type Terran M and meant to type a N you have to click out of the field and try again. It prevents you from backspacing the text in the field if valid unit was highlighted. And finally, when you type in a drop down box and have a unit highlighted hitting enter doesn't select the unit and close the box. Also.. If you have a unit selected and click out of the box that selection isn't saved (it should).

Edit: Another cool feature or option would be make the set memory action in the classic editor act as a giant text field instead of set fields to type in the memory info. A comment box would be ideal so you can just copy paste the trigger in.

Random question: Is there any use to directly setting sound strings, without using the sound editor? Basically direct virtual sound support.


I have rough plans on how to enable this, however plugins would not be launchable while a trigger editor is open. (To prevent race conditions).

This is easy to change. Depends on what the consensus is for where a copy should go. Does anyone else have thoughts?

I can add that to the idea list.

Searching or filtering should be possible. Sorting would break any trigger order dependent effects, so I think that is too dangerous to support.



Ya, the UI will get an overhaul. Including spaces should be easy, and I think that may be how staredit works around the same problem. Fixing enter + click should also be possible. Backspace in the autocomplete fields is a difficult problem


And how would it be parsed? Using text trigedit formatting?

And how would it be parsed? Using text trigedit formatting?
[/quote]

Trigedit formatting or just take the memory address and the number at the end. Like this..


SetMemory(0x6635D0, SetTo, 16842756);.

Did you read what I replied to you in the shoutbox? Sorting should be only a visual thing, not change the real order. While in sorted mode disable move trigger buttons. Then have a way (maybe make it radio buttons?) to change back to real trigger order.

Also, is it possible to make ability to copy conditions and actions to clipboard, and paste then into another triggers? Would be very useful for EUD.

I don't think that would result in a very intuitive UI. Maybe I'll give it a try, likely I won't.



I will add it to the list. Isn't completely trivial because it needs to include trigger text, unit properties, etc, but definitely is doable and sounds like a sensible request.

You think?

Didn't bother to actually show a sorting difference, but you get the idea. Also should probably say "View sorted by Comment", but yeah just a quick mock up.

Change triggers background color to pale yellow or something and it will be obvious. But what the use case would be for this feature?

Any map where you use comments for triggers, to quickly find triggers belonging to that system, even if order forces them apart.

But filtering by comment would work for that use case, and cover others as well, without having to worry about order

I agree that placing the copy of the action under the target action would be better than at the end of the list.

I'd prefer it as an option. Would it be possible to have a checkbox next to copy? In some cases it makes more sense to copy below and others at the bottom. Like for a bound.. Copyimg below for am obstacle would be a nightmare.

A UI request that might be specific to me, but maybe not.

I have lots of small trigger systems in my map, where there'll be some system that requires 5-30 triggers (although some are much larger) to implement. The way I do this is by putting a comment on the first trigger that explains the system and how it works, and then for the subsequent triggers I put a comment with an empty string, simply to hide them so they take up less space in the editor, as well as reduce a lot of visual clutter and noise. This way I can scroll through my trigger list and fairly quickly locate the particular system I'm interested in.

This works well enough, but sometimes I need to debug the trigger, and I do things like add "create [unit] at [location]" actions to them, or display text actions etc. Some times I may alter conditions or actions more substantially, such as changing the DCs in use or changing the way locations are used. The problem with this approach is that if I stop mapping for a day after I've added these debugging things in, then I need to remember later to remove those debugging changes and revert the trigger back to its original state.

What would be really handy for me, is if when a comment was unchekced in the trigger actions, that the comment would no longer display in the trigger list. This way, if I'm debugging triggers, especially if there are multiple triggers being debugged at once, when I scroll through the list of triggers I will immediately see the triggers that I've been working on, because they won't be hidden by a comment.

At the moment the only way to achieve this is to delete the comment - this is fine if it's one of the triggers that had an empty comment to begin with (although a bit annoying having to re-add the comment action back later), but if it was one of the comments that has actual text describing what the trigger is doing, it's not a realistic option.


So in summary:
If you uncheck a comment action, then in the trigger list, don't show the comment text, instead show the normal trigger conditions/actions summary view.

I believe this is how StarEdit does it. I didn't realize SCMD didn't already, so I think this is a good idea. XD

ScmDraft always has done it like this ....