OR block bug

Problem Description

OR blocks are not properly registering as a TRUE condition when one or more of the condition lines indicates TRUE.

Attach a Capx

link to capx

Description of Capx

The layout contains a TiledBackground (TB) and a sprite (with 8-direction behaviour, so you can move the sprite to overlap the TB). There are 3 groups in the event sheet, 2 of them are disabled so that only one group runs during testing.

If the mouse or the sprite overlaps the TB then it is set invisible. Group 1 works correctly with separate events to check for the overlaps. Groups 2 and 3 contain OR block checks of the mouse + sprite overlap, with the order of the conditions swapped in each group.

Steps to Reproduce Bug

• Run the layout with only Group2 enabled and observe when the TB is set invisible with mouse / sprite overlapping it.
• Run the layout with only Group3 enabled and observe when the TB is set invisible with mouse / sprite overlapping it.

Observed Result

As described in the Group comments, the OR blocks in Groups 2 and 3 do not work correctly. The Group2 OR block works like an AND (sort-of...), and the Group3 works only when there is a mouse overlap.

Expected Result

Each OR block should register as TRUE if one or more of the lines in the block registers as TRUE.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

W10 x64

Construct 2 Version ID

r227 64 bit

I tested it and indeed looks like a bug. At first I thought it was a problem with using Else in Or blocks, but the bug happens without it too: https://dl.dropboxusercontent.com/u/395 ... rBug2.capx

In one of the cases it works like AND and in the other only the mouse event is detected

Was having problems with this and I have now seen this report, must publish soon be a correction !.

I think you read those conditions the wrong way.

Maybe you understand this example better:

https://

drive.google.com/open?id=0B1SSuCVV8v74YlBUdzI3dzhlQ28

The thing is. This is not a logic puzzle like the easy if x=4 or if x=5 then do this.

This is are pick conditions. Its not comparing overlaps. It is making Selected Object Lists. And that is all it does.

The overlap logic is only in your mind, its is not part of the logic.

The question with pick condition is always simple: what is in previous Selected Object List. And what did we filter out (or not) in the next pick condition.

Okay so:

Sprite is overlapping tiledbackground ...

1/ if the sprite is overlapping, both sprite and tiledbackground are in the SOL. This made the previous picked SOL for the next pickevent. If now the mouse is not over the background, that background dissapears in the SOL. Simple as that.

2/ if the sprite is not overlapping the tiledbackground, the SOL is empty, it does not matter what the mouse does, the tiledbackground is just not in the SOL to begin with. Simple as that.

3/ if the sprite is overlapping, both sprite and tiledbackground are in the SOL. If now the mouse is over the background, that tiledbackground stays in the SOL. And finaly the tiledbackground that is in the SOL gets set invisible. And that is why you see this as an AND event. While it is not.

There is a BIG difference in logic between pick-events and non-pick-events.

The only thing that pick-events do is filter previous picked Selected Object Lists. And the previous picked Selected Object List is empty when a new root event is started.

And that is in 2 sentences all you need to know to make good pick events.

My opinion (everyone has one) on this is this:

Since you have to code this differend to make a solid logic, Construct 2 can as wel force you to code this differend. By not allowing an 'OR' when there is a pickcondition in the events.

99Instances2Go,

According to the manual, if any condition in an OR block is true then the sub-events should be run.

Here's another example to demonstrate the bug: capx demo 2.

The group "works for cursor overlap" runs correctly because the overlap check condition reads true (ie the cursor overlap condition = 1). So we have a condition that reads as 1 when on its own or under an Else, yet it does not read as 1 if it is placed inside an OR block.

There is no false/true case. It just adds or pulls objects on/from a stack. The actions run on the stack.

The result of a pick condition like 'is overlapping' is not a true or false flag, the result is a list of objects, populated or empty.

The result of a pick condition like 'is overlapping' is not a true or false flag, the result is a list of objects, populated or empty.

Let's agree to differ on this point and see what Ashley says. I am pretty certain that if the SOL is not empty then the condition should behave as if it was true. This is why, in fact, in my second example above (line 6: Else, Cursor is over Sprite) the condition is true and the variable changes to 1 whenever the mouse is over the sprite (ie the SOL is not empty).

Additionally, your analysis does not explain any of the nuances of this bug (ie the order of the conditions in the OR block makes a difference as well).

I have to rephrase things. I was only half correct. The flag true/false gets set. Else unreferenced objects would not feel the action, and they do. But. The rules for picking still apply. The SOL is just empty. The action run on a empty SOL.

https://www.scirra.com/manual/75/how-events-work

99Instances2Go,

I've edited the original capx, please re-download and take a look. There is definitely a picking problem caused by the presence and position of the mouse-overlap check condition.

I have added a text object that changes to indicate if the OR block is running as TRUE or FALSE. The tiled background should be picked by the overlap with the sprite, but this is not happening - even though the text object is changing to indicate the condition was True.

About the last capx you placed.

You always start at the bottom condition, and trace back. Knowing that: a pick condition looks at only the objects in the previous picked list of objects. Unless the list is forgotten. Forgotten is not the same as empty. So. When the list is forgotten you can read in the manual as i linked it for you.

• The does not work section:

Starting at the 'cursor is over sprite'. The previous picked list for that condition is made by the 'sprite is not on screen' condition. Al sprites are on screen, so that picked list is empty. Meaning, the 'cursor is over sprite' does not find any sprite in the SOL, and can therefor never be true. There are no referenced or unreferenced objects in the actions section, so we do not have to talk about at that. Althaught thats is mostly the problem. Because since the SOL is empty, no action can ever work on the sprite object.

• The works section.

Starting at the 'cursor is over sprite'. That is a new 'top' condition. Or 'root' condition, or how you want to call it. This means that there is no previous picked list. The picked list is forgotten. Not the same as empty !. Just forgotten. So, in fact, it makes its own pick list from scratch, starting from all the sprites again. And in the picklist that it made are all sprites that are overlapped by the cursor included.

Same for 'sprite is not on screen' in there. It has no previous picked list, because it is a root, a new condition. So it has all the sprites to pick from.

Dont know how to explain it better to you. I hope i made things a little clear.

So, basecaly. When you compare 2 'pick condtions' (in an or, or an and, or an else, or in a sub) you have the obvious flag true/false. But besides that, the mutch more importand 'previous SOL'.

Two things can happen.

1/ Althaught the flag reads true as you expect it to be, the actions can get an empty SOL, an therefor work, but work on nothing.

2/ The second (or third, 4th, 5th ....) condition can look for objects that are excluded by the previous picked list. Than the condition will not be true.

There is one more way for me to state it more clear. When i may say it in my moms language. : )

Colludium

I can confirm the bug. You can re-arrange it without an else to show the "or" is the only issue:

every tick:

--- set text to false

mouse is overlapping tiledbackground

-or-

sprite is overlapping tiledbackground

--- set text to true

For me the second condition in the "or" block is always ignored.

Thanks for checking, R0J0hound, that's good to know.

Ok.

Explain the difference between the 2 events in this capx, plz.

https://

drive.google.com/open?id=0B1SSuCVV8v74V0FMSUZrTklDSVE

99Instances2Go, you have just re-hashed my bug report. The first OR in your example works like a broken/locking AND condition and not an OR condition. The reason this happens is there is a bug in c2 :p ....

Please stop spamming my bug report and let the c2 devs work this; are you still insisting that this is not a bug?