A quick question about triggers

In case the same trigger happens multiple times at the same tick for different instances of a family object, do this trigger get all instances at once and runs for each of them or the same trigger runs separately for each instance?

This is an old question of mine as I don't see this explanation on manuals, I never know If I need to use a for each after the trigger to ensure I get all instances or not

Thank you!

If certain condition met then it will take action for instances that picked based filter parameter.

If certain condition met then it will take action for instances that picked based filter parameter.

I'm not sure if you got what I mean. My question is: If a trigger event happens to be triggered by different instances of the object in the same tick, internally, will this trigger work like a loop? or will it be triggered one by one for each instance? And my ultimate question is: do I need to use a for each instance loop after a trigger or It's certain that the trigger will always bring one instance at a time?

It depends on SOL. One event might continue in loop while other executed once. Here a discussion about it:

construct.net/en/forum/construct-2/closed-bugs-22/pick-create-bug-114401

If the condition has a little green arrow it means the event triggered once. In pathfinding "On Pathfinding path found" case, the event will trigger once for every instance that found a path.

And it will triggered again when new path found. So in following example the object will change direction immediately when user tap on screen.

dropbox.com/s/fumc7ctko35r68r/tap%20path.capx

If I understand your question right, you can test this (and many situations like it) easily using the browser object.

Try adding the browser object to your project. Then add the action Browser -> Log to your "on path found" trigger, and just log something like "path found“.

Finally, run your project in a web browser and press F12 and view the console. You'll see it will have logged "path found" for every time that condition triggered.

It's a quick way to test if your code is running as intended. In this case, my hunch is you'll need a "for each -> enemies" condition to your "on pathfinding path found" trigger, but this test should tell you for sure.

If I understand your question right, you can test this (and many situations like it) easily using the browser object.

Try adding the browser object to your project. Then add the action Browser -> Log to your "on path found" trigger, and just log something like "path found“.

Finally, run your project in a web browser and press F12 and view the console. You'll see it will have logged "path found" for every time that condition triggered.

It's a quick way to test if your code is running as intended. In this case, my hunch is you'll need a "for each -> enemies" condition to your "on pathfinding path found" trigger, but this test should tell you for sure.

That's exactly my question. Thank you!

Btw, the pathfinding was just an example. My question is about triggers in general that happens simultaneously on the same tick for the same object and how they treat its instances.

I'll try that later. If you have any other tips regarding the use of the browser log for debugging, please, let me know. Thank you.

There are much smarter folks on here than I, but I think conditions will pick a random instance from all possible objects that meet its criteria.

So using For Each is a great way to ensure that every object that either triggered the condition or meets the condition are picked for the subsequent actions.

I use the Browser log as an quick way to see what's getting triggered, especially when a function gets called. You can also put browser logs inside for/repeat loops, if you want to track what's being done within each loop. It's a really handy tool!

That may be because pathfinding -> find path is one of the "asynchronous" actions.

I believe these few special actions are designed a little differently. Calculating a path can take anywhere from one tick to five seconds depending on the layout, CPU speed, etc, so it needs to run in parallel or the program will hang until it's done. Each sprite looking for a path may take different times to find its path, or the same time.

So it basically has a "for each Sprite" built into it. The timer trigger does not, like most triggers. So on a tick where multiple identical timers go off, your single timer trigger will be considered enabled, and it'll go off a single time.

If all this is true, you should always use a "for each" condition on synchronous actions (like timer). Try putting a "for each sprites" condition on your timer trigger and see what happens.

But they happened in the same tick, as you can see the tick count in the log. I'm now using 'for each' after triggers, without distinction. I think this is the safer way.

What I don't understand at all is why important information like these are missing in the manual, knowing how it works exactly makes all the difference and many bugs could be avoided. Yet, in many situations you just find too simple or too superficial explanations in the manual. I found myself countless times searching for answers on how this or that feature works internally and rarely got an answer and this case is a perfect example of that.

Thank you for your time!

Besides using browser.log() you can use sprite.pickedcount to see how many objects are picked.

In general I assume most triggers just have the one relevant object picked at a time. “On created” for example will be run for each object you created. So no for each needed in triggers.

Ultimately the plugin/behavior could be made to pick multiple instances at once but I can’t think of any examples. Are there any that don’t stick to the standard?

Triggers are like functions, they will be jumped to. But there is something called a fake trigger that’s used sometimes that looks like a trigger but is run in place.

“Keyboard: On key pressed” is a trigger.

“Gamepad: on button pressed” is a fake trigger, which is the same as:

Game pad: button down

Trigger once.