# Feedback: 'Else' condition

Discussion and feedback on Construct 2

### » Mon Apr 09, 2012 4:17 pm

If I remember correctly, multimedia fusion 2 has two kind of "or". An or "logical" and an or "filtered".
Even with the experience I have with mmf2, cc and c2, I think I really understand this design choice now (well I dropped mmf2 long ago...)
Anyway, if it's that hard to understand, it's probably not a good choice.
So, I don't think having a logical and filtered else would be a good idea...
B
71
S
22
G
14
Posts: 1,494
Reputation: 16,660

### » Mon Apr 09, 2012 4:38 pm

[QUOTE=Kyatric] @Geo: what's the practical purposes of "inverted on every tick" and the logical/practical purpose of "inverted for" ?[/QUOTE]
@Kyatric: I wasn't asking for them to be inverted, I was just saying it's possible, replying @Fimbul's post above my own - 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!
B
14
S
5
G
8
Posts: 235
Reputation: 5,675

### » Mon Apr 09, 2012 8:25 pm

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.

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:

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:

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

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.Animmaniac2012-04-09 23:28:10
Scirra Employee
B
175
S
55
G
17
Posts: 711
Reputation: 18,577

### » Tue Apr 10, 2012 12:31 am

@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?
B
81
S
32
G
24
Posts: 1,053
Reputation: 36,465

### » Tue Apr 10, 2012 3:44 am

Yes, that's right harrio. Although I wasn't accounting for an ElseIf, it can be extended that way.
Scirra Employee
B
175
S
55
G
17
Posts: 711
Reputation: 18,577

### » Tue Apr 10, 2012 10:23 am

I believe Switch logical statement would have solved at least one problem beautifully.
[code]
+ 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
[/code]

With picking and all that.
[code]
+ SWITCH: Sprite // picking pool
+ CASE: Sprite.X < 0
> Sprite: Destroy
+ CASE: Sprite.X >= 0
> Sprite: Sprite.X - 120*dt
[/code]
The above example is basically an IF statement with ELSE. Sure, all conditions are checked, but that's a small price to pay for elegance and practicality.

Before you say that this is what events and conditions already do, switching makes sure the variables it compares are immutable (so you don't do things like compare X = 0 and alter the X in the same step, which can cause oversight bugs)Mipey2012-04-10 10:31:29
B
62
S
21
G
13
Posts: 1,910
Reputation: 13,685

### » Tue Apr 10, 2012 10:51 am

Great thinking, Mipey. I like that one better.
B
25
S
8
G
7
Posts: 184
Reputation: 6,050

### » Tue Apr 10, 2012 4:20 pm

@Mipey, isn't that identical to just using a series of subevents with different comparison conditions?
Scirra Founder
B
415
S
248
G
92
Posts: 25,288
Reputation: 200,960

### » Tue Apr 10, 2012 4:23 pm

What if you alter the variable you are comparing? The switch should take a snapshot and perform comparisions with that.
B
62
S
21
G
13
Posts: 1,910
Reputation: 13,685

### » Tue Apr 10, 2012 4:26 pm

Then you can just put the variable in a local variable, right?
Scirra Founder
B
415
S
248
G
92
Posts: 25,288
Reputation: 200,960

PreviousNext

### Who is online

Users browsing this forum: No registered users and 12 guests