Default values when you set parameters for actions/conditions - alternative modification sign component proposal

[blurymind]

Description

Whenever you create a new action/condition, very often there is a modification sign entry box that is left empty by default.

There are two problems with it atm:

1. It's set to nothing, so the interface is not trying in any way to guess that for you - so you always need to do that step. over 50% of the time you want it to be =
2. It's a dropdown menu, which means that it requires several steps to set - not one. You have to move your mouse, click, move the mouse and click again. In that case it really doesn't need to be that way, since there is plenty of space there.

Solution suggested

My suggestion for the modification sign there is to turn it into a different component that requires only two steps, not 4 (move mouse over it, click).
Set the default value to =, so there is a good chance that it guesses what you want to do for you and you can entirely skip setting it at least half of the times.

This also solves the problem with the bloody dropdown covering the input field for the value right below it. What is even worse is that the dropdown sometimes covers an area around the modal pop up that when clicked closes the parameter editor and loses your edits entirely. So what tends to happen is I click twice on the modification editor - the first click applies the modification, the second click closes the parameter editor and loses all of it's settings.

If you like that suggestion, I can later on do a pr on it? :)

The other suggestion is to populate these fields with a default value whenever we can guess it in advance. Can you think of other fields that can do with a default value?

I think the field expecting a string can have "" as default value for example, but we can try and think for other cases here.

[4ian]

Setting a default value would be great yeah :)
I started doing improvements on these parameter fields so that error messages are less hard to miss and other smaller improvements.

I agree that this field is sub optimal. Code generation will use "=" as the default operator if nothing is set, so you can use as a default value if no valid value is entered (same for the relational operators, == is the default).
I'm not sure about your mockup because it looks to close to the player and so could be interpreted as something related to the player by beginners. But feel free to try something! :)

[4ian]

I think the field expecting a string can have "" as default value for example, but we can try and think for other cases here.

So it's a bit more subtle.
String (and expressions) don't have a default value. Meaning that if you don't enter anything, they are in an "invalid state", i.e: clicking on the field and clicking outside will show an error message.
It's important because here we can't give a sensible default, it's almost always up to the user to enter something meaningful.
BUT we do display "" as a "hint text" (in gray) for string expressions to remember the user about how to write string expressions (basically, don't forget the quotes around the text).
And it's also a good thing because code generation, in case an expression is invalid (i.e: syntax error or empty expression) will generate either 0 (for numbers) or an empty string ("").
(So yeah you could say that 0 or empty string is the "default value", but it's more the value used to represent emptiness in case you've put something invalid or empty - this is done to avoid completly breaking the game).

More generally, you might think about what to do with selector (material ui's <SelectField>) if you think they are suboptimal.