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
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
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
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:
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.