Atrik

We don't decompose the collision vector. We calculate the resulting impulse from the contact normal, and the spin actually comes from calculating the torque given the impact position to the center. Since the shape is (almost) a rectangle, then it's just about calculating the lever effect on a axis - the contact point projected on it. Velocities are also calculated based on this closest point. I think to apply your idea it would be to add a scaling to the lever effect? But I'm not sure it's always desirable, for example on the choke point wouldn't that create more units facing the wrong direction of movement?

Wait, but I told you it does for collision, just not for the 'soft' push who are mostly meant to keep units apart more then simulating a collision. So for 'soft' pushs you don't really want to scale it down with velocity. It's not so much about complexity you even tried yourself it's just less then 10 lines of codes, less if we refactor with the one for collision. But why would it help rotation here?

The shape is a radius around a segment, a 2D capsule, which you generally picture as a rectangle but for small segments, it start being more circular. They are, and for boats their footprint shape was displayed as it was (the champion ele had the triangle one because it's a champion). Since they are long shapes, there it looks more like a rectangle then for elephants. So I was approximating them as being all rectangle, but now that it is drawn for elephant, it's obvious that it's a bit less true for them. Although they are still pretty close to a rectangle. For buildings, it was always was one contact point anyway, as it doesn't use the hitbox used for pushing. But the example you gave was still trickery! The wall was blocking the unit from complying to the push because of having one less degree of freedom.

This hitbox you used are the model's bounds but aren't accurate to see what the unit collide with. It's my bad for not doing the obvious : adding a debug for visualizing the actual footprint used for collision. I was debugging mostly using boats to this time because they have everything more extreme than elephants : inertia, size, and they even have drifting effects. For them, the footprint is already accurately displayed when you select them, but now I added the debug so we can also see it for elephants. Also it made me realize that for boats it's fair to approximate their shape to a rectangle, but not so much for elephants who have different ratios, so when we spoke about corners, we highly exaggerated their extent for elephants : Yellow is the debug footprint. You can now display it by enabling Unit motion overlay and selecting the elephants. I'm convinced that a lone elephant pathing got better. He'll be more resilient to solving hitting a building corner for example. Lone elephant with other non-solids that used to block them it's even more obvious. I'm doing the tweaks I can to make herds of elephant not too terrible but they will always be less agile then normal units @real_tabasco_sauce do you think we could also slightly increase both their pop cost/res cost, and make them a bit more tanky? So that you get their new ability with micro but getting tones of them is still not as easy?

It is kind of the case depending on how you look at it : We could say that units aren't actually pushed, they just look at every neighbor that look too close to them, then they move away from them. Consuming all forces they calculated, tells them where they have to go for this turn. So it's them actually moving away.. Well since all that is a bit some abstraction of physical events probably there are as many way to phrase it as you want. Edit : I meant is that the pushing range is already some kind of way to communicate to units to move away. But maybe if you wanted to add one that apply only to allies but further then the normal push one, it could be a good idea for example for rams where you want them to push allies but enemy can still block the way. It's a good idea. Edit 2: Now I have regret dropping my initial approach about a forward area in front of units used for charging, that would be maybe a few lines of codes to just make it possible to apply to allies only... I'm glad for the involvement, it shows that this is an interesting topic and that many things will sprout out of it. In fact, a big highlight of this project is that it will be easy, even from a mod, to plug in forces into UnitMotion. Examples : weather, spells (attractions, repulsion)...

Like a simplification that doesn't account for friction?

But right now a collision is only detected once for a pair. I imagine this idea would require to do two. I did a quick attempt for ellipse. It wasn't going in the right direction so I dropped it. Thinking about it I think I can explain why it's a bad idea : ellipses are too good to tile up a given space regardless of if the shapes are aligned or not, creating interlocking patterns. A drawing not at all accurate but to give the idea : For the same area, the ellipses can compress easier regardless of orientation. Whereas the rectangles force a spacing. And there corner impacts actually helps keep it that way. Really? Where can I get it?

Well the shape is taken from what already existed in templates, and they can only be rectangles or circles (not related to 'solids' and non-'solids', here it's just the 'footprint' => exactly like buildings, they can be either rectangles or circles). Also the rectangle is better for code simplicity. Also "attacker" in this case is a bit vague because it means fastest unit of the two who collide i guess. But that would make things super complicated

Well the only parameter you can play with currently, that doesn't require to hack the physic of the collision is SolidPushSpin as said. If that ends up to still not be enough I still think it's currently fine for now.

Well two things were contributing to this and got better in this PR : 1. Elephants were unable to push other not moving units. => Now they give 0 sh!t about any dwarfs sitting on their path. Which increase their mobility by a immeasurable amount already. 2. Obstruction handling was not too resilient. => According to path requests sent, on my benchmarks, the path requests are down by a lot relative to main, meaning units handle obstructions better. Yes making them "solids" is very challenging on plenty of points. But I have a feeling it's doable, let's see if @guerringuerrin find a way to prove we are still far off succeeding. With the UnitMotion refactoring of this PR, iterating is also much faster, and things are compartmentalized.

They do! @Thalatta is just master trickster here! Joking, but maybe we can increase the SolidPushSpin as explained above. I had this parameter added before doing the "push only if we have room to push", so maybe a higher value now will still results in still acceptable level of wiggles.

Well here you are trying hard to make the geometry show it's limits In the first example, a rectangle pushing another one against the wall is kinda expected to do this slide. In the second example on open terrain, I see you manually try to aim for the elephant's center, despite it trying to rotate!! But you can actually try to tweak values even without recompiling : in `pathfinder.xml` you have the parameter `SolidPushSpin`, which makes the circle pushing/soft pushing impact more or less units spins. Currently it's low (0.25), if you increase it, your elephants will spin faster in that case, but this also means elephants moving shoulder to shoulder might also wiggle a bit more.

Yes they are. Well for the most part. There is also soft push gradient (not really the hitbox, but like a softer wider hitbox) and also some logic that tries to push if two bodies already overlap.

Can't tell in from the picture, but it's also very possible that the elephant here was stuck at this angle due to the ones pushing on it's butt... But this should happen less often, and elephants should be able to unstuck themselves sooner now. You can also enable "UnitMotion" in dev overlay to display the path, this can help figuring if it's actually a pathfinder weirdness or a bug.

@guerringuerrin I was about to post when I realized you posted . Nevermind I'll keep mine as I wrote it initially. And make some reply to yours after. ------------------------ Unless... Screencast from 2026-10-01 13-50-02(2).webm x20 speed, no orders but 2 step rally point. For nerds, what changed (main changes) : Contact slides, solids slide along each other in the direction they want to go. This fix solids getting stuck on chock-point. Solid are only sensible to soft push if they actually have room to be pushed to. This makes groups of solid expand outward and prevent wiggles because now they only push in one direction. Minimal cost, just coarse grid check. Note : Also this idea is a bit of the same than pressure for non-solids. Excepted pressure wouldn't work for solids because their shape is different, and the pushing is different too, so its barely more costly, but works very well for solids. Improved contact logic so also actually even less overlapping on choke-points. Ok but now, the question is... Will @guerringuerrin manage to get some elephants stuck this time?

@real_tabasco_sauce there is nothing that force elephants or boats to be "solids". Above you have videos of cavalry charging some civilians, you can see it's still doing some physics, but if you don't add "solids" to boats and elephants : 1. Their collision area is a circle at its center, so things that hit him and that he hit don't spin him as much as you'll expect have to hit him at center, front and back are ghost parts you can just go through are weaker (elastic) 2. Path-finding don't ignore idle units so they are considered as obstacles

Well apparently this thread is already about trying to get units that both try to not overlap, and still manage to move around in groups of 50 without too much weird stuff happening...

Yes but it might not be the reason they freeze here, I think in your video it's mostly elephants pushing on each other's butts so they have a hard time facing the right direction and continue walking. Or maybe trying to reach a waypoint - a intermediate path goal, given by pathfinder -, but since a bunch of elephants are in the way, they wait trying to reach it. I think I can try to make these better. However I'll disclaim once again that this new "solid" propriety was designed for rare units, to have a very visible superiority when they collide with normal smaller units. So a large herd of elephants that get this "solid", will always be less agile then other units : they are not made to be in large groups.

@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. The part you changed is the soft push, which only depends on how much the units overlap. That's on purpose: it's what gets overlapping units apart. With your check it's set to 0 whenever the units move apart, or stand still since you used >=. That doesn't make physical sense, and would now allow overlapping: two idle units on top of each other, or two units walking side by side at the same speed, would never be separated. 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.

Yes a herd of elephants getting stuck on a narrow path is somewhat acceptable but in the video the bouncing was way too awful. The reason why I would give this new "solid" propriety to only melee elephants amongst all land units, is that it's one of the costliest units. And "solids" having inelastic strong pushs, it will always make a large group of such "solids" always a bit tricky. But it doesn't mean that it should look as sh!t as in your video neither. I found a few bugs, improved some of the physics, and made couple tweaks that try to address that. Ideally we can still have "solids" do the minimum of overlapping. Tell me if you manage to test and still reproduce the weird bouncing!

So @MarcusAureliu#s is OP?

Ah right this might be a tough one to do. Terrain modifications would be op though. The first thing I thought you wanted to do is some kind of model representing the crater. But even this my have a whole bunch of challenge to get along with too...

For this the projectile can probably spawn an entity (the crater) with an aura (slow units in the crater), have you tried that? What would cause performance issue?

In the code there is a TODO comment that hints that terrain bonuses already existed in 0AD, but got removed .

A recent example is @Vantha and I working on improving ranged attacks, so that units can have a range much larger then it's vision and still be able to attack. Perfectly suited for like long-range artillery that needs intel on it's target before firing (like a infantry recon commanding artillery fire, or scout drone...). I actually did have in mind one of @Eilat's post with ICBMs when doing it.