wraitii

Mh, it's working for me. Are you sure you restarted the game with the new version of the mod installed?

I released 0.26.2 hoping to fix a bug quickly (though it seems I might've messed it up) but the idea is to release a bit less often that that. Thankfully, it's fairly easy to know if you haven't got the latest version from the lobby. I've created the merge request for siege: https://gitlab.com/0ad/0ad-community-mod-a26/-/merge_requests/9

It's done now, if you Have 0.26.2 it should work out.

Sorry, the fix isn't yet in the community mod. I'll post an update soon to fix it.

We have some merge requests: Nerf heroes Iphicrates and Ptolemy Move tier 2 blacksmith technologies to Town Phase Rebalance healers by making them cheaper I would like some more opinion before potentially merging these, though they all seem like good examples of things we could do in the mod. Edit: Also, just as a reminder, anything that is merged can also be removed, the idea is to try some things out as well.

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.