wraitii

As Stan said, the idea is that you use gitlab directly. Just make a Merge Request, you can do this online via the web editor or using git or using the gitlab app (I think). As for 'What standards are used to determine if a mod is suitable?', the idea is that the community will self-manage, but so far only the 0 A.D. teams are maintainers so we would merge things. Ideally people will react to changes here or on gitlab directly. At the moment, I'll probably merge simple changes that are widely agreed upon, as for A27 essentially.

Err, not really. It was created to make the job of balancing the game easier and allow the community a more obvious place to contribute gameplay effort. It happens to be an obvious place to fix some issues that we've missed as well, but we don't intend to use it as an auto-updater, because it cannot be one. The main problem is that we currently have no automatic download of the latest version of the mod. -- Anyways, for now it remains not super useful -> I am looking forward to gameplay balance and contributions there, though possibly Alpha 26 is perfectly balanced

To be honest it seems to me like AoE 4 (our main competitor lol) is doing quite similar to us in terms of unit overlap. But we can always experiment further.

In a good or a bad way ?

I believe you only need to de-activate it once, then load the gameosetup, and then you can re-enable it

@chrstgtr I'm wondering if you notice a difference with ram and ram pathfinding. My hunch is that it should be better in A26 with the improved unit pushing. And overall much, much better than A24 which had no pushing at all. I'm also curious about unit pushing improvements in a more general sense, how does it feel?

It's that same mod. We're just going to use it to fix these limited issues as well, since we can

I think people need to enable it in MP, then people will see that others have it and download it.

Yes that's the idea. I do think so, but I kind of intend to let the community actually handle thing here.

My perspective is to start with small things that people agree are OP or broken (such as the Han thing I fixed). As a maintainer I'll only merge stuff there that feels consensual enough, whether that comes from a PR on the mod or from a diff that ended in A27 from A26 playtesting. The idea of the mod is to allow: Having an A26 that's playable in MP Allowing some experiments potentially in a slightly easier way

Hello everyone, The mod is now live! You can contribute over on GitLab at https://gitlab.com/0ad/0ad-community-mod-a26/ The mod can also directly be downloaded from 0 A.D. using Mod.io. The current version, 0.26.1, incorporates the Han rice/grain fixes as a demonstration. Feel free to reach out to @Stan` or myself if you would like to become a maintainers. Otherwise, open the web IDE and get ready to make PRs!

I think the best comparison for us is Age of Empires 2, I believe DE also uses a turn-rate with command-delay system. However, I believe they use adaptable and lower turn-rate / command-delay, so you usually don't notice it in normal games. If you end up in a situation where you have lag however, there is a noticeable delay between a click and the corresponding action happening.

Correct, the 'turn length' was 200ms in SP / 500 ms in MP, with command delay set to 'next turn' in SP (which can range 400-200 ms). I've changed it to 200ms everywhere, but the command delay is 3 in MP, which results in 1000-800ms actual delay I believe. One thing to note is that the graphics are always 'one turn behind' the game simulation, as we need to know what happens between turns N and N+1 to render turn N. So even though SP actions take place on 'next turn', that's at best 201ms away. Lowering the command delay would be possible if we had better lag mitigation, and could adjust on-the-fly, but works remains to be done here. Adjusting the 'turn length' requires optimising the game.

For the record, I setup a default of 10 because of @nani's comment here: https://code.wildfiregames.com/D3737#162803 I don't have any strong opposition to changing the max lag to -1.

I believe GUID is the unique identifier for a network peer, so it sounds correct.

Just keep in mind things need to be deterministic across players

I think if anything turns should be made shorter. Average/total load is not the right metric: it's much better to spend 2 extra milliseconds on each frame (16 -> 18 remains smooth) than stopping for 20ms every 200 ms. There are however other considerations: With shorter turns, we could potentially run some computations only on certain turns (this is tricky, but becomes possible. E.G. maybe we run short-range paths every two turns or something) With shorter turns, pathfinding behaves much better With shorter turns, there are generally fewer events per turn (the main source of 'stuff happening' are timers & range queries), so any individual turn tends to be faster. Note that I haven't actually done the math on this. I think ideally we'd run turns every 50ms or so, with network delay in the 150ms range. This seems like what AoE 2 is able to achieve and it's very, very smooth.

It's complex, not necessarily outstandingly so. But mostly I don't think it 'breaks' the flow of anything, it's really just a long reloading time and with some cleverness it could be hidden. I don't think it's particularly a problem here.

I'll try and get some smaller instructions in the repo and I'll ping you

Indeed something to be discussed. That being said, my intention here is more the former than the latter. I hadn't really considered it, but I think I could maybe set up a branch system to have variants of the mod, so you can use the provided infrastructure for other things. Alternatively, you could just setup forks that implement entire redesigns.

I do plan to have some screen on the landing page if you've activated the mod, but that'll only be for signed versions of the mod, which I expect to lag behind the 'fastest' stuff. It's going to be a little awkward, unfortunately, but less so than having to actually apply patches or something Not doable for this release either, though yes that would be a nice feature.

Hello everyone, LINK: https://gitlab.com/0ad/0ad-community-mod-a26 Following recent & less recent discussions on the forum, the team has a proposal on how to improve balancing that seems viable in the short term. This post will explain the 'what' and 'why'. What We will make a copy of the files relevant to balancing (templates, civ data, techs, ...) as of A26's release, and create a new repository on Gitlab. This repository will be bundled as a 'A26 community balance' mod, and regularly signed & uploaded on mod.io by the 0 A.D. team. The mod will also be easily downloadable directly from gitlab. Community members will be granted commit access to this repository, on a voluntary basis, by 0 A.D. team members. This commit access is subject to the expected rules, such as not trying to mess everyone's work and generally behave productively. More generally, the mod will be public and anyone can easily make PRs using GitHub/gitlab's interface, and people with commit access will be able to merge PRs. This mod can then evolve on its own after A26's release, independently of 0 A.D.'s work towards A27. Why We agree with you that balancing is a sore point for 0 A.D. The issue is complex, and the team lacks time to fix it. Previous efforts, such as the balancing PM or the balancing subforum, did not work well enough. Furthermore, we receive a lot of feedback from the community on gameplay and would like to give the community a more hands-on approach. There are far more players than team members, and we hope that having more people with commit access will speed things up. We understand that Phabricator is a little unwieldy. Using a better known tool will also make it easier for people to make changes. We cannot currently give commit access to the whole SVN repo, nor can we easily split the 0 A.D. mod to make balancing its own repository. Making more regular releases seems unrealistic at the moment. Migration to gitlab is also a work in progress. Therefore, we think this is an easy way to make strides forward while not increasing the workload of the team too much. By making it a mod that can easily be downloaded, and that's provided by the 0 A.D. team, we can somewhat ensure that the mod will be played, and thus a better product. This also relieves the team of some of the pressure of balancing the release right away, since we know unbalanced units (which are somewhat inevitably discovered after release) can be fixed. What happens with A27? This balance mod's scope will not follow potential engine changes in A27, and may not be immediately portable when the time to release comes around. Our hope is that, by comparing the mod with A26, the 0 A.D. team can understand the direction that things should go in and port relevant changes in a coherent manner. This will almost necessarily lead to some changes not being ported, or to some work being necessary to do so. To summarise: we'll give you the keys to the car to make A26 a more fun game. By the time A27 comes, we can hopefully use your work (and our own) as a good template for a better game out of the box. If this experiment is a success, we may reproduce it after A27, but time will tell. --- The repository will be shared around the A26 actual release, to make sure the files are indeed those from A26. In the meantime, feel free to share feedback on the idea and indicate what you'd consider a fitting role for yourself.

Not really, could well be a bug. Might be fixable in JS though since I think that's what decides decay.

Note that changing the cavalry to use its own pathfinder size would be much slower, but changing the pushing logic is cheaper and perhaps doable. On chokepoints specifically though, the 'bogging down' mechanic in A26 should help, potentially significantly.

It's improved the same as the infantry, but cavalry doesn't take more 'space' than infantry despite the larger mesh size. That remains future work for now.