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

For as long as I've used Construct, I've assumed that "OR" works the same way as you'd expect an OR condition to work in any other programming language - i.e. the code runs if any of the provided conditions fire true.

However, I learned just recently that "OR" in Construct actually functions like an AND condition, because what it apparently does is that it fires true if any of the conditions are true, but it *also* picks 0 instances of the conditions that return false.

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

To me this doesn't make sense, because it's inconsistent with how the toolkit otherwise works. All object types are always available to the user even if they weren't explicitly picked as part of an event, so why should an "OR" condition suddenly negate them from being picked just because they didn't fire? "OR" means "either 1 or 2", not "1 and no instances of 2".

The reason why I'm bringing this up is because the way that the OR condition works prevents you from being able to utilize any object types inside of an event where those object types didn't fire as part of the event's OR conditions.

In other words, let's say that you want to change JSON1 if JSON1.foo returns true OR if JSON2.foo returns true. Now you can't do that, because if JSON2.foo fires true then 0 instances of JSON1 are picked.

I can't think of any use cases where Construct's way of doing "OR" is needed in order to be able to achieve effects that would otherwise be convoluted, but I can think of several use cases where Construct's way of doing "OR" makes it impossible to do certain types of events that are important to be able to do and which otherwise require complex workarounds.

I guess my questions at this point are:

- Has this been discussed before?

- Is there a reason why "OR" works the way it does?

- Has it always been like this?

- Are there any plans for adding a "True OR" condition? I'd love to see a "TOR".

I know what you're saying and this is mentioned in the manual. Maybe I've been using Construct for too long but it does make sense to me. The condition was not met so the picked instances have been narrowed to 0 even though it didn't run that part of the OR. When I look at the event sheet it makes total sense that if I now add a sub event there are no instances to pick from. Maybe you can try not to use different object types in an OR.

- Has this been discussed before?

Probably. Kind of hard to search for those discussions though. Or with picking has seemed to be a sticking point over the years for many users.

- Is there a reason why "OR" works the way it does? it probably made sense at the time. Personally I use it sparingly as I haven’t reasoned how it works in a simple way. Intuitively it tries a condition at a time until one of them is true. The picking handling has been a bit hazy to me. Your observation show that it doesn’t reset the picking after each false condition. There’s probably some utility in that.

- Has it always been like this?

The behavior of or has basically been the same since the early versions of Construct 2.

- Are there any plans for adding a "True OR" condition? I'd love to see a "TOR".

When just using non picking conditions like system->compare the or behaves just like a logical or in most programming languages. Also the dev seems to keep plans to himself. We only see what they were planning once the feature was added.

Actually unless you have multiple instances of things using system compares is an ideal solution to avoid the picking or non picking.

Imagine this scenario:

> IF PlayerObject is carrying a torch

> OR if FireflyObject is lit

> THEN change PlayerObject's animation to EyesSquinting

In the above condition, PlayerObject would be un-selected if the FireflyObject fires true, and as a result you wouldn't be able to change PlayerObject's animation.

Ohh interesting, it picks 0 players due to failing the first condition, therefore doesn't change the animation?

I would have guessed: after failing the first condition and 2nd condition succeeds, the SOL would have been reset when evaluating the 2nd condition, therefore changing all existing player's animation.

Worst case duplicating events is an option instead of using or. But typically I find alternate solutions to using or on a case by case basis. Best I can do is offer possible work arounds or help confirm or figure out its behavior when I get time.

Dev may weigh in on this later but he’ll probably refer to the manual, or refer to the suggestions platform or bug tracker. At this point in time the way or works probably won’t change because they are worried about keeping backwards comparability.

Imagine this scenario:

> IF PlayerObject is carrying a torch

> OR if FireflyObject is lit

> THEN change PlayerObject's animation to EyesSquinting

In the above condition, PlayerObject would be un-selected if the FireflyObject fires true, and as a result you wouldn't be able to change PlayerObject's animation.

But the implication is that you want to change the animation on the ones that are carrying a torch, so since it couldn't find any then it's correct to apply to 0 instances. If you want to apply to PlayerObjects because Firefly is lit, you have to ask yourself, which PlayerObjects? Because none of them are carrying a torch.

But the implication is that you want to change the animation on the ones that are carrying a torch, so since it couldn't find any then it's correct to apply to 0 instances. If you want to apply to PlayerObjects because Firefly is lit, you have to ask yourself, which PlayerObjects? Because none of them are carrying a torch.

I don't think the implication is that I only want to affect PlayerObjects that are carrying torches, because carrying torches is only one of the two conditions for changing the PlayerObject's animation.

If I didn't want to change the PlayerObject's animation in both cases, then I wouldn't have put it in an event with an "OR"-condition.

I struggled with this for years — thinking it was a bug — until finally realizing that the OR statements inform ALL picked instances even if ONE statement is true.

I guess it's a conflict between the event sheet system and pure logic, but it's always bothered me as well. If PlayerObject isn't carrying a torch, it shouldn't be relevant — if FireflyObject is lit, the PlayerObject should change animation. Isn't that the definition of the word OR?

A true OR that prevents non-true statements from affecting picking would be amazing!

I struggled with this for years — thinking it was a bug — until finally realizing that the OR statements inform ALL picked instances even if ONE statement is true.

Exactly this. Just instead of being bothered for years i looked for a workaround and never looked back.

They should implement a true or condition and keep their weird one as backwards-compatibility hidden just like they did with the old functions plugin.

Until then i will continue acting as if there's no OR condition available. :p

It's a difficult feature to design. The problem is it can't work like a simple logical OR as it needs to involve picking, which is a unique aspect to event sheets.

You can illustrate the difficulty with a counterexample. Suppose it did just work like a boolean test, and then you set up this event:

+ A overlaps B

+ OR: spacebar is down

-> destroy A

Now if you press spacebar, even A which are not overlapping B get destroyed. But this violates a key principle of events that actions only run on the instances which met the event's conditions.

This would mean running the OR block like this:

1. Test "A overlaps B". None are true and so none of either A or B are picked. Usually this means it doesn't run the event, but it's an OR block, so other conditions might be true, so keep checking them.

2. Test "spacebar is down". If this is true then the actions can be run. However "A overlaps B" just unpicked everything. Should it then go and pick them all?

If it worked like this I think you'd get equally-confused threads where people say "why does this OR block affect things that did not meet the condition?" I can't remember exactly as this was originally designed years ago, but I think this was originally the case, it confused people, and so the design was changed early on, but the new design still trips people up.

Because of picking, I'm not sure there's any obvious or intuitive way to design OR blocks. Perhaps the naming is misleading and they should be called something else like "ANY" blocks, so people don't approach it with the mindset of a logical OR. That does also better match how they work, as an OR block really means "run all the conditions, and then run the actions if any condition was true".

Perhaps the naming is misleading and they should be called something else like "ANY" blocks, so people don't approach it with the mindset of a logical OR.

Yep the name is misleading, as for me whenever I wanted to use the "Or" condition is for as simple as:

+A overlaps b

or

+Spacebar is down

These are two totally independent conditions therefore each condition check should reset from zero the Picking. The conditions above of the current condition being checked can never affect the ones below. Each runs 100% independently as if you had them in separate events instead of all in one "Or" Block.

As a result, I never use "Or" blocks for 6+ years unless in very specific cases which are clear (black or white). I have now gotten used to not using "Or" I dont need them but sometimes I miss the simplicity to make an "Or" block to tidy up the code.

In my first years, I studied how it works and I had my notes etc... But if you stop using it for some time you keep forgetting and always have to look at your notes and make a quick examples test etc... it was too much of a hassle trying to remember how it works each time you need to use an "Or" Block so I stop using them at all and I was very happy to be honest as now I dont even have to think to make the equivalent of an "Or" block as it comes naturally.

Though Would be nice if you could add a true "Or" block.

Maybe we should create a suggestion feature and see how many users want the change?

That will give you the motivation to revisit this "Or" block condition hopefully.