Of course, experienced users see that this sets X to 1 then immediately back to 0 in the next event. However, using 'Else':
+ If X = 0
-> Set X to 1
-> Set X to 0
This works as intended, toggling X between 0 and 1. However, your proposal to make 'Else' the equivalent of the inverted previous event will break it again, making it work like the first example![/QUOTE]
A bit off topic I agree, but perhaps some experienced users aren't aware of the "short" version of toggling between 0 and 1 without ifs:
Set X = 1 - X.
Now back on topic, after reading more here's my suggestion:
For logical conditions, ELSE should be "programatic" else, i.e. did it execute or not.
For Picking conditions: "Else" picking should be done at the same time as the "IF" picking and should be the exact opposite. So let's say you have 5 sprites, 1 on the left of 320, and 4 on the right, then you do:
Sprite->X > 320 -> do something
ELSE -> Do something else
it should execute accordingly. BUT, IF in the "do something" you move some sprites, then the "ELSE" should not pick those sprites, even though by the time the flow gets there, they match the ELSE too. Think of it like "programatic" if on a "per instance" basis.
Like: "For these instances, did the logic under IF execute or not? If yes, don't pick them on the ELSE, otherwise, DO pick them, REGARDLESS of what happened to them and whether or not they match the inverted condition as well by the time the "flow" gets there"
This as far as I can tell is the most "honest"
implementation of ELSE.
And @Fimbul, the else in your scenarios should do exactly what the inverted does currently. You can invert "Every tick", "For" etc currently, I didn't try to see what it does in practice, but you can invert them and the ELSE for those should do exactly what the inverted does currently