Feedback: 'Else' condition

Post reply
0 favourites

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

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

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

    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.

  • 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

    +Sprite: X < 320
  -> Sprite: set opacity to 33
+Sprite: X >= 320 
  -> Sprite: set opacity to 100

    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

    +Sprite: X < 320
  -> set X to 400
+Sprite: X >= 320
  -> set X to 100

    Obviously all sprite will go to X = 100

    we need an else here

    +Sprite: X < 320
  -> set X to 400
+Else
  -> set X to 100

    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

    +Foreach sprite:
  +Sprite: X < 320
    -> set X to 400
  +Else
    -> set X to 100

    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

    +Foreach sprite
  // check for sprite too far from the center of the view
  System: distance(scrollX,scrollY,Sprite.X,Sprite.Y) > 100
    -> do things

    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 

    +Sprite: Y > LayoutHeight
  -> Sprite:destroy

    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

    +Sprite: X < 320
  -> set X to 400
+Sprite:invert picking
  -> set X to 100

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

  • This breaks a common use for Else.

    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.

  • Ashley :D yeah I saw my mistake and thought about something else as a solution

    So I reposted it with some changes

  • "Else" is pretty tricky indeed when you consider it in the field of C2.

    Programaticly it's strictly logic : did the code block before executed or not ?

    I'm wondering about a case of use:

    if, elseif, else

    So so far, else as been evoked in "simple case tests" if I may say so, where you have actualy "workarounds" in C2 by inverting conditions or "duplicating" with different comparison operators, and where it's a simple matter of if, else.

    How would the C2 "else" handle a "more complex" structure:

    Var1 = 0
-> do this
Else
Var1 = 1
-> do that
Else
-> do whatever

    I'm aware this can be achieved already and doesn't require an "else" to do.

    The interest here, though, is to make sur that if the code in the last event "else" is executed, it implicetely means that all events "linked" above did not execute/their conditions were false.

    This is something else that can be worked around but what I expect from an else is to handle such a structure for me now.

    So my question Ashley here is is the "else" currently planned to take several top levels into account, and if so how would that impact on the "picking" side ? (also are you planning the little visual links like in CC between top and "else" events, it wasn't on your screenshots and I really liked those ^^)

    I might come later with more feedback on the subject it is just indeed really tricky once you start to think about it.

    Also, since I've used C2 from the start without else, and tools have been given to workaround, it's actualy pretty hard to think about how I would use it and expect from it on usage.

  • IMHO "Else" should be strictly logical just the way real programming works,

    especially since you want it to be conceptually simple.

    On this example :

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

    I know it looks like a really convenient & obvious way to do a picking,

    but i think it will turn confusing really quick in a more complex example.

    Also when you teach a beginner class/kids to use Construct 2,

    this will messed up with how "If..else..." works in their mind when they start learning programming language (or if they already learn the basic of it).

    Conclusion:

    + If Condition A is fulfilled
     -> Action 1
     -> Action 1
     -> Action 1          
+ Else
     -> Action 2
     -> Action 2
     -> Action 2     

    Only one side of Action can run at one time, either Action 1 or Action 2.

    This makes things easier to debug/read too,

    because you can be sure that when Action 1 is running, Action 2 will never run,

    you don't have to debug both sides because there is no chance that will happen (unlike that picking example above).

  • Agree with Potato says. Keep it simple, stupid.

  • EVERY TICK                do something
ELSE                      ????

FOR(...)                  do something
ELSE                      ????

EVERY X SECONDS           do something
ELSE                      ???

    what about those cases?

    Also, what happens when you chain the else, like adding extra conditions to the else, and then adding an else to that and adding even more conditions to that other else and so on?

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

    A bit off topic I agree, but perhaps some experienced users aren't aware of the "short" version of toggling between 0 and 1 without ifs:

    Set X = 1 - X.

    Now back on topic, after reading more here's my suggestion:

    For logical conditions, ELSE should be "programatic" else, i.e. did it execute or not.

    For Picking conditions: "Else" picking should be done at the same time as the "IF" picking and should be the exact opposite. So let's say you have 5 sprites, 1 on the left of 320, and 4 on the right, then you do:

    Sprite->X > 320 -> do something

    ELSE -> Do something else

    it should execute accordingly. BUT, IF in the "do something" you move some sprites, then the "ELSE" should not pick those sprites, even though by the time the flow gets there, they match the ELSE too. Think of it like "programatic" if on a "per instance" basis.

    Like: "For these instances, did the logic under IF execute or not? If yes, don't pick them on the ELSE, otherwise, DO pick them, REGARDLESS of what happened to them and whether or not they match the inverted condition as well by the time the "flow" gets there"

    This as far as I can tell is the most "honest" <img src="smileys/smiley1.gif" border="0" align="middle" /> implementation of ELSE.

    And Fimbul, the else in your scenarios should do exactly what the inverted does currently. You can invert "Every tick", "For" etc currently, I didn't try to see what it does in practice, but you can invert them and the ELSE for those should do exactly what the inverted does currently <img src="smileys/smiley4.gif" border="0" align="middle" />

    <img src="http://img94.imageshack.us/img94/4683/invertedweird.png" border="0" />

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

    As far as my test goes, "inverted for" makes the application crash (firebug error,grey screen in browser) and "inverted every tick" just doesn't execute (logicaly).

  • As far as my test goes, "inverted for" makes the application crash (firebug error,grey screen in browser) and "inverted every tick" just doesn't execute (logicaly).

    Sounds like a bug - both events need the "not invertible" flag. Will we have a "not elseable" flag? <img src="smileys/smiley36.gif" border="0" align="middle" />

    Personally, I'd prefer if else were not a condition per se, but a special case - a condition "mode" if you will, similar to how inverting is not a "invert this condition" condition or how a sub-event is not a "treat this as a sub event" condition. Because else acts on the previous condition, it follows that it should be special, not a simple condition (because it is not contained to its line).

    IMHO, treating it as an ordinary condition is a mistake, hence the confusion. Set some time aside to think of an appropriate interface for it - we also need one for OR. Remember that this decision will "stick", and it won't be easy to go back and change it.

  • Ok so if we can't have 2 else maybe we could have one with options :)

    This could be either Logical (1 at a time) or picking

    If Condition A is fulfilled

         -> Action 1

         -> Action 1

         -> Action 1          

    + Else

         -> Action 2

         -> Action 2

         -> Action 2

    Logical could be default and we could enable picking with a tick box or something...

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

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)