Feedback: 'Else' condition

Discussion and feedback on Construct 2

Post » Sun Apr 08, 2012 9:29 pm

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?

Cheers!
(btw really looking forward to the OR...) (and to the family behavior )
B
14
S
5
G
7
Posts: 235
Reputation: 5,175

Post » Sun Apr 08, 2012 10:40 pm

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:
[code]+-----------------------+
|System| variable1 = 0 | -Do this
|Sprite| X<320          |
+--+--------------------+
   |
+-----------------------+
|System| variable1 != 0 | -Do that
|Sprite| X>=320        |
+--+--------------------+
   |[/code]
Which may or may not be what is desired. If it isn't then sub-events can be used like Ashley pointed out.

This is how it seemed to work in CC with the exception that the inverted selection was a bit wonky which made "else" only useful for simple events.

So, option A, but explain it's behavior as all the conditions of the previous event inverted.

My 2c.
B
79
S
24
G
54
Posts: 4,754
Reputation: 40,771

Post » Sun Apr 08, 2012 10:44 pm

[QUOTE=Geo]
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? [/QUOTE]
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.
B
25
S
8
G
8
Posts: 71
Reputation: 5,307

Post » Sun Apr 08, 2012 11:31 pm

[QUOTE=Geo]You could solve it I guess by limiting the ELSE to logical conditions only[/QUOTE]
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.

[quote=R0J0Hound]My thought is Else should just be shorthand for all the conditions of the previous event inverted.[/quote]
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!
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,610

Post » Mon Apr 09, 2012 12:01 am

[QUOTE=Ashley]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[/QUOTE]

"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)

B
97
S
22
G
178
Posts: 4,122
Reputation: 104,051

Post » Mon Apr 09, 2012 12:06 am

Is it possible to set it up where the user can only add else as a subevent.
I don't see much of a reason to have it on top tier anyway.
Image Image
B
161
S
48
G
91
Posts: 7,359
Reputation: 67,273

Post » Mon Apr 09, 2012 1:07 am

Personally, I think this is really not that necessary, thanks to copy/paste. I would work on more important features first (functions/OR) instead of what looks like it could get very confusing!
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Mon Apr 09, 2012 1:22 am

@Yann: making it "logic only" would certainly be a lot simpler in the code. (Edit: did you delete your post? :P ) However I don't think your last example works. Remember if a single instance meets the condition the event counts as having run. So in your last example if *any* sprites have X > 35, the 'Else' does not run.

In other words going back to case 2:

If 'Else' is logic-only here, and for the duration of the game there is always a sprite on the left of the screen, the 'Else' event never runs at all - it may as well be deleted. I think this is also counter-intuitive. It seems obvious what the event should do, so I think it's still a good idea to involve the sol-inverting feature.

I'll code it as option A (logic-only if a system condition is present, else sol-inverting) for first release, but with a warning it may change in future. I think having people play with it in real projects will be useful.Ashley2012-04-09 01:22:54
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,610

Post » Mon Apr 09, 2012 1:28 am

I honestly think that "else" shouldn't mess with picking as most system expression.

In my opinion, else is missing in c2 for only one algorithmic case: "when my previous condition is false"
Putting the inverted condition as an else doesn't work if the action of the previous condition makes the next one true (like Ashley's toggling example)
In short, I side with Geo in the idea of keeping the else logical only.

Also in Ashley's case 2 things can be easily handled by just inverting condition
[code]+Sprite: X < 320
-> Sprite: set opacity to 33
+Sprite: X >= 320
-> Sprite: set opacity to 100[/code]
There's really no need for an else here

If we keep telling users that "most system conditions do not pick any instances: they are either true or false." It will be the same rule applied to "else"
The only system expression that should modify picking should be those in the "Pick instances" category and the for each loop. Because they are pretty self explanatory.

Unless someone find a good situation where inverting picking is really that usefull and can't be handled by just inverting events... I don't think it's worth it.

hmm let see a case were inverting a condition doesn't work
[code]+Sprite: X < 320
-> set X to 400
+Sprite: X >= 320
-> set X to 100[/code]
Obviously all sprite will go to X = 100
we need an else here

[code]+Sprite: X < 320
-> set X to 400
+Else
-> set X to 100[/code]
Indeed if this else is a logical one, and there's even just one sprite at X < 320 the others won't go to X=100 as the else won't be executed

One of the work around could be to loop through objects
[code]+Foreach sprite:
+Sprite: X < 320
    -> set X to 400
+Else
    -> set X to 100[/code]

Which makes me thing that we also need to loop some other different case where we use system expression on instances, like distances or angle checks
[code]+Foreach sprite
// check for sprite too far from the center of the view
System: distance(scrollX,scrollY,Sprite.X,Sprite.Y) > 100
    -> do things[/code]
So it's not far from it actually.

However, if I'm not wrong about how event works, condition "inside objects" works does a kind of hidden loops.
Like
[code]+Sprite: Y > LayoutHeight
-> Sprite:destroy[/code]

Which leads me to this idea: maybe we could have a system else for logical purpose and an instance "inverse picking"

Then the aformentionned problem would be reduced to
[code]+Sprite: X < 320
-> set X to 400
+Sprite:invert picking
-> set X to 100[/code]
(of course you'd have to have a link system between two events...)
... This way you keep the two ideas, as well has clarity =)

Annnnd I side with Arima on that one, didn't read his posts but we had the same ideas (:Yann2012-04-09 01:39:00
B
60
S
22
G
14
Posts: 1,479
Reputation: 16,346

Post » Mon Apr 09, 2012 1:28 am

[QUOTE=Ashley]This breaks a common use for Else.[/QUOTE]
Opps, I forgot to think of that. And now that you mention it that is the main reason I used "else" in CC.

In that case I agree with you that option A is the best option. It will work with System conditions and single instance objects exactly as expected. Any complexity added when using multiple instances of an object can be solved in the same manner as conditions such as "Sprite| X=Sprite2.X" when multiple instances of each are invoved.

edit
Logic only would also be ok. Case 2 would then be soved with a "for each Sprite", which is pretty common solution used for a situation like that.
B
79
S
24
G
54
Posts: 4,754
Reputation: 40,771

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: shinichild and 12 guests