Events executed in the wrong order

Problem Description

Picking two events modifying one variable, the changes from the first to come will be carried after the second is executed. The changes from the second to come will not be kept outside of its own scope.

Attach a Capx

sta.sh/010tefj7gcwj

Description of Capx

Spite haz boolean.

When boolean True, sprite destroyed.

Two times in the project, the boolean value is changed:

• A first time with no condition: the boolean is set to false.
• A second time, on click, it is set to True.

Afterward, the boolean is checked, and the sprite i or isn't destroyed.

Since the boolean is set to True AFTER being set to False, it should still be considered True afterward by the following events.

It is not.

Steps to Reproduce Bug

• Disable Event 1 and run the project. On click, sprite is destroyed.
• Enable Event 1 and rerun the project. The sprite won't be destroyed anymore.
• Make Event 3 a subevent of Event 2. The sprite will be destroyed again

Observed Result

The action of Event 1 will be carried after Event 2, despite Event 2 supposedly cancelling it.

Expected Result

Event 2 overwrites Event 1 's changes once and for all.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)

Operating System and Service Pack

Windows 8.1 / windows 7

Construct 2 Version ID

r221

The trigger "on click" is run when the mouse clicks, it's not run top down.

Wait...

But then when are triggers executed in the code? In-between ticks? How do you control that ?

I don't understand why. What makes it so it was intended not to work the same way as: ?

Triggers (the events with green arrows) run in the order defined in the event sheet but before regular events. If you imagine all triggers at the top of the event sheet - that's how it works.

Event number 1 is pretty much "Every Tick", and as ramones mentioned above, the boolean is set to false before checking if it is true.

Yeah, I've checked the manual and understand how these triggers are supposed to work, but I still don't understand is why they need to work this way.

I mean, code not executed in writing order, I'm falling off my basics here. Am I the only one to question this?

Basically any trigger except "on collision" (which is run in place) can be run inspite of its location on the event sheet. Simple things like "on start of layout" and "on function" are example where you wouldn't want it to run when the event sheet gets to them. Another reason is if the condition is triggered multiple times. With mouse button is down that event would run only once per frame, wereas on click would run for every click. Now for the mouse this won't really happen since you can't click multiple times in 1/60th of a second. It is possible with something like on any key pressed.

=> "A single trigger can be run multiple times per tick"

Oh, I never actually considered that. I think I'm starting to see the nuance here.

Thanks for the information.

Closing as not a bug - the fact triggers run outside of the normal event flow is documented.