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
Operating System and Service Pack
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.
Develop games in your browser. Powerful, performant & highly capable.
Here's a further refined capx:
https://dl.dropboxusercontent.com/u/542 ... r_bug.capx
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.
I refined the capx further here:
https://dl.dropboxusercontent.com/u/542 ... _bug2.capx
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.