Atrik

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.

I think 0AD engine should try to get the features to get a variety of mods working on it. Not even just the engine but the scripted simulation part too, so that modders don't need to code everything from scratch. @Eilat if you encounter limitations while doing your mod you should definitely open issues for them, I doubt anyone would be against it.

Noted, yes after some playtesting also with @Effervescent it was clear that we should make infantry have more agile movements, which is mainly suppressing restrictions on turning. We also had interesting talks about using the new parameter "MaxAngle" to have ranged units in general start the attack prepareTime/animation while turning (they start drawing an arrow while they turn, so it makes micro interesting). I think i did increase the value of pushing a tiny bit, but maybe before reverting I would try to see if you think it's better with the lowered Inertia effects (they are more agile so maybe it would fix it for you). I guess I did set a "stagger recovery rate" very low in the templates So you are right. I didn't, but I should have saw it come. Yes this is one bug that is from this PR obviously, I can address that. The other ones I'm not too sure, the woodcutters getting stuck happens a lot to me in MP. Thank you so much for the feedbacks! I have a much clearer idea of what this PR needs now. Mostly tweaking the templates and fixing the big boys club dances.

You can see how "solid effect" of "stiffness" impact the boats in the video. You get super cool effects when there are a few ones, but a lot of them result in them taking a lot of time to settle. It's fine for boats as you rarely think of crowds of boats, and I just made a scene for this in the video to show that it works, and still look good for them. But if you have a crowd of infantry constantly wiggling and taking forever to settle, this would look very bad. Hence the spring. Inertia and pushing aren't the same thing. But for navigating on open terrain, this wouldn't change much. However if you try to funnel "solid" physical bodies into a choke-point, they obviously take a while more to achieve the same movement. So if ever we wanted to make cavalry "solid bodies", with this PR it's only just one tweak in their template. But because big crowds of them cost more to simulate and that moving them around take longer if they are in high number, it should be accompanied by an increase of cost/population for example. The pros are that they will have much more realistic charge effects, like you see with elephants, but cavalry have less contact area and are moving much faster, the physic outcome would be different too (like a cavalry can trow fewer infantry units away but at higher velocity). So this is just a balancing change, out of scope. Even without proper "charge", -so just using the old pushing pretty much as it was, the inertia improves physics for cavalry fighting at no additional cost. The cavalry can push away other spread units thanks to it's superior weight, and also push its target by a little - even if ideally it would be more, and the cavalry would be smart enough to take more advantage of it instead of stopping once in front of it's target. Screencast from 2026-09-22 18-44-41.webm

You are such a gigantic troll But I'll bump on it still, and give some nerdy details. The collisions between units are not indeed like solid bodies that are impossible to overlap, even with this PR, this will remain true for most units. It's more a spring-like push that tries to make units keep distance to each others. This pushing just use a distance-to-center repulsion force. What's introduced here for boats and elephants is a different stronger pushing and that actually take the unit's shape into account. This is why on the video you see that the hulls act like actual solid bodies. However simulating this, is ~x1.5 time costlier then the simple radial spring pushing. So because that, for small units, the difference in visible behavior would be minor, better go with the simple pushing, and use the better one only for big units that get the most benefits from it. A fun fact is that before this PR, all units were treated the same, so you did had still this radial-pushing for boats (the collisions were spring-like and only a small circle at the center of the boat was even acting as the hitbox) but it was still much bigger then for, say infantry. To detect if units were colliding, the map had a grid that allowed each unit to search a limited area where it might be actually colliding with other units. This grid size had to be proportional to the largest pushing unit of the game : boats - who's pushing effects where questionable anyway. Even if you played on mainland map with no ships whatsoever, the grid was sized to work for boats too. And your unit had to check their distance with much more other units they needed to. So you can say that the lag you experience on mainland, was partially due to ships. This along a few other optimizations with the pushing and more resilient obstruction handling, make the PR a performance improvement for common scenarios (yey!).

Screencast+from+2026-09-22+02-47-35.webm Screencast+from+2026-09-22+02-49-43(1).webm Better? Also another demo about cavalry movement now : Screencast+from+2026-09-22+02-53-38.webm

My favorite too Hopefully it can be a good starting point to make naval battles very different then land battles. Right.

Unfortunately it's mainly modifications to the game engine itself, meaning it's not possible to wrap into a mod. But I can help out by providing a couple of demo videos for you : (I had to compress the videos) Screencast+from+2026-09-21+22-14-52.webm Screencast+from+2026-09-21+22-13-08.webm Screencast+from+2026-09-21+22-11-19.webm For testing you will need to know how to compile the game. Which makes things difficult I'm aware.

Dang, I really should start tryharding 1v1s