@Thalatta, I'm glad you built, tested, even more so dug a bit into the code.  For your proposed change, I'm pretty sure I can make yourself disagree with it. You might have noticed collisions already take into account relative speed, by scaling the magnitude by it. What you suggest  is to set it to 0 whenever the units move apart (or stand still since you used >=), completely. But that doesn't make physical sense, and would now allow overlapping. Yes, some small wiggles are expected in any case. But they shouldn't look like units are bouncing. And they should settle very fast. Is your tests using the updated code (after i replying to @guerringuerrin)? I cannot reproduce such sever bouncing with it.   Part of my last tweaks, for "solids" the soft push that extend beyond the actual unit footprint (used to try to have them spacing out more naturally) have very dimmed effect on spin. This help individuals in herds keep their facing direction under control.

Hello, I currently running 0A.D. R28 and DE R28, great work! If I play with Cimbri and if I recruit the clubman raiders in the Civic center they slowly die (about 1 minute after recruiting). The only way I found to make them stay alive is to garrison a temple... Is a bug or a feature? Thanks  

@Atrik, bouncing is expected since you are using linear pushing, and that's how springs work. A simple "fix" (or at least to show where I think the problem comes from) I just tried is not to keep pushing when the object is already moving away. In these test videos, I split all elephants in two groups and make them move against each other, press abort, make them go through a narrow path to attack a structure, and when they are concentrating on top of where that was, press abort. Notice the lack of bouncing in the second video (the one with my change) after pressing abort: Recording 2026-09-30 104423.mp4   Recording 2026-09-30 104650.mp4   The code I added to UnitCollision.cpp before the last line shown: const CFixedVector2D relativeVelocity = a.velocity - b.velocity; const fixed separatingVelocity = relativeVelocity.Dot(offset); if (separatingVelocity >= fixed::Zero()) distanceFactor = entity_pos_t::Zero(); CFixedVector2D pushingDir = offset.Multiply(distanceFactor); The fix doesn't have to be exactly like this, it could be a function depending on the relative velocity vector for example (to better handle any unwanted increased overlapping), but I think that's a simple way to add non-linearity, besides being realistic: a push is a force applied in a certain time interval (impulse), and this process is usually more inefficient if during this time the object moves away, because what's pushing falls behind of what's pushed. This is related to mechanical impedance, and that's why springs react more when pushed at their resonance frequency, since that timing doesn't fall behind, nor gets past, the points of most efficient energy transfer. I didn't notice a big difference when they went through the narrow path, but the unit's rotation when pushed seems to be quite a problem. I'd make torque effects more inefficient by, quite obviously, either making them more spherical or changing their moment of inertia, if that's how things are implemented (I haven't checked that).

Create something similar for my mod using AI—it might be interesting:  In this new combat mode, it's possible to play using area control or head-on battles like in *Total War*; for my futuristic mod, I intend to focus primarily on area control, though nothing stops me from removing the control points and reverting to classic *Total War*—if one can even call it that.

https://www.danielkirkpatrick.co.uk/irish-history/irish-iron-age-chariot/ https://www.researchgate.net/publication/246543302_Iron_Age_chariots_and_medieval_texts_a_step_too_far_in_breaking_down_boundaries I've found some articles arguing for chariots at least. Although i dont know if there is a consensus.