wraitii

I'll point out that the behaviour is by design because doing it dynamically is harder, and we haven't done it yet. Ultimately, we would like to reduce the response time, but it hasn't yet been implemented.

Made a diff incorporating the idea of slowing down units based on pushing pressure around them: https://code.wildfiregames.com/D4439 I think it's a very neat idea.

In fact, doing physics simulation most likely makes them much more efficient than us. In 0 A.D., arrows are actually purely graphical, the "hit" itself is a timer (this, by the way, has a number of odd consequences, e.g. #5965 or #5964). The consequence is that on timer hit, we must query units around us and check collisions in JS manually (sorta). if there are 100 arrows, this will do 100 range queries. In a physics-system approach, the arrows would move each "physics update" through the world, a very local phenomenon that can be highly optimised. Detecting a hit is a fast operation by itself, and there is no need to do range queries. Thus arrows are not _specifically_ slow, just part of the whole physics engine. 0 A.D. does not have a physics engine at all, and it probably wouldn't work that well for us because of our 200ms turns. I suspect BAR uses a much more fine-grained "physics turn" of e.g. 10 or 20ms (edit: based on 500ms being 15 turns, 33ms) , so their physics-related lag is less 'spikey'. -- We could update 0 A.D. to have more turns and do fewer things on each turn, which would end up making it more possible to use a physics engine (though there are floating point / determinism concern), but that's a lot of work given where we come from. --- That being said, this doesn't prevent us from changing how projectiles work -> it's probably a semi-good idea to consider moving stuff to C++ and making them behave more realistically, given that the current code ends up being slow-ish anyways.

There unfortunately is: you're changing unit 'clearance', which affects pathing substantially and adversely. In particular, your units won't be able to go through some small gaps they could go through before. Further, splitting infantry and cavalry paths slows the game down. That being said, slowing units down when they are being pushed might be a smart idea, I think I'll try that out in C++ and see what happens.

I would assume they are much smarter about collision detection They probably have much more persistent data structures for collision detection in such a manner, because otherwise the game just wouldn't work. For example, they can probably first consider all formations (of which there are very few) to decide a new target to pick, where we must consider all individual units. Or another example: for the most part, they don't have to consider new units joining the battle (I think this may be somewhat different in TW WarHammer but it remains limited). That probably enables them to use some clever hacks that we can't so easily use. There is a lot of stuff happening in combat. If the target dies, UnitAI needs to choose a new target, which is by itself rather slow -> range query + filtering for preferred targets, sorting, etc. That's not even mentioning the fact that yes, dying by itself could be a bit slow. This is indeed an area of possible improvements, and some work has been done (e.g. rP25102) To be honest, the arrows range query could perhaps be improved by having some in-turn caching or some other logic to batch missile hits (so that multiple missiles landing in the same area don't do multiple range queries or something), but that doesn't sound entirely trivial to do without breaking in some edge-cases. It's always a question of code complexity, accuracy, edge-cases with these kind of optimisations. --- Edit: Also, while such "in a vacuum" performance profiling is useful when you're working to optimise a specific function, be careful about generalising. In an actual MP replay, you'll most likely see a much more nuanced picture.

For what it's worth, I'm pretty sure that the speed difference is because missing arrows query units around them to try and find alternative targets, whereas successful arrows don't. The former is obviously much slower. Thus why it seems like 'overkill' is the problem, but it's in fact just that missing arrows are computationally expensive (and every arrow after the target has been killed misses). You'd probably notice different results if you used an attack with splash, since splash does range queries anyways (as in, just much more lag all around lol). See https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/components/DelayedDamage.js$71 I think you're also compounding the results by having a massive blob of units nearby, since that probably slows down the C++ range query. Overall, there is little easy gain to make here unless we got much smarter about immediate range queries.

I remain the opinion that the only way to content all groups is this (or anyways, the idea of 'splitting our civs into balancing groups that are internally balanced but externally not so much') You make the balancing problem much easier, which lets you make much larger roster changes because you don't have to make sure that Kushites won't be OP against Romans or something, and that lets you have some actual gameplay variety both between and within groups. I think people have made the other points already.

It seems to me that most people would agree with an experiment on a self-hosted gitlab instance. It seems mostly consensual to not store large binaries, including windows libs, in the repo (not the main repo anyways). I think it'd be great to start experimenting with the above setup. Steps I see: Having a script to copy the svn history over to git. I don't think this is vital to get 100% right for the experiment because we can still do the other steps. Creating scripts to handle binaries automatically, at the very least on Windows. Vital on windows, probably good on other platforms too. This includes "storing them somewhere" Once removed, we can see how heavy the repo is, and the make a decision on LFS, IMO. Set up some CI/CD with this. The existing jenkins script will need to be reworked. That's already quite a bit of work. IMO we need this to work well Set up ticketing & issues & stuff like that. Test out the workflow. Have a script to download Phabricator metadata (issues, comments) & ideally port-them over to Gitlab. I would prefer to port 100% of the data, but not necessarily keep 100% of the "formatting". If the inline comments aren't inlined properly on gitlab, it's perhaps OK. Again, for experimenting this can be refined later. If the above steps all work, then we already have a mirror that works, and we can refine the steps for an actual migration. I can offer help with these steps.

I'm fairly sure what changed is that the tech is now recognised as being the same, and so explicitly doesn't stack. My recommendation would indeed be to just use modifiers directly. You can check how it's done in e.g. binaries/data/mods/public/simulation/helpers/InitGame.js

You mena the units overlap as if they had no collision at all? Have you tried using the template setting (DisablePushing) ?

The way I see it, we have 3 main components: the actual 'reference' VCS the development tool. That's currently Phabricator, which is somewhat git/svn agnostic, unlike say gitlab or GitHub, but like some other alternatives. the CI/CD pipeline, currently Jenkins.` The VCS question is only relevant when it is determined by our development tool, which should IMO be the focus. Phabricator works appropriately but has been somewhat of a pain to maintain, and I think we should exclude any tool that leads to more headaches in that space. I do believe the 'reference' VCS should be somewhat independently hosted and backed-up, so we don't risk losing the code or independence there. However, I also think the 'work' VCS could be something separate and we just run synchronisation scripts. For what it matters, if we could have a single tool abstracting gitlab PRs, GitHub PRs, phabricators diffs & so on, I would be very happy. Exporting data from that system should be possible but I also believe that's mostly a free space everywhere. My ranking of the issues noted by bb in the second post + 1 personal take

it is a feature, introduced in the latest alpha, referred to as "unit pushing". It makes movement of groups of units much smoother overall. You can turn it off in the pathfinder XML by setting 'Radius' to 0, or on individual unit templates by setting <DisablePushing>true</DisablePushing> in the UnitMotion component parameters.

Technically all you'd need is the lobby STUN server, you don't have to be using the lobby itself (I don't think we authenticate people anyways)

The feature can be disabled individually for ships if people prefer so. I _believe_ this is incorrect, as an arrow that hits its intended target only its the intended target and not any other target that may overlap it.

My take for now: Units overlapping is not a desired outcome of the pushing logic However, it is quite a bit harder to prevent it and actually make pushing work and/or pathfinding work. The pathfinding benefits of pushing outweigh the cons of units overlapping I don't know if I'll have time / how much time I'll have for A26. Possibly little. So I wouldn't expect this to get much worked on. It's possible that there could be tweaks to pathfinder.xml to improve things. Do you mean that e.g. A24 already had problems with this or are you talking about the A24-A25 SVN version?

I think it's left-click for actions that you click such as clicking the Patrol icon, and right-click for hotkey-triggered actions, such as attack-move (or using the patrol hotkey)

For what it's worth, my opinion is that this will never work Looks cool nonetheless. IMO there are a few basic problems: - If you want 'realistic' ship movement, you either need to have only rowing ships, or some notion of wind. Players do not want to have to care about that, and some maps could be basically unplayable if ships aren't able to go sufficiently into the wind (which, as square-sails, they might not). - If you don't want fully realistic movement, you would still need some sense of inertia: acceleration, stoppage, turn-rate. This is a rather complex problem, but it's made worse by the sheer size of ships. They are already completely unusable, so making them more awkward is not the move. Part of the problem is that our maps are much, much too small. You'd need to make them at least 10 times bigger. The engine can't support it, unfortunately. - The simplest solution is to make ships 'AoE2 like', which seems to be the direction AoE4 takes (haven't played the beta), and I'm not surprised. Basically all RTS of this specific sub-genres have done that.

(I'll ask the usual question -> are you using formations?)

Caesar III used birds to highlight fish areas, which I think is a decent and semi-realistic option, if water cannot be made transparent / people don't want jumping fishes.

There's other solutions: add some flying birds, more fish that jump out of water.

Specifically terrain textures.

This was done on purpose: https://code.wildfiregames.com/D3706#161503 The choice can always be reverted, but IIRC we had reasons for it, see convo there.

Fixed by https://code.wildfiregames.com/D4205

Thanks for the report -> this was actually a bug in the C++ height map loading code, hence why it happened there.

mh, if anything we fixed the code. it's plausible that there's still some issues that make the AI able to ignore restrictions though.