Feedback: 'Else' condition

Geo: what's the practical purposes of "inverted on every tick" and the logical/practical purpose of "inverted for" ?

Kyatric: I wasn't asking for them to be inverted, I was just saying it's possible, replying Fimbul's post above my own <img src="smileys/smiley4.gif" border="0" align="middle" /> - and saying that the ELSE on such an event should just do what currently the inverted event/condition does (which as you tested out doesn't do anything or throws error in the browser he he).

Cheers!

I think mixing different behaviors depending on the condition type involved is very counter-intuitive and should be avoided at all cost. This will cause lots of confusion in complex eventsheets.

Decomposing the problem:

In the scope of Else there is basically two types of conditions: Logic conditions and Picking conditions.

The most intuitive behavior for an Else of a Logical condition like "System: Variable=0" is just treating it like a logical inverse. For a Picking condition like "Sprite: X<320" the most intuitive behavior for the Else is picking the opposite instances.

So for an event that mix both types, the most intuitive behavior would be consistent with the previously stated.

<img src="http://www.scirra.com/images/else3.png" border="0" />

For the events above, the Else should be executed whenever the Variable!=0 and there's an instance of Sprite>=320, picking any instance of Sprite that meets the new criteria. This behavior is very straight-forward and easy to follow, and should cover most situations.

What is breaking the logic above and causing trouble is the fact you are trying to accommodate this type of situation without always returning 0:

<img src="http://dl.dropbox.com/u/7871870/construct/Else-normal-01.png" border="0" />

For this variable not be always set to zero, the Else needs to run only when it's parent event is False, and not parallel like the more intuitive way.

So the real problem is not related to picking, but if the Else should be executed parallel to it's parent or just when the parent is False. For most situations running parallel is more intuitive, but there's this exception where it can add further functionality.

You can quickly solve any confusion by limiting the Else to work with only one of these cases, but the optimal solution would be to allow both. So for an optimal solution what is needed is a mechanism that allows the user to choose which situation he desires: execute in parallel, or just when the parent event is false.

A way to allow this is by adding the above options when placing the Else (maybe a dropdown), and showing it's state (type of execution) in the Else condition.

Another possibility is to use the positioning of the Else in relation to it's parent to change the execution type:

-if the Else is in the same level as it's parent, the Else runs parallel;

-if the Else is placed as a sub-event of it's parent, the Else runs only when the parent is False.

Following this logic this would always set the Variable to 0:

<img src="http://dl.dropbox.com/u/7871870/construct/Else-normal-01.png" border="0" />

While this would set the Variable to 1 or 0 depending on the Variable value:

<img src="http://dl.dropbox.com/u/7871870/construct/Else-subevent-01.png" border="0" />

There should be more ways of doing this, these are just the ones I could think right now.

Independently of the final solution, I agree with Fimbul that the Else should be listed in the right-click menu. It would act similar to an "Add blank sub-event", but adding the proper Else below the current event instead of a blank sub-event.

*Edit: added images for better demonstration and improved the explanations.

Animmaniac,

i like this 'method'. basically a 'hierarchical else' event. if i understand you correctly.

i think it may solve ash's main problem, which is to keep the solution as elegant as possible. meaning, no multiple 'else' event statements. instead of that, you have implemented one 'else' with multiple event states, that mirror the intended use. am i reading you right so far.

it seems like this could solve the problem ash talked about with nested or stacked 'else' events. you could conceivably mix and match the usage to fit the functionality intended;

event: condition 1

else> event: condition 2

      else> event: condition 3

            else> event: condition 4

else> event: condition 5

if i understand your logic than this event course can be built where;

conditions 1, 2 and 5 are assessed in parallel while conditions 3 and 4 are optional choices of condition 2

am i seeing this right?

Yes, that's right harrio. Although I wasn't accounting for an ElseIf, it can be extended that way.

I believe Switch logical statement would have solved at least one problem beautifully.

+ SWITCH: Sprite.Variable1
 + CASE: Sprite.Variable1 < 0
 > do something
 + CASE: Sprite.Variable1 >= 0 AND < Sprite.Variable1 < 1
 > do something else
 + CASE: Sprite.Variable1 >= 1
 > do something completely different

+ SWITCH: Sprite // picking pool
 + CASE: Sprite.X < 0
 > Sprite: Destroy
 + CASE: Sprite.X >= 0
 > Sprite: Sprite.X - 120*dt

Great thinking, Mipey. I like that one better.

Mipey, isn't that identical to just using a series of subevents with different comparison conditions?

What if you alter the variable you are comparing? The switch should take a snapshot and perform comparisions with that.

Then you can just put the variable in a local variable, right?

Can you save SoL in local variables?

No, but I'm not clear why it needs to?

Sometimes we need to do actions on different subsets of objects. We could do that with separate events and conditions for each subset, but altering one subset may consequently alter the total object SoL for the next event. That may not be desirable.

An else if would be good. Also visually I think the else statement has to be indented. Either that or the entire else's background should be a different color.

I think from an organizational standpoint there should be something visual to separate the if else statement.

Hmm, having thought on this some more I think I'm persuaded by the "keep it simple" argument.

Initially I'll release it as a logic-only "last event did not run". We'll see how things pan out there.

Hmm, having thought on this some more I think I'm persuaded by the "keep it simple" argument.

Initially I'll release it as a logic-only "last event did not run". We'll see how things pan out there.

Yes, but it won't be a simple condition, right? That way lies madness.