Extremely high call #s on MakinomHandler.RandomWaypoint() [Coroutine: MoveNext] [Invoke]
Forum › ORK Support
@gamingislove
Iv got 162 MoveAI Range components in the scene. Each one has a 72% chance of spawning a single combatant, which would send the player to a separate battle scene using a group.
They are all assigned the Random Patrol schematic described in the tutorial. random wait time of 5s-20s
However when I check my editor and build FPS I drop to about 4.4fps 6 in the build. Id be happy with 30fps.
When checking the profiler i found that:
MakinomHandler.RandomWaypoint() [Coroutine: MoveNext] [Invoke] has 16263 Calls on it. using 81.9% of my threads with a Self ms of 106.28
How is this possible?
Even if X, Y, and Z are process independently of each other that should still be less than 500 if they are all called simultaneously.
I'm in 2021.3.32f Personal, using Ork version: 3.16.1 and Maki 2.15.0
Iv got 162 MoveAI Range components in the scene. Each one has a 72% chance of spawning a single combatant, which would send the player to a separate battle scene using a group.
They are all assigned the Random Patrol schematic described in the tutorial. random wait time of 5s-20s
However when I check my editor and build FPS I drop to about 4.4fps 6 in the build. Id be happy with 30fps.
When checking the profiler i found that:
MakinomHandler.RandomWaypoint() [Coroutine: MoveNext] [Invoke] has 16263 Calls on it. using 81.9% of my threads with a Self ms of 106.28
How is this possible?
Even if X, Y, and Z are process independently of each other that should still be less than 500 if they are all called simultaneously.
I'm in 2021.3.32f Personal, using Ork version: 3.16.1 and Maki 2.15.0
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Running theory
The MoveAI area is out of range of the spawn location so Navmesh is constanlty trying to find a valid place to spawn\move the AI, and gc isnt catching it so it spirals out of control.
Noticed that on some of my MoveAI cubes after duplication was for some reason set to a previouus prefabs Area (presumably human error)
In the process of correcting this. to test. will let you know.
Root cause was:
Combatant spawning MoveAI prefab field.
You MUST match the combatantant MoveAI with the correct Trigger field or it will call updates in a out of control rate.
In my case, i made a duplicate of the Prefab.
At some point I must have selected a existing trigger volume already in the world then duplicated it and spread it around. I did notice that during the process of fixing it, having EVEN just ONE setup incorrect will cause this.
Not sure how one might catch this with a catch statement, but im guessing that movenext doesn't check to see if the moveAi trigger field is valid or not. So it doesn't seem to consume the co-routine and fill up memory as a result.
Those triggers are an optional setup, though. You can e.g. also use the move AI's setup to limit random patrol range around to a radius around the start position or current position.
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!