It's nice that switches default to `Set` in conditions. Can we have that happen in actions, too?

They don't default to 'set'. However any trigger parameter you configure when editing a trigger is remembered, and if you need the same parameter again it is set to the previous value. So if you create a condition which uses "Terran SCV" and "Location 20", then all subsequent conditions / actions use those values to populate unit and location fields.

Unfortunately the values for "Set switch" and "switch is set" are different, so it remembers that setting differently for conditions and actions.

Can we just have it default to Set if there's no remembered value?

Not right now - want to make a official release with no changes if no bugs are reported.

Medium term, I want to add support for tabbing from field to field in the trigger editor, and once that is in place that could get default values that are selected if you hit enter. (So tab, enter, tab, enter, etc to populate the trigger)

Here's a minor bug: if you select Memory action or condition in classic editor, it initially displays as "deaths", and you have to change player to -1 before it updates to the input that allows the address to be entered. Also the memory condition is just "memory condition", it should be "EUD: memory condition", or whatever so that it mirrors the set memory one.

When entering an address, it requires the format to be 0x with 8 digits - it should be able to interpret any value as long as it has valid hex characters. I've been copying and pasting values from calculator which just gives 6 digit values, so I have to prepend 0x00 onto everything I enter, which takes longer.

Also the default value for the modifier field for memory actions is "set", which is ambiguous because its not actually a valid option, but "set to" is. So you can add a new action, and think you've filled in all the values, and wonder why it won't let you click "ok" to continue. I think defaulting to "set to" in this case would be fine.

For new conditions/actions, if you select memory it will immediately display as memory, it only switches to deaths if you manually set an offset into the death table. The only quirk is if you had previously set a player in a different condition/action, it fills that value and may toggle morphing the type of line.

I already changed the condition name a few days back.


I most likely won't make it auto parse depending on the presence of hex characters, that has a high likelihood of confusing people. (e.g. 0000A000 is hex but 00009000 is not hex is not self explanatory)

I can enter numbers such as 0x1234 just fine. The address needs to be a multiple of 4 in order to be valid though.


All trigger parameters are initialized to not being set and display some default text, using similar text to staredit. In this case the default text for a "Set Type" parameter is "Set"

Post has been edited 1 time(s), last time on Mar 11 2018, 9:18 pm by Suicidal Insanity.

I wasn't clear, but this is for newly created conditions/actions. I'm at work so can't test right now but will have a play tonight and confirm exactly what operations I'm doing, I might be doing something slightly wrong.


How is 0000A000 hex and 00009000 not hex?

It's a hex field, so values put in are interpreted as hex numbers. Just like text fields interpret data entered into them as text, even if you put numbers in, it's still text.

Calculator will support you pasting in a value of 0x1234 or 1234 and will correctly interpret it as hex. I'm suggesting scmdraft behave the same, for fields that are explicitly typed as hex. IMO calculator should always display 0x on the front when in hex mode, but it doesn't (scmdraft does, so is doing it right).

I don't specifically recall trying just 0x1234, all I noted is that a straight paste wasn't working, so put 0x00 on front and that fixed it.

Yes I realise that, and it's confusing. If you don't want to default to "Set to", then there are other alternatives that would be clearer, for example [Unset] or [Choose] or [Select]. Hell even putting [Set] is better than Set, since it's immediately visually clear that you haven't changed the value of that field from the default one.

Minor feature request: when clicking to edit a new trigger, it would be good if the edit dialog can open on the same tab as the most recently closed trigger edit. Right now it always defaults to the players, which 99% of the time is not what I'm interested in - I'm wanting to change conditions, or more often actions. Especially since it now supports multiple edit windows at once, it's an annoying extra mouse click when you open up Trigger 1 and click to the actions, then you want to compare this with trigger 2 and so open it, and have to click on the actions tab again. This is very similar to your re-cycling of previous input that you've implemented, but also applying to tabs in newly opened dialogs. There's is the small snag in how you default the tab view - to the last trigger window that was closed, or to the one that was the last focus of the user's selection, I'm not sure which is best in practice and/or easiest to implement.

Its not a hex only field though, if you don't prepend it with 0x it is interpreted as a decimal value. It just defaults to hex format. Its much the same as text trigedit does it.

Editing multiple triggers at once has always been in there. I can see about syncing the default tab when a new window is opened. Three options though
- Last tab the user explicitly clicked on
- Last visible tab before closing
- Last visible tab in the last active window.

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

Why not make it a hex-only field? Why is someone trying to enter a decimal into a field that is intended as a memory offset? The EPD field is the one that should take a signed integer.

So the difference between 'last tab the user explicitly clicked on' and 'last visible tab in the last active window' is someone can open 2 windows, put A onto conditions and B onto actions, and open trigger 3 and if doing 'last click' it will always open on Actions, and if doing 'last active window' it's behaviour depends on which of A or B they most recently had focus on?

I think it's impossible to know exactly what the user is intending to do when they open the 3rd trigger, so the behaviour should be the one that's most intuitive. Last active window tab is probably the best, since you may have done the tab-clicking many minutes ago, but the active window is presumably what you've just been looking at.

That's why I added the option you didn't mention, since that makes the most sense fore me.

I have practically no experience developing GUI applications so I'm not familiar with what's easily possible vs what's impossibly difficult, and so that option didn't occur to me.