Are "On Each Loop"s memory intensive?

[Enchantainment]

I've been using "On Each Loop"s, to multiple instances of a enemy, to stop one even affecting all the instances of it. I've used it, so that when the enemy lands on the ground, the one that is hitting the ground stops and not the ones in the air. I know that "Fast Loops" can cause your game to strain, but I was wondering if the same applies to "On Each Loop"s?


Thanks!

[casleziro]

Many of them, or lots in complex situations can, but it usually takes considerably more foreach loops to cause a notice-able slowdown than it does fastloops. You shouldn't have to worry about them, I think.

[schrodinger]

I noticed/tested a couple things,
and recall hints by Snail, ProdigyX and other forum members,
that may be worth mentioning:

-scoping a Foreach already on launch wil scope down inspected objects already (this will save Fusion from iterate through the same objects again onloop)

-always>foreaching becomes a bad practice when additional different loops are performed on the same objects

-^ following from above, better stuff most actions you can, for the same objects, in the same "on each one of" condition

-scope down the loop at best you can, and always put the most "scoping" filters in higher places on the conditions list

As for speed, it may also significantly depend on the use you do,
if you iterate through objects, foreach will generally do a better job.

(this is all worth inspecting/tweaking in a crowded situation with many actions performed onloop, otherwise just leave it go )

[Enchantainment]

Thanks for the answers! I'll make sure to use them sparingly, and try to avoid using them in an "Always" event.

[schrodinger]

Just as a clarification,
(from what I can tell with own testing)
always - foreach is not a bad practice on its own (I'm myself an always-foreach addicted )
it becomes dangerous when you perform more of these on the same objects

i.e.
always --> count - foreach one of "glue", loop name "stick"
always --> count - foreach one of "glue", loop name "drop"
always --> count - foreach one of "glue", loop name "sink"

[Enchantainment]

Thanks for clearing that up Schro. That's definitely a good bit of knowledge to have whilst using them

[Simon]

For this kind of testing I highly recommend that you use behaviours. Applying logic through behaviours allows you to test each individual instance of an object in isolation, automatically, simply by attaching the events you need as a behaviour. Fusion then automatically filters these down so that they apply to only the objects affected by your conditions on the behaviours.

These are one of Fusions least well understood tools but can offer an enormous amount of power and flexibility without bogging the main event loop down with lots of for...each or fast loops.

[mobichan]

Simon: It is too bad the interface for behaviors is so unfriendly. Otherwise they might be more popular and useful. It also doesn't help that you have to change your coding logic to deal with them at the end of the event loop, something I find very tricky to deal with.

[Enchantainment]

For this kind of testing I highly recommend that you use behaviours. Applying logic through behaviours allows you to test each individual instance of an object in isolation, automatically, simply by attaching the events you need as a behaviour. Fusion then automatically filters these down so that they apply to only the objects affected by your conditions on the behaviours.

These are one of Fusions least well understood tools but can offer an enormous amount of power and flexibility without bogging the main event loop down with lots of for...each or fast loops.

Using logic from the top event in this screenshot, the spawner (the default triangle) should begin adding to it's spawn timer when none of the 3 objects are overlapping it. However when one instance of the object meets those conditions, nothing happens. That event will only work if all instances of the spawner don't have any objects over them. Could you tell me why this might be the case?
Spawn Event.jpg

[Simon]

Simon: It is too bad the interface for behaviors is so unfriendly. Otherwise they might be more popular and useful. It also doesn't help that you have to change your coding logic to deal with them at the end of the event loop, something I find very tricky to deal with.

Can you elaborate on your thoughts about the interface? How is it unfriendly in your opinion?

Also could you elaborate on what you mean about changing coding logic, perhaps with a simple written out example?