Good way to order "broadcast all" recipients

[abend]

So I have this one setup event and I use broadcast all. I believe there are 10 or so objects that receive the call and then run what they run. One of them is a copy of a rather large object with maybe 200 child objects. I feel like I am doing too much in this frame and there is a visual hiccup when this fires. It's not too bothersome, but the framerate drops a lot for that little bit, but I just want to sort this out now before it gets too complex. I would like to fire the big guy first and then fire the rest of them. In doing so I am kinda breaking my format, but I think it makes sense here. So I was wondering what sort of approach would make the most sense.

1. make a standalone sequence that calls the 10 things in a row, although the rest of them can probably all run at the same time as they are not nearly as intensive as the big guy.
2. try to put a wait action on the other ones as the first thing that happens when the broadcast is fired (I feel like this would be hard to maintain)
3. change the broadcast all to calling each individual thing. I lose the freedom of the broadcast all here.
4. have each call daisy chain the others.
5. make an intermediate broadcast call that takes the first broadcast all and then fires it's own broadcast all after it runs

I'm very open to any other designs anyone suggests. I just want to be able to trace things easily!
Thanks!

[djaydino]

Hi.
When you can always go for 3, if you have a lot of objects, it will check each object to send the event.

Did you check in the profiler what the hicup is, are you creating multiple objects maybe?

also test in build or at least in editor without any other window visible.

[jeanfabre]

Hi,

 it's likely not the event or the fsm, but rather what you do inside the following states, you might have an action that takes time, you need to identify that.

 sending event doesn't cost anything in itself.

Try to turn off actions, or even deep profile with Unity and see which action creates the hickups.

Bye,

 Jean

[Broken Stylus]

Maybe the Big Guy–the parent (itself a copy) of 200 children(!)–eats up some render or CPU time because of something you do in a FSM of this Big Guy the moment it receives the event which, for some reason, fires up the 200 children at the same time.

Assuming you have some margin of operation, you might optimize this by sorting the 200 children into several child groups (like 4 groups of 50 each, or 8 x 25, etc. but be careful not to use too many frames) and have the FSM on the Big Guy go through each child group during several frames.
So you're looping through all these child groups one by one, one frame at a time, forcing a pause by using Next Frame Event after processing each child group.
Eventually you might even begin this before the moment you really need the Big Guy, ergo simulating a kind of preloading, so the moment Big Guy and his Big Family are needed, most of the bread is already baked and ready to be served. :-)

[abend]

thanks fellas! yea I think the issue here is the big guy himself has lots of FSMs that all fire together when the clone is made. I wish I could kill the FSMs on the clone as they are only needed on the big guy himself. I wonder if I can maybe add some empty meshes that are duplicates of the big guy. The baby clone has no functionality, but copying the big guy has a large payload. I will have to think around this as I may be able to simplify this heavily, in the end there's not much to it.
I initially tried many ways to kill the FSMs but ended up setting many of them to check the root name, and if it included "clone" then do nothing. I'm sure I haven't touched on all of them. But maybe I could make a shell or something then just make a copy of the root objects, I will have to bounce this around! Thanks for the thought!

[jeanfabre]

Hi,

 yes, turn it on its head and make that without any mesh by default, and following some logic, you then load the mesh if needed.

Bye,

 Jean

[Broken Stylus]

Hi,

 yes, turn it on its head and make that without any mesh by default, and following some logic, you then load the mesh if needed.

Bye,

 Jean

Maybe try to have the FSMs off by default and activate only those you need from some kind of monitor FSM on Big Guy?
Do that with Activate component for example and cycle through the children.