Atrik

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`

0 A.D. use it's own homemade engine and I don't think that will change anytime soon. Also starting from scratch makes the project above like not that much work in comparison lol

I think the project below has a lot of support : But it's an herculean task, and I still have no idea how one would bring it to be implemented into the game. There will be a tone of work too for reviewing the proposed (sizable but not crazy neither) engine changes, unit balancing, testing, maybe even adding some animations to make it extra-cool... Also there is the valid concern that it would inevitably add a bit of extra load. I took an approach that's actually super cheap on performance to simulate the interactions but some extra checks to handle collisions while units move with inertia seems unavoidable; and they however, add up a bit of load. So it's difficult to tell if in the end, it would be considered worth it, or be blocking the whole idea.

I like the idea of turret points on boats. I think it would go well with #8957. In my opinion we also need some logic to allow shrinking turetable unit model's => When a unit is turreted on a boat, it become 20% smaller. Just for visual consistency with boats being a bit smaller then they should. Also as you pointed out, units should die when the boat sinks.

Post your issue here or another thread, if I know how to help, I will. If not, someone else will probably

@razieve thanks for reporting this. I can confirm this is a ModernGUI bug on the development version. A condition was poorly written which created this ghost foundation in some edge cases. It will be fixed next time I push my local work. In the meantime you don't have to worry about it affecting your game. This foundation placement doesn't consume any resources, nor creat any obstruction of any kind. Basically it doesn't affect anything, but you can still delete it to make it disappear. If you want, you can also enable 'global queue' feature to make this work, where builders will start building the foundation once the required resources are reached.

Sounds like something that should be handled in vanilla and not require mods to implement the logic. You should open a issue for it, I might pick it up myself. If you do, attach a dummy template of boat with turret point to make the testing easier. Or if you can't wait next release and you just want to do it yourself, please open a PR on main repo that would be most useful.

Yes I did fix this bug with @Vantha in #8652.

@manowar, I will make a PR for the fix I suggested. I've just tested it and there doesn't seems to be any complication to it. It will fix a lot of bugs that happens when the territory owner and building owner are different players. Here are the results : The territory line still visually slightly goes into the CC footprint but that's just the polyline smoothing rendering of territory lines. You can still propose your PR if you think it make sense balance-wise. But as a fix, I would consider it improper, and I prefer to fix the underlying issue if it's possible (and it seems to work).

Buildings don't decay because they are outside your territory (in 95%+ of cases, they sit on their own territory influence), they decay if not connected to a root. This would be unchanged. Territory ownership and connection to territory root are two different things. So nothing will change if you capture a CC and opponent have no other root attached to buildings => all buildings will decay. Your opponent will still own the "blinking" territory until the buildings are decayed to a new owner (unchanged and unaffected by proposed modification).

There is no need for whatever complication you imagine. We just want buildings to always be in owner's territory. Which is how it should be, you cannot own a building but the land is to someone else (in this game at least). If this land is not connected to a root, then all buildings on it decays still, like what happens commonly in games when buildings are reasonably spaced. Basically in the picture with the CC in the comment above, the territory line would be between the CC and the barrack. There will be no more territory lines crossing buildings, which makes sense. None of the decay conditions are changed, beside that now the CC center point will actually be in the owner's territory (as it makes intuitive sense) and therefore buildings in the territory won't decay unless the CC is totally enclaved.

Meaning another building cannot extend the territory into another's player building. This should still allow decay if this piece of territory is not connected to a territory root. Your misconception here is to think the building needs to be outside his territory to decay but really it's about being connected to a territory root. In the scenario with the barrack, the territory limit would happen exactly between the CC and the barrack => not into the CC

One fix idea, although haven't digged into what would take, could be to have building footprints (their size) always be the territory of the building owner. This would kinda make sens too. Maybe I'm overlooking some potential drawbacks of doing so.. Anyone can think of one? I think for non-root, this shouldn't prevent decay if not connected. IIRC I noticed a bug where dropsites, owned player but "outside" your territory (example enclaved by an allied barrack) is not considered by your gatherer. So that would also fix this kind of bug.