Usually a workaround implies that it can actually be done in the current release. Otherwise, it’s not a workaround but another feature request which purpose can’t only be to workaround something.
You’re correct, fut this feature can facilitate many workarounds, not just that one.
I’m more interested in this statement.
Can u explain to me how they’re going to let you use less “for each” events? …i’m a newb on the matter.
1 Like
when an event is on an object’s behaviorFunction or on a prefabFunction it counts as if it already was on a “for each object” condition, because every instance of the object is “running its own events”.
I use objects as containers of events/behaviors and wish to use prefabs as containers of tightly related objects with heavily interconnected behaviors.
I understand what you want.
aren’t they childs of object?..cos you said instance…just asking
1 Like
They’re called children for a reason.
how can this reduce the number of “for each” to use?
1 Like
“for each object” I forgot to add "object " when I wrote that.
I know, but they are instances too when they are on the scene, I used the word instance to mean “every Copy of the object existing on the scene”.
1 Like
Good 
.
I went in depth cos “for each” is something i prefer to avoid too…
1 Like
there was one for each event that I could not avoid, because I don’t know how it works so I rather not touch it. But I was able to replace the “for each Object” with a behaviour.
Is there an reason to not add this? Would it brake the engine or something?
