I am making an RTS game where each unit is a character. The Character blueprint has a static mesh with a navigation box collision. The AreaClass of this collision mask is set to NavArea with a high default cost, so that the characters try to avoid one another. The problem is that sometimes they do that and sometimes they don’t. Using the console command Show Navigation during runtime, I can see that this occurs when the NavMesh cannot keep up with updating itself (is red when the character is moving). But this is really weird, because I tried it with only two characters with various settings of dynamic NavMesh updating and it seems like the engine can’t cope with it. Am I doing something wrong, or should try a different approach?
That would be most probably the same as changing the AreaClass of the box collision to NavArea_Null, which I have tried with a lot of setups. Apart from that, the volumes would have to be spawned along with the characters and moved with them. Achieving this through BPs is, from what I know, impossible as the mobility property cannot be changed within blueprints.
Have you tried going to your character Blueprint, Components, and Add Component Box then selecting the appropriate collision for the box? Being that you can have the different components of a blueprint having different collision presets I don’t see why this should be more difficult and as it spawns as part of the Character blueprint it should be less taxing on the system than attaching something to follow the Character.
The collision mask created in components tab of a blueprint creates a Null NavArea by default and this does not work in general. The characters create an untraversable area around them and consequently when using Simple Move to Location (or Move to Location) they try to “avoid themselves”. This results in really weird paths generated, even more frequent character collisions and a complete mess when a character tries to find a path when located near enough another character, so that their Null NavAreas overlap. I think, that the character movement works best when it is capsule-based as the capsules affect NavMesh in a more friendly way I suppose, but in my case I need to have only static meshes with box collisions.
Yup i use this exactly setting to make all collisions more flexible.
In my setup most outer mesh is overlap mesh that is used for detecting overlap events only, because hit events somehow do not register sometimes.
Then i have collision mesh so other physics actors just bounce off it (after overlapping previous mesh)
Then i have invisible box for simulating physics (because different shapes have different center of mass, constantly tweaking it is waste of time). I connect all thrusters and motors to this mesh.
And last, smallest mesh is my actual spaceship visible in game, it has no physics, and no collision, holds all visuals like emmiters lights etc… This way i can scale it rotate or replace without need of tweaking everything once again.
PS. you could update nav mesh only after each command. Or make static nav mesh then add own logic for collision between units.
But unfortunately implementing such setup does not resolve the navigation problem. The characters sometimes avoided one another and sometimes did not. Actually, I can say nearly instantly after giving a move command whether a character calculated a proper path or not, because when it “knows” that something stands on its way it moves not in a completely straight line to a destination even at the very beginning. But if something goes wrong (which in my case occurs often without a reasonable explanation yet) it acts as if there is nothing on its way and goes straight to the target point and eventually bumps into another actor.