Why is "OR" not a true OR condition in regards to picking?

Post reply
0 favourites
From the Asset Store
Fighting Template: A (Not So) Basic One
$31.99 USD
2D fighting template based in the game that defined the fighting games genre.
danuyos's avatar
danuyos

  • We do have both ways now though, an or block doesn't reset picking, and an else-if does.

  • + Sprite X < 500

    + OR: Sprite Y < 500

    You'd expect this to run actions with all Sprite instances picked that are left of X=500 or above Y=500. If it resets picking for every condition, it becomes essentially just "Y < 500" by itself, which will look broken again.

    I would expect this OR-condition to either pick all of the instances that are to the left of X=500, or pick all of the instances that are above Y=500. Even as we're talking about this, I struggle to think of what else it could logically do.

    Based on this thread, it sounds like what would happen is that it would pick all of the sprite instances that are to the left of X=500, while un-picking all of the sprite instances that are above Y=500. Is that what is supposed to happen?

    You could file a suggestion, but based on the problems I've shown, I don't see a better way it could work unfortunately! Then there's also backwards compatibility: we can't just change how thousands of existing projects work...

    Would it be possible to add a true OR condition? Or would that require fundamentally changing the way things work.

  • I would expect this OR-condition to either pick all of the instances that are to the left of X=500, or pick all of the instances that are above Y=500. Even as we're talking about this, I struggle to think of what else it could logically do.

    You say it should be one or the other, so which would your actions apply to? It makes sense to me that sprites that meet either criteria would be picked for actions to happen.

    Based on this thread, it sounds like what would happen is that it would pick all of the sprite instances that are to the left of X=500, while un-picking all of the sprite instances that are above Y=500. Is that what is supposed to happen?

    If picking was reset between or conditions, that is what would happen. Which isn't what currently happens, but that was the provided example of what would happen if picking was reset.

    > You could file a suggestion, but based on the problems I've shown, I don't see a better way it could work unfortunately! Then there's also backwards compatibility: we can't just change how thousands of existing projects work...

    Would it be possible to add a true OR condition? Or would that require fundamentally changing the way things work.

  • > I would expect this OR-condition to either pick all of the instances that are to the left of X=500, or pick all of the instances that are above Y=500. Even as we're talking about this, I struggle to think of what else it could logically do.

    You say it should be one or the other, so which would your actions apply to? It makes sense to me that sprites that meet either criteria would be picked for actions to happen.

    Exactly, the use of 'either' doesn't make sense in the context of how Construct is picking instances and applying actions to them. It will pick all the instances that meet at least one of the conditions.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You say it should be one or the other, so which would your actions apply to?

    It would apply to the instances that were picked as part of the condition that returned true. In other words, any instance that returns true for an OR condition would be picked.

    If picking was reset between or conditions, that is what would happen. Which isn't what currently happens, but that was the provided example of what would happen if picking was reset.

    I don't understand, if OR-conditions un-pick instances that don't return true as part of an OR-condition, why would it not un-pick instances in the provided example?

  • > You say it should be one or the other, so which would your actions apply to?

    It would apply to the instances that were picked as part of the condition that returned true. In other words, any instance that returns true for an OR condition would be picked.

    I find it's better not to think of it as returning true or false, but instead returning a number of picked instances. If you have a condition 'sprite is X' as part of an OR block, and there are no 'sprite is X' I think of it as 0 instances matched, not that the condition returned false and therefore should be ignored and all instances are still open to being picked.

  • Then there's also backwards compatibility: we can't just change how thousands of existing projects work...

    For backwards compatibilty rename the current "OR" to "ANY" as you suggested yourself and create a new true "OR".

    To prevent any confusion, trigger a one-time pop-up the first time someone uses the new "OR", to inform users what changed so they know they need to swap to "ANY".

    Or if you're so keen to not rename it, call the new one TOR, *OR or whatever. Isn't as clean but at least we get the actual logic.

    And everyone's happy.

    Although events picking without mentioning picking could still get confusing. But that's nothing new. A tiny tooltip icon indicator on each event that picks ur unpicks might come in handy, but that's a different topic.

  • It's still not clear to me how any new OR feature should work. There are lots of awkward combinations of different types of conditions that need to be properly thought-through with specific results defined. It definitely can't just be a logical OR, because it needs to involve picking somehow. You can't just say "make a true OR" without explaining exactly what that means.

  • I thought it was explained well in the first post:

    In other words, the following event:

    > IF playerA.Something

    > OR playerB.Something

    Doesn't translate into:

    > Pick playerA.Something if true

    > Or pick playerB.Something if true

    It actually translates into:

    > Pick playerA.Something if true, and pick 0 instances of playerB

    > Pick playerB.Something if true, and pick 0 instances of playerA

    So an OR condition where the untrue statements have no effect on the picking of the true statement.

  • What about the other cases I pointed out, like when combining with multiple conditions from the same object type, or involving system conditions that don't do any picking?

    TBH I don't think this is going to happen, realistically. The event engine involves a large amount of complex code, internally there are several different types of conditions that work differently, many important conditions have custom coding for them, and code for OR blocks is highly complex and spread through it all. Even after many years we still occasionally get bug reports and have to tweak the implementation. The idea of adding even more OR logic to all that fills me with dread. Then there's the fact that it's adding a second alternative to an existing feature, which I generally think is the way to end up with messy and complicated software. Add on top of that that I get the impression different people have different views on how this should work, and it seems likely an alternate OR implementation will not fulfill everyone's wishes in every case, and so could end up as something people end up avoiding anyway. Altogether this kind of adds up to a worst case scenario for a feature suggestion.

  • Sorry - I was only summing up the problem to solve and initial proposed solution (OR conditions where the untrue statements have no effect on the picking of the true statement).

    I can't answer questions about the other cases the solution would need to address. However, I don't think those are user problems to solve.

    Users could try or suggest, but chances are they don't have enough information to do so (seen here). But if users can't solve the problem, that shouldn't have any bearing on whether the problem should be solved.

    Developer solutions to the conflict of OR and picking would for sure be the most important and productive to discuss. Or maybe the criteria for this be successful could be shared with users, so the proposals could be more useful to you. But if OR code is simply too complicated to adjust, then I imagine that's the end of it.

  • + A overlaps B

    + OR: spacebar is down

    -> destroy A

    As it is, pressing Spacebar takes absolutely no effect, because it picked 0 instances during the overlap check. And if there are overlaps, only the overlapped ones get destroyed. Conclusion: "Spacebar is down" condition is redundant / non-functional.

    But yes, your other example works as expected.

    if (A.x > 500 || A.y < 500 ){

    }

    I guess it's what it is, just doesn't feel consistent. But i have a better understanding that picking over-complicates it in the backend.

    At least i made myself a little reminder:

    "OR" stay within the same event block unlike "ELSE". And everything within the same block remembers picks.

    Which is i guess, the core principle of events as Ashley mentioned.

  • From my perspective, it has never been a problem.

    I've programed some pretty complex logic into construct 3 and I never had to think too hard about the OR block setting.

    I am a novice programmer, and I do remember thinking it was weird how it was set up, but after a while dismissed the thought, as all software has a quirk or two.

    I do use the Or feature sometimes as well.

    This being said, I'd like to propose a 3rd train of thought.

    Logical gates are required between EVERY condition in real programing languages.

    This would likely never be implemented in construct 3, but if you really wanted to make it the same as traditional languages, the 'OR' and 'AND' blocks would look more like extra condition blocks themselves, with the ability to place one between every condition.

    [ + If sprite.y > 40 Or + If sprite.x > 80 ]

    And

    [ + If sprite.y < 1200 Or If sprite.x < 400 ]

    Note that for this to work, you would need to include a way to add parentheses to explain order of operations.

    This is how real logical gates work. It's just not how construct is designed.

    For me, it quickly became intuitive to know how to turn this logic or any other set of complex logic into a series of events with sub events.

    For true 'Or' it's easiest to just make a separate block all together and add any other picking you need to it.

    At the end of the day, construct treats the entire event sheet like one huge true or block, resetting picking between each parent event block.

    There is not a huge need to bake this behavior into a new feature.

    But renaming to ANY sounds like a simple and productive change to me.

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