OR-block ignores instances picked in parent event

Problem Description

In parent event "System->Pick by comparison" or "Pick by evaluate" is used to pick some sprite instances.

If "Or" block is used as a sub-event, it ignores picked scope and evaluates all instances of this sprite instead.

Attach a Capx

https://www.dropbox.com/s/98slz4y9w6clo ... .capx?dl=0

Description of Capx

A very small and well-commented example demonstrating the problem.

Steps to Reproduce Bug

Run the CAPX

Observed Result

Parent event "System->Pick by comparison" picks only one instance of Node sprite.

In sub-event ("Or" block) the Node.pickedCount suddenly becomes 4.

Expected Result

In all sub-events picked count should not exceed 1.

Affected Browsers

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

Operating System and Service Pack

Windows 8.1

Construct 2 Version ID

Construct 2, Release 246

Well it kind of makes sense since you are directly picking with the system, so the regular picking conventions are ignored.

newt What do you mean? I thought picking conventions are always the same, no matter which event was used to pick instances.

And why "AND" block with the same conditions works fine (respects the set of instances picked by parent event), while "OR" block doesn't?

Here is the code in a nutshell:

// a=1 for all instances
// b=1 for all instances
// c=1 for one instance

System Pick Sprite with c=1    // only one instance is picked
    
    Sprite.a=1
    Sprite.b=1    // Correctly picks just one instance

    Sprite.a=1
    or
    Sprite.b=1    // Incorrectly picks 4 instances
[/code:18m5yq6f]

The pick by system bypasses normal picking, meaning you can use it anywhere without having to use conditions, meaning you can use it in situations where you could not pick specific objects. The caveat is that it's only for that event, which is both good, and bad depending on what you need.

Normal picking covers all objects, and instances from the top tier that picked it, and sub events to that tier.

Sub events at the same level as the first sub, break picking.

newt, Sorry, I still don't understand.. This kind of ruins my whole system of belief in how C2 picking works. And it can potentially mean lots of hard to detect bugs in my games...

Is there a tutorial or something that explains differences between "normal" and system picking?

How can you explain this?

System Pick Sprite with c=1    // System picking - only one instance is picked
   
    Sprite.c=1     // This is "normal" picking, right?
                   // picks just one instance

          Sprite.a=1   // If I put Or-block into a sub-sub-event under "normal" picking sub-event, 
          or           // it still incorrectly picks 4 instances!
          Sprite.b=1    
[/code:e6fk0rs9]
Here is the updated capx:
[url=https://www.dropbox.com/s/jyc2ctj1hlqh3oo/Picking_Bug2.capx?dl=0]https://www.dropbox.com/s/jyc2ctj1hlqh3 ... .capx?dl=0[/url]

Did some more testing. This only happens with Or-blocks, and the order of conditions matters!

"Sprite.a=1 or Sprite.c=1" picks 1 instance.

"Sprite.c=1 or Sprite.a=1" picks 4 instances.

So I'm 99% sure this is a bug.

Ok, the system pick only applies to the actions of that event. The picked items are not saved into the selected item list

Since the tier with the system pick doesn't apply to the sub events they get to act as if there is no sol.

The fact that you still get to add to the sol in the "or" sub is a bit iffy since it's a subevent to a regular picking event, and should work as a filter instead.

Is that a bug?

I would say probably not since the system picking breaks things.

Um just to make sure we're on the same page.

The or event picks 4 instances because all 4 instances meet the logic.

Right?

The or event picks 4 instances because all 4 instances meet the logic. Right?

Yes, but the parent "compare instance variable" event picked only 1 instance. So the sub-event should not pick more than 1.

Also, changing the order of conditions in Or-block should never affect the result! It's against the binary logic.

It sounds like a bug to me.

I reported this issue/bug a while ago, but never got a response from scirra.. at least it sounds a lot like the bug I reported:

The or bit is a bit funky. It looks like the or allows it to go back to inclusive picking rather than filtering, not it's that's normal use there.

Then the system picking may be bugged, but what will it break if it can be changed?

Picking out of sol is not a useless feature.

Hey Ashley,

Sorry for summoning you, could you take a look at this please?

If this is in fact not a bug, please explain why this is happening?

Basically, when Or-block is nested under System->Pick event, the results are unpredictable.

Updated CAPX:

https://www.dropbox.com/s/odcjah36sa6g7 ... .capx?dl=0

OR blocks are one of the most complex parts of the event engine, since the way the picking works differently has ramifications for the entire way all picking works throughout the event system. Given that many conditions internally work differently with their own particular algorithms, it can result in some pretty difficult edge cases, which is what I suspect is going on here.

Currently we are still very busy with the C3 beta running up to the full launch, C2 is pending a stable release, C2 is only in maintenance mode, and this bug report is only a few days old. I can't give an ETA when I'll be able to investigate/fix this or any other related issues, but hopefully I'll get to it at some point.

Thank you, Ashley!

Once you know about this bug, there are lots of ways to work around it. I'll just have to be more cautious with using OR-blocks in my code.

So it's not a very urgent matter, but it would be nice to have it fixed some day.