Atrik

@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

Also, if anyone interested know how to animate, we are looking for charge animation (strike while moving) and staggering animation.

Exciting news! I've finely brought this project to a testable and reviewable state. A big change since my last posts is that I've managed to make the performance impact minimal. The inertia system pay for itself and is kinda having 0 cost including the collision detection logic and other logic related to it. Having a lot of units that have the "charge" effect fighting is also demonstrated to be reasonable on performance with only a few percent increase in simulation cost for a given battle. This project have a lot of implications, and anyone willing to be testing the PR and giving feedback would help tremendously to make it move forward. If you are able to, please do. PR link

OP! Start with that next time Already thinking about merging this into gigabundleUI

Screenshots please

Thanks the bots for the up. I missed that. Who won this priceless prize in the end?

I'm on a forum a lot and I had miss both your posts still. I only dug into the issue when realizing the bug myself. Since games can have diplo turned off, there is a small chance this bug could have even made it to next release unnoticed even... This is a formal invitation to help on git by opening tickets when you encounter such bugs..

@Stan`