Feedback: 'Else' condition

I've been thinking about the 'Else' condition and how it ought to work. I found some difficult points so I thought I'd post for feedback on how you think it should work.

Case 1: logic only

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

This is a simple case: the 'Else' runs when 'Variable1' is not equal to 0. In other words, the 'Else' condition is identical to a 'Variable1 not equal to 0' condition, or "If last event did not run" condition. No objects are picked in either event.

Case 2: picking

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

IMO, this case should work differently to case 1. If it is 'logic only' (runs only if the previous event was false), the 'Else' will never run at all if there is a single instance with X < 320. It looks like the intent with this event is to make objects on the left faded out (opacity 33), and objects on the right normal (opacity 100).

So this event should run like so:

1. Test if any objects have X < 320.

2. Make those instances opacity 33.

3. In the 'Else' event, invert the picked objects: pick all objects with X >= 320.

4. Make those instances opacity 100.

Note this is different to the first case: the 'Else' event still runs even if the previous event also ran. The 'Else' event would only not run if all instances have X < 320, so there are no instances with X >= 320, so there is no need to run the event. So this is different to "If last event did not run". It's more like "Invert the picked objects and run if some are left".

Case 3: mixed logic and picking

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

This is the difficult one: when should the 'Else' condition run? Which objects should be picked in the 'Else' event?

I'm not sure what the intent of these events is if someone made them. I can think of two possible answers:

A) Treat as case 1: simply run if the previous event did not run.

Problem: 'Else' never runs if a single instance has X < 320. This could be annoying, because maybe the intent was the same as case 2. It could also be confusing since 'Else' running depends on whether the previous event has a system condition. So adding a system condition to case 2 suddenly makes it run like case 1.

B) Treat as case 1, but tweaked:

• if Variable1 is not 0, run the Else with all Sprites picked.
• if Variable1 is 0, run the Else with sprites with X >= 320 picked.

Problem: this is so complicated I'm getting a headache trying to figure it out. The sprites picked in the 'Else' event changes depending on the truth of a system condition. And the 'Else' event can still run even when 'Variable1' is 0 which is pretty counter-intuitive!

C) Treat as case 2: pick all sprites with X >= 320, and run the 'Else' event if there are any instances there.

Problem: The 'Else' condition can still run if 'Variable1' is equal to 0! So the text is always set to "Some other text" if a single instance has X >= 320.

D) Maybe something else I haven't thought of?

I'm siding with option A) because it is the easiest to understand. Basically it means

• if there is a system condition in the previous event, 'Else' means 'Last event did not run'.
• otherwise, 'Else' means 'Invert which objects are picked and run with those'.

You can then make it pick instances by rearranging in to a subevent like this:

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

It's now clear that it picks the instances in the Else event.

This avoids 'Else' still running if a system condition is false. However, it still seems a little complicated to me. It's supposed to be a conceptually simple event that is easy even for beginners to use, but the rules of how picking works still take a bit of thinking and possibly rearranging in to subevents to get it working how you want.

Does this design for 'Else' sound straightforward enough even for beginners? Will it "just work" and do what you want or do you think you'll be tripped up by the change in behavior when adding a system condition? Is there some other way it could work I'm missing? I'm surprised how complicated the exact definition of this seemingly simple condition is.

I'd prefer to only have one kind of 'Else' condition which works intuitively, just like you expect it to. I'd really prefer not to have two different kinds of 'Else' condition.

I can't remember exactly what Construct Classic did, but I do know it was too buggy to use in any serious capacity. (Obviously I want to make it bulletproof in C2!)

Let me know if you have any thoughts.

Well I haven't got any experience in programming but for me it sounds all fine.

The else should work as just being inverted action.

Example

If both variable 1 = 0

and x < 320

then

set text "lol" and opacity 33

else

set text "hi" and opacity 100

I think both conditions should be met for else to work.

This is kinda no use.. as it's above so basically I think both conditions should be met before else works.

This is not hard at all and I think it would great feature in construct 2

If YOU'RE having difficulty following what's going on in parts of what you wrote, not to mention I am too and I've been using construct for about 5 years, I think it's not a good idea! Construct is supposed to be intuitive and simple, and I think else should be that way as well.

Another problem with option 2 - what instances would it select the inverse of?

• Sprite x < 100
• - Sprite2 x < 100
• - Else

Would it invert the selection of all objects that have any selected instances? It just seems... messy and hard to control somehow.

What if, for another option, there were more controls like the 'pick all' condition? Something like 'invert picked' and then an object selection box so people had more control manually?

I understand why you don't want to have multiple elses or multiple else modes, but I personally would want it to work like this:

Have a parameter drop-down menu (or two elses) so you could select between "run only if the above event doesn't run" and "run anyway" - neither of which do any picking, and then are combined with the 'invert picked' condition above. It's as simple and flexible as I can think of.

Actually, come to think of it - an 'invert picked' condition would basically be an else if placed as a subevent, wouldn't it? Maybe THAT could be option 2 and else could be simply "run if above event did not run." Then we can have both!

Edit: Er... except it wouldn't work like an else if the parent event didn't run. Hmm.

Edit 2: Okay, if you combine a "last event did not run" with a copy of the condition of the above event with a 'invert picked' that could work.

Another problem with option 2 - what instances would it select the inverse of?

- Sprite x < 100

- - Sprite2 x < 100

- - Else

It would only invert the picked Sprite2s. IMO it makes no sense to change the picking on any objects other than those referenced in the previous event's conditions.

I really want there just to be one 'Else' mainly for elegance. It just seems like there should be one option that does everything you'd expect it to. If there were a programming language that required two versions of 'else' because it could not make one that did what you needed, I would be inclined to think that's a badly designed programming language. So it's a bit of a philosophical point.

I think the initial release will be option A, but this is still open to discussion. I think real usage and any bug reports or confused users we get will be useful information.

Yeah, makes sense. I'm leaning towards option 1 at the moment then as well.

I do hope you'll consider the 'invert picked' condition I suggested though - I still think that way we can have both options functionally, and it's not actually two elses.

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

for me, this one (option A) looks the most understandable and logical

But the sprite event should only run if Variable1=0

Option 1 seems the most logical I guess, but I'm thinking it's probably going to get a bit confusing especially for beginners - although I don't think you can really get round that.

I'm also trying to see the advantage of even using the Else condition over normal inverted events, other than maybe saving a few seconds of time, and making events looks slightly more confusing...

I'm not even sure "else" is needed. Personally, I very rarely (only if forced in exams) used it.

I mostly found it easy to work without it.

Option A SEEMS ok, but this is a feature that needs heavy testing for users to see if it's use fits in C2.

The main place I used it in CC was checking something like "if there are no instances of an enemy with hp greater than 0."

I couldn't use "is enemy hp equal 0" because that would run if there were any with 0 hp, rather than all of them. I could have used loops and such to check as well, but else was a lot simpler.

Your ELSE dilemma gets tricky because it doesn't really apply here. ELSE is a logical operator, while the conditions in the events in C2 are more than just logical conditions (they also do some "actions" like picking etc).

You could solve it I guess by limiting the ELSE to logical conditions only, like System.Compare variable / value, and disallow it if the same event contains other non-logical conditions.

Or you could "overload" ELSE to do other stuff (inverted picking, nice idea), but then it gets tricky.

One more thing, how about this one?

Event: System->Compare x = 1 / Action: System->Set value X = 0

Event: System->Else / Action: System->Set value x = 1

After this runs, what is the value of x? <img src="smileys/smiley4.gif" border="0" align="middle" />

Cheers!

(btw really looking forward to the OR...) (and to the family behavior <img src="smileys/smiley17.gif" border="0" align="middle" />)

My thought is Else should just be shorthand for all the conditions of the previous event inverted.

Case 1 and 2 would work as expected.

Case 3 would read like this:

+-----------------------+
|System| variable1 = 0  | -Do this
|Sprite| X<320          |
+--+--------------------+
   |
+-----------------------+
|System| variable1 != 0 | -Do that
|Sprite| X>=320         |
+--+--------------------+
   |

One more thing, how about this one?

Event: System->Compare x = 1 / Action: System->Set value X = 0

Event: System->Else / Action: System->Set value x = 1

After this runs, what is the value of x? <img src="smileys/smiley4.gif" border="0" align="middle" />

If x = 1, then x will still = 1 and X will = 0. (Unless Construct 2 is case-insensitive.)

If x = 0, then x will = 1.

You could solve it I guess by limiting the ELSE to logical conditions only

I think this would basically make the condition useless. I don't see any reason it can't apply to picking conditions as well - it's only the mix that is difficult.

My thought is Else should just be shorthand for all the conditions of the previous event inverted.

This breaks a common use for Else. Often people write this with the intention of toggling 'X' between 0 and 1:

+ If X = 0

-> Set X to 1

+ If X = 1

-> Set X to 0

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

+ Else

-> 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!

I really want there just to be one 'Else' mainly for elegance. It just seems like there should be one option that does everything you'd expect it to. If there were a programming language that required two versions of 'else' because it could not make one that did what you needed, I would be inclined to think that's a badly designed programming language. So it's a bit of a philosophical point

"Else" in case 3 is not straight forward, since there are more than one possible result.

User might not really make sure what's the actually one, so they might take more effort to understand/memorize it. (And put more question on forums)