Wondering if there is a quick fix for this. I have a City Sample Crowd massspawner in a level with three zonegraphs and it works. Problem is, the AIs don’t honor the Zonegraph tolerances. I have them set in project settings to 100 for each forward and backward lane. Occasionally one AI will decide to walk slightly off the graph and bump into building (or whatever). They will continue walking in place until they hit the timing where they would have reversed course or go another direction. At that point, that AI is messed up for good, they will never return to the coordinates related to the zonegraph, though they do follow the zonegraph course relative to their new coordinates (meaning they will do unwanted things with tenacity).
It doesn’t seem to matter if I widen the spaces so they could never hit something, because they will still deviate enough to find something to bump into, and in any case, it’s impractical to make a side walk as wide as a 4 lane freeway.
It’s not really logical because the things they bump into are not in the way. They deviate even if they have not approached another AI going the opposite direction and made an adjustment. I don’t want to put an agent on every vehicle and building along the zonegraph since zonegraph is set up to clear all these things (edit, putting an agent on the obstacles does not fix the problem anyway). I really just want them to stay on the zonegraph lanes. It’s almost like it ignores the lane width and gives them free choice to go outside of it. I have tested down to lane width 10 and it still has the same problem.
Has anyone else experienced this and come up with a solution.
I’m pointing out in red a few of the tightest places they tend to get stuck on even though those aren’t in the path of the zonegraphs, on the other graphic, I show the collision which is very liberal in providing them space, in other words, they could walk through part of that gray column, but they will still wander far to the right of the building edge where I haven’t told them to go:
Just in case someone else is interested in city crowds and trying to use this, I’ll like to note my possibly flawed testing and findings. I’m not going to file a bug report because what I’m seeing has to be by design if true. I would like to discuss this if anyone is interested, and adjust my findings if they have information to the contrary.
The city sample crowd appears to work perfectly as long as the zonegraph is widely unobstructed, for example, in a completely open section of a level or very wide side walks, points of termination aren’t intended to enter or exit buildings with realistic door widths, and NPCs are sparse to where they will not collide with one another (e.g., with very wide lanes).
The NPCs involved do seem to become completely disoriented upon reaching a Navigation Obstacle even if that obstacle is decorated with an agent. The effect of collision on them, is to disregard the original zonegraph absolute positioning, but instead, to continue on the zonegraph shape/course irrespective of the fact that the collision delayed or redirected them. That is, they stick to the zonegraph shape, but after any collision, it is no longer related to the preset zonegraph’s absolute position.
If I am right about this, it’s not a very useful capability as of yet for our game unless the preset conditions could be engineered to not, in any manner, obstruct the NPC. Beyond this, the issue I mentioned about the performance hit from using it and MetaHumans (at least on a Mac), factors into our decision to go instead with a traditional skeleton (e.g., Manny) and the AI Detour controller which doesn’t exhibit either issue (since an absolute waypoint path can be set up with that method and NPCs can be instructed with refreshed destination coordinates following collision).
I would still like to hear if anyone else has successfully implemented this in a real game as it could be I’ve missed some crucial setting that would allow the NPCs to handle collision delays and redirections correctly. I’ve also pondered if collision has to be explicitly handled rather than just trusting the set up of the traits to do some obstacle avoidance under the hood.
In my testing, this issue existed at the time the Crowd pack was made compatible with 5.2.1 and has persisted through 5.3.2.
