   Steering/unit formations
  I'm doing a little experimentation with steering behaviours and their application in group formations, and running into a little difficulty. The formations work reasonably well while moving, but as they come to a halt, things go wrong. Mainly, this comes down to two related problems.Basically, when a unit reaches its goal, its velocity tends towards zero. Eventually, given that its orientation is based on its velocity vector, this ends up producing an undefined floating point value for the direction when velocity hits zero. This then throws off the desired positions for the other units in the formation as they are dependent on the leader's alignment. A smaller version of this problem is that a unit that backs slightly away from the one in front of it to give it more space has effectively reversed direction, and any units relying on that unit's direction now have a very different set of parameters to work with.So the two problems are (i) how to cleanly represent orientation separately from velocity, especially for low values of velocity, while not letting the two get out of sync, and (ii) how to cope with vectors that tend towards zero when calculating their angle and normalising them will start to produce undefined results. Any suggestions?   
  hmm, this sounds like a math problem to me, and my math is a little weak so feel free to reject my suggestion. If the whole problem is 0, would it not be possible to store the velocity as a complement?  Meaning Velocity = Max Velocity - x.;  You're right, on the whole it's a mathematical issue I'm facing, but I'm asking here because I'm just as interested in workarounds that fit the AI task as I am in absolute solutions to the mathematical issues. :)I must admit I don't understand your suggestion, but I wouldn't be surprised if my maths knowledge is worse than yours!   ;  If I understand your problem, your units always go in the direction of orientation? In that case, I suggest you store the orientation as a unit vector, and the velocity separately, as a scalar. When you need to move, just scale the orientation by the velocity.Hope that helps.   ;  Another simple solution would be to have a min velocity.  At some point, it stops contributing meaningful values to the position.  If the magnitude of the velocity is less than the clamp value, just zero it.  Over all, the separate components probably will work better; your rotation will not become degenerate.  If you did go that route, I would still suggest a min value as well, as your vector from the AIs position to the formation target will become degenerate.   ;  My units go in the direction of their velocity vector and the orientation is inferred from that. Orientation isn't actually stored at all, just calculated from velocity when needed.As for clamping velocity to zero, I'm not sure how that would help? It's zero velocities that actually cause the problems, by having no meaningful magnitude and therefore no calculable orientation.   ;  Your problem is what you basically stated yourself... Calculating orientation from velocity is a bad idea. I don't know what your units are (spaceships? people?), but instantly flipping around when the velocity changes sign probably won't look very realistic. You definitely should store the orientation because you'll need it, in the very least it'll let you cap the rotation speed at a reasonable value.I'm doing something like this in SAIS space combat when a ship is flying towards a goal:1. if distance to goal is greater than some threshold value, turn toward the goal (at angular speed that depends on ship config)1a. if pointed in the general direction of the goal and not going at max speed, accelerate.1b. if pointed in the wrong direction, decelerate.2. if the ship is near the goal (distance < threshold), decelerate.It's basically Wing Commander physics, ie. a ship's velocity is its forward vector multiplied by a speed value and there's no true inertia. The waypoint is a circle rather than a point so it's easier to stop on it. With newtonian physics, you'd make a similar algorithm that takes a "goal velocity" and calculates which direction you need to accelerate in.   ;  The simplest and most likely to match "reality" is to do what was suggested above.  Keep the orientation and speed values separate.  I quick pair of functions will combine and split them as necessary for further calculations but they can be accessed separately.   ;  Ya, sorry I was in a rush and my suggest is rather cryptic, so I'll try again.Calculation Velocity = Max Velocity - Velocitywhere Max Velocity > Velocity.Basicly it means you have to alter all your math slightly but it elimantes the problem of divided by zero.   ;In your Vehicle.Update method only update the heading from the velocity if it is above a very small threshold.