We have this huge project with different sized units, that are controlled by detour crowd controllers that get their movement orders by the player (RTS like gameplay).
We use nav mesh walking for the units and units are constantly getting stuck on edges because the agent radius on the character movement component was alwas -1 with disabled “UpdateNavAgentwithOwnersCollision”. So why not checking this checkbox to use the capsule of the unit as agent size.
It worked - no more stuck units BUT the capsule is suddenly not detected by triggers (OnOverlapBegin and -End) anymore (which makes no sense to me). When I spawn a unit in the base (which also has a collision sphere) it fires overlapBegin and overlapEnd at the same time but is still in the sphere. Why? what am I doing wrong?
I setup different SupportedAgents for different sized units in the NavSystem settings and only have one collider on each unit.
(When I change some settings and the unit is not connected to the nav mesh, the triggers suddenly work again)
Pretty sure I had the same type of problem. Try changing the collision settings on your units and on your walls. Make it so triggers act as something like “Destrucible” and set collision on your units to only overlap with “Destrucible” objects. This property setting should be easily editable and testable…this is how I made my overlapevents work with certain units, while ignoring other overlapevents of different units.
Thanks for the response. But that didn’t change anything. It’s almost like the character movement consumes the capsule component of the unit for navigation stuff. It is just not recognized by triggers after the movement component is initialized. But the capsule is still there and the collision settings are correct, too.
Okay, wow. I think I found something while looking at all the engine code. The nav-walking mode changes the settings of the capsule collider (object response of world static&dynamic) every tick to [Ignore] and after that back to what was before. But when the overlaps for the triggers are checked, it is changed to ignore and thus not recognized.
So your answer really is a workaround (I tried it again and now it works, maybe I didn’t compile correctly the first time… hehe…)
But when I setup a demo project with just a few AI characters and the same nav settings, it just works without the workaround.
I just found something in the udn forum about that:
Collision is disabled on purpose on both channels, because both are being
used in game to represent collision of
world meshes / objects. Yes, it will
allow pawns to move through geometry,
but that’s the whole point, trade
accuracy for speed. If your triggers
should react only to objects on pawn
channel, which is usually true, adding
new collision profile is best
solution. Otherwise, you’ll have to
leave world dynamic channel enabled,
either by modifying engine’s
CharacterMovementComponent or
overriding SetNavWalkingPhysics() in
game specific implementation. We do
later in Fortnite, where collision
settings depends on custom LoD for
pawn, rather than just movement mode.
Yea I didn’t explain it very well, but I’m glad you got what I mean haha. I’ve been using that as a work-around in my project…not sure of another way around it
