wraitii

I've merged a substantial change to unit pushing in SVN. You should be able to test it out starting tomorrow. There are new parameters, and overall the behaviour of the system is IMO much better.

It's fine on minimal resolution, but I'd rather not inflict this on other resolutions if we don't have to. Yeah. I think it'd generally look better. Might be weird on the biggest screens, but it's going to look a little weird on the biggest screens anyways so. Yeah sure. I'm just giving you my opinion haha. IMO the 'art-deco' box border is out of place. I preferred this one if we're going for art-deco-ish. I would probably prefer something else still, but I'm not entirely sure what to be honest. I actually liked the initial pyramidal notch, even though most of you seemed to think it wad 'too modern' haha. But the rest of the menu is super sleek and modern so I didn't really mind. That being said, this is just my opinion and I can certainly get overruled. It's not like it's the ugliest thing on Earth either, just not my preference and I think overall it's still an improvement on the current menu.

I would definitely keep extending the top border over the whole top regardless. Also IMO definitely worth considering JS to extend it, the buttons taking two lines instead of one makes it much uglier. I also rather dislike what's happening in the bottom corners on the 0 A.D. box, but I think it's the same as the one I complained about lol. Wow's design didn't have that and it looked much better IMO.

You could probably use javascript to make the width of the top-bar only extend up to a certain point, and then just have empty space on either side. This would fix Vlad's problem I think. I agree with wow, the square-box-single-line design is kinda boring for the 0 A.D. box now. I disliked the original because it looked inconsistent IMO, but now it's boring. As a matter of fact I think wow's design here is best so far, but perhaps just extending upwards instead of being closed. I would definitely go with the 'not center the logo at the bottom off the top menu' option, which looks much better than the bigger box IMO. I agree about the 'Empires Ascendant' text, but since I suggested moving the buttons upward, I would suggest putting it below the buttons (Edit -> that being said, maybe moving the buttons further down is better? Seems like it would be for DE's main menus anyways).

I think I preferred the earlier "pyramid" look to the box, which IMO looks too busy now.The double-border is also inconsistent with the single-bordering of the rest and I think it makes it look a little awkward. Perhaps you could pick a trick from the Roman playbook and have "middle dots". That being said, IMO the bigger "0" and the smaller letters with dots looked better overall. Yes it's more symmetrical here, but I think it looks worse. Perhaps you can find a balance between both approaches. Other suggestions: I think the text in the top row is a tad dark. You could perhaps push the middle-button-row a little higher (have it split the screen ⅓ - ⅔), this would leave more room for the background, and possibly any information we might want to show there. IMO this looks great overall and we should consider replacing the main menu.

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.