Looped "pick with UID" doesn't pass on the picked UID

Problem Description

Having certain events enabled in the code even if no actions are triggered by these events, changes the way other events behave, may they be in completely event sheet.

If a "pick with UID" is in the same event as a loop, it doesn't always pass the right UID to all of its subevent.

Attach a Capx

Compact : sta.sh/025e3kk223cf (as little code as possible)

Expansive : sta.sh/0n24fz9hycm (more mechanics of the bug explained inside)

Description of Capx

There are two Blue sprites, with UID 0 and 1

A loop picks Blue-0 everytime it repeats, and make it transparent when certain conditions are met.

Blue-1 is ignored by this loop, and does nothing.

Steps to Reproduce Bug

• Start "or-bug.compact.capx", drag and drop the two Blues around the place
• -> Blue-0 becomes transparent when placed outside of the lower-right quadrant of the layout
• -> Blue-1 stays opaque no matter what. ----
• Enable Event 2, and restart the project.
• -> Blue-1 now becomes transparent when placed in the top half of the layout. It shouldn't. ----
• Change the order of the conditions in Event 4
• -> Blue-1 now becomes transparent when placed int the Left half of the layout. Expected Result ? Event 4 is the subevent of "Pick Blue with UID 0", it should only ever affect this instance of Blue Observed Result ? When the bug is enabled, if the first condition of Event 4 is true, it may affect other instance of Blue than the picked one. ? Event 4 is affected by this bug because :
  • Its mother-event "Pick with UID" is also a loop.
  • It is an -or- block
  ? To Enable the bug, you also need Event 2, which one :
  • Is placed before the loop
  • Is a subevent
  • Is an -or- block
  • Has at least one condition enabled, which compare one of the following properties in Blue :
  X, Y, Eight, Width, TextVariable, Animation, any form of Pick
  • Has no condition enabled that would compare anything but one of these properties.
  Affected Browsers
  • Chrome: (YES)
  • FireFox: (Not Installed)
  • Internet Explorer: (Not installed)

Operating System and Service Pack

Windows 8.1

Construct 2 Version ID

r216 & r219

Though I have a workaround for myself and don't need help on it, I'd like to know whether this was confirmed as a bug.

Here's a further refined capx:

https://dl.dropboxusercontent.com/u/542 ... r_bug.capx

r219

Enabling\Disabling the "or event" at event 3 affects the result of the following "or event".

With the first or event enabled the second or event changed the picked blue from uid 0 to uid 12.

I'll see if the capx can be reduced further.

I only ever managed to reproduce it using text variables before, I appeared to be half wrong there.

Comparing Number or Boolean Instance variables still disable the bug, but apparently coordinates also enable it.

There might be more to add to the list, I should try using different kinds of events, and see which ones enable or disable the bug.

I know already that comparing opacity, Dimensions and Animation also enables the bug.

Ashley

I refined the capx further here:

https://dl.dropboxusercontent.com/u/542 ... _bug2.capx

Description:

The bug is an "or event" that's a sub-event of an empty event affects a following "or event" that's a sub-event of a "for each" event.

Here's what the events looks like:

The layout has two sprite types: red and blue.

Red has only one instance and can be anywhere. It is only required to have the "for each".

Blue has at least two instances to be able to see the bug.

The gist of the events is to pick the first instance of blue and make it transparent if it's left or above the center of the layout (250,250).

It acts as intended for the first instance of blue, but when event 2 is enabled then event 4 also seems to pick any other instances of blue. The other instances are only picked with the second condition of event 4 though. So if any other instance has a y lower than 250 it becomes transparent.

The expected behavior would be for the other instances to not be picked regardless if event 2 was enabled or not.

If rewritten without using "or", and keeping the same behavior as the bug, the events would look like this:

This was tested in r219 in google chrome 47.

R0J0hound Nice one.

I could refine the Capx even more by completely removing red, replacing the loop with "for each blue"

Also, the loop doesn't have to be a "for each" at all. A "repeat 1 time" also works.

I've rewritten my first post with what you've found. Attaching your capx and one I believe is better for understanding.

Notably I readded an action that turns the picked Blue sideway: we can see that Blue-1 is never actually picked by the loop despite being used in its subevents.

Thanks, should be fixed in the next build.

sweet