Leaderboard

This is an oversimplification of the situation. As ffm correctly points out, the full hashing is a feature that cannot be removed lightly. We are working actively on the issue, as you can see from the linked technical discussions. What we will not do is hurriedly release a new version. We are carefully fixing a few bugs the right way which will take time. Thanks to our new git workflow, we are able to prepare a 0.27.1 release in an orderly way, something that wasn't possible in the past. It will also take some time to get the process right, as it will be our first patch release. The future release 28 is in active development and should be out in Q4 of 2025. I cannot give you an estimate for 27.1, but it will be as fast as humanly possible on our 100% volunteer free time. If A27 is not playable for some people, then it means it was even worse for them in A26. Indeed, full hashes were performed in A26 as well. The numerous performance improvements we released are just making that bottleneck prominent. It is alarmist and totally incorrect to insinuate that A27 would have higher spec requirements than A26.

As most people are aware, A27 has some technical bugs: extreme stuttering and OOS on rejoin. The extreme stutter makes many players drop down to 3fps or even freeze and crash the game completely. We have determined that it is caused by full hash. Wraitii has a fixed version with quick hash that solves this problem. I and @real_tabasco_sauce have tested it out and large battles with 4 players were able to run smoothly. My question is, can we do a quick re-release like we had in A25-b or just call a new version A27.5 / A28, where we at least fix the hashing stutter. If this is too much to ask, all we need to do is compile this: https://gitea.wildfiregames.com/wraitii/0ad/src/branch/quick_hash_only/ into .exe or appimages then distribute it to the player base so that people who aren't capable of building the solution can also play. Of course it might not be compatible with the rest of A27 players but if everyone could update easily, then it won't be a problem. The solution can be popularised by advertising on the forum and the lobby heading message. We can do a release candidate every time a bug is fixed, just to get games going. This current version is almost unplayable for many medium spec users and a few players I know have quit because of the stutter issue.

Can you describe your problem in more detail? Do you drop down to 4fps irregularly, like every 4 seconds, or is it just a constant laggy experience? How quickly in a typical game do you get down to 4fps? And what fps would an equivalent game in a26 have? What steps to fix it have you tried, like switching to different graphics settings in options -> graphics (advanced). Have you tried combinations of Vulkan/openGL and with vs without GPU skinning? It could be that you are experiencing a separate issue.

https://gitea.wildfiregames.com/0ad/0ad/issues/7599#issuecomment-112460 Design discussion branched from here^ Some of my thoughts on the subject: Things I think will help overall: #7608 looks interesting. I'm thinking there could be another status bar below the capture bar for "Assimilation." There could be a "warm up" time called Assimilation where it takes a certain number of minutes for the usage of that captured building to become available. You've captured it, it's been denied to the enemy, and you've claimed its territory, but now you gotta wait a little while before you can actually use it. And similar to #7608, you can't delete it either unless you've Assimilated it. All of this wouldn't require any input from the player, so it's decently simple. As suggested by @real_tabasco_sauce Adding some toggle or option to choose default behavior for your units: Capture or Attack. If it's an in-game toggle, we could call it a "Policy," or else it can just be an Options menu item. I think in-game toggle is sexier, but Options menu item might be simpler (?). If an in-game toggle, you wouldn't have to swap in and out of the Options menu if you wanted to change the policy mid-game. I think (un-garrisoned) buildings should take longer to capture in general, and buildings easier to destroy with melee weapons. Maybe revisit the base capture points of different building types and the health/HP or armor values of various buildings. Just rebalance capturing vs. attacking. I don't think a fully-garrisoned building should be impossible to capture. We could revisit the GarrisonRegenRate values to prevent this. Higher base capture points, but lower GarrisonRegenRates seem desirable to me. My ideal game is still Attack by default, but if some solutions were implemented to make capturing better and attacking more viable, then I could live with Capture by default, especially if there was a toggle. If we make buildings more vulnerable to non-siege units, then we can compensate with a building health tech tree at the Civic Center: Craftsmen (common) -> Architects (common) -> Monumental Architecture (for "urban" civs). And if we make buildings less vulnerable to capturing (increased base capture points), we can add a couple capture techs to compensate: Military Cult (common; at the Temple) -> Plunderers (for "barbarian" civs; at the Temple), Siege Ladders (common; at the Fortress).

I had just little time and patience to test it but here is my observation (need more time to evolve game in late stage) i just keep few minutes.. 8xAI hosted (no lobby) it seems more stable and less "shuttering" 7xAI 1xme (no mods single mod enabled!) I feel presence of shuttering every 4-10 secs

Great, that means you are one of the few that can bisect the issue, let us know which commit changed your experience for the worse. You should be able by letting ai players play against each other in a LAN game (no need for team games) to reproduce the issue if it's related to state hashing, which is likely if you see a short simulation stall every 4s only but have high fps otherwise. Any other symptoms must have a different reason than what this thread is about.

If I recall correctly, we ran a 2v2 large-army combat test two or three days ago with you and @real_tabasco_sauce . During that test, I used two computers: a high-spec PC and a mid-range laptop. Despite having all graphics settings on low, the laptop still struggled, running at just 3 FPS for most of the large battles. Some improvements have been observed, such as the absence of stuttering and state hash check spikes when panning the camera. While these changes may indicate a performance boost overall, I would be cautious about promoting them as a definitive "performance improvement," as players might find the gains imperceptible, leading to potential frustration. To ensure a more accurate assessment, it would be beneficial to involve more players in the testing environment, allowing us to conduct full 4v4 matches under "typical multiplayer conditions".

One by one would at least maximise its chance of getting merged. A mega patch will certainly not.

This is a performance improvement by removing a feature. Before one removes a feature one should consider what this feature is there for in the first place. The feature is there to detect OOS. OOS still occure even in vanilla but also when broken mods are used. This shows the necessity of this feature. Without this feature https://gitea.wildfiregames.com/0ad/0ad/issues/7634 would not have been caught.

My intention is to be able to get a more or less accurate idea of the players' preferences by giving them the possibility of choosing multiple options instead of holding a vote in which only one option can be chosen, which would force each user to exclude some of their preferences from their vote. As an example: So far, there is a clear preference for the addition of Building Hotkeys over Players' Stats Overlay, with a difference of approximately 18% percentage points (17 votes/22voters = 77% vs 13 votes/22voters = 59%. ). Of course, here we have to take into account the different preferences between single player users and multiplayer users. We could infer that a single player user does not have much interest in seeing the economic information of his allies as a multiplayer player does. Same for hosts features which has even more difference (23% over hotkeys). And this "could confirm" that right now most voters are single player users. Evidently, this seems to be the case. However, taking into account what I expressed in the previous paragraph, we should consider which of these features are more suitable for the two game modes (single/multiplayer). Taking Active Pause as an example, it doesn't seem right that a player can execute commands while the game is paused in a multiplayer game, and in this regard I would put more emphasis on how to modify the pause system in multiplayer in such a way as to mitigate pause abuse, something we know can be quite irritating. Finally, I would like to add that beyond the "democratic spirit" of any vote, it is difficult to take the results as an absolute and definitive truth. Rather, I believe they serve as valuable feedback for those who, with effort and dedication, develop 0 A.D. and make the decisions they consider most appropriate (and feasible) to continue improving this great game, incorporating Autociv features that have contributed a lot. It could also be a nice tribute. =)

Updates for A27: To enlarge training icons: larger-icons.zip Ranged Overlay without OOS: rangedoverlay.zip Previously, the ranged overlay mod caused OOS with community mod, because the stats of units are different. Now, community mod no longer exists so your templates will not be touched by other mods and hence no OOS issue.

In my opinion, packing effects into the Phase up techs is super uninteresting. It's not like 0 A.D.'s tech tree is massive.

It's not. It's actually within the game licenses that anybody can mod the game. You can make a circular reasoning with the tos stating that cheating isn't allowed in ranked games. Actually the Terms of Use are very clear that everything which grants unfair advantages isn't allowed in multiplayer games, no matter if they are rated or not:

Bullshit asymmetry principle (Brandolini's Law) is again what @BreakfastBurrito_007 and alike use when the argument goes on. So I'll make this last reply and then let them post whatever. @seeh made a feature in autocivP to display mod usage. You have also statements on this very thread that I'm all for features that would display mod usage. It's not. It's actually within the game licenses that anybody can mod the game. You can make a circular reasoning with the tos stating that cheating isn't allowed in ranked games. But you can absolutely use mods in ranked, compatible or not (you can make a ranked game with ponies ascendant mod afaik). As long as all parties are in the know there aren't any problems. That would be true for any game modification. You don't do it for autociv. Some very old players like Dundean consider it as cheat. So why don't you? You shadowy cheater! (It was even the first mod to introduce auto production lol ) lol. I'm done with this thread.

I know a27 just came out, and everyone likes it But I have been working on a mod (started on a26) that I would love for people to try out and play! Im not trying to seperate the community at all. I'm just trying to learn more about modding and dabble around in it. However, since Petra isn't that strong (and that is way above my pay grade) it would be nice to have people to play with and give suggestions so I can continue to develop my skills The purpose behind the mod was to try and create a little more historical accuracy and difference between the civs. It's been a lot of fun and I've been learning a lot and reading a little! I've had help from @TheCJ @Atrik@Meister@Friedrich123@real_tabasco_sauce and I'm sure others my old brain is leaving out. But yeah its really been more of a community project once it got going a little. Currently I would have to send a zip file... eventually maybe mod.io if I get lucky! Thanks! LeifTheLucky

Shouldn't we wait to do the necessary testing on other implications of removing this feature before we go public and start having players running different versions of the game? It seems a bit hasty. Or maybe I'm missing something?

Originally they did: if (turn % 20 == 0) return true; Which means 1 full has per 20 turns. We can do maybe turn % 300 == 0 which means 1 full hash check per minute. return true = do full hash return false = don't do full hash For everyone else who want to do this or play with us: The OOS is false alarm. The error is thrown because everyone else is doing a full hash at 20 turns, but we did not respond to their check request. The error does not affect gameplay and can be royally ignored. Just play on and the simulation will be in sync because it is deterministic in nature and player commands are synced over network. I personally have noticed significant improvements, especially in early game and in large fights. However, it doesn't solve everything because other parts of simulation are still poorly optimised.

As someone who uses ProGUI Trainer from time to time, but not in 1v1s and also not when im asked to, i can definitely tell it gives me an advantage, it makes me a better player. It makes my boom 30s faster on average, but really helps me in micro-intensive situations where normally i would just forget to queue units. My number 1 issue about playing 0ad is the sole impact of the "boom" on the gameplay. If you are a 20% faster boomer, probably every strategy you choose will work (at somehow equal microing skills). For me an RTS should have less focus on queueing the right amount of troops but managing your economy and strategic warfare. Then again i am unsure about my own use of ProGUI, sometimes it feels like I'm not really playing the game, and i agree with @BreakfastBurrito_007: "They're not playing the same game"... I got used to using it so much that when i play without the trainer i always forget to click troops, so I feel almost forced to use it to fulfil my own expectations. Yesterday i decided to not use it anymore (cuz i got beaten by @chrstgtr). Yet i consider the GUI (now called ModernGUI) to be the best one available right now, with helpers like idle barrack display.

It seems you already have an account with contributor access there https://replay-pallas.wildfiregames.ovh/LobbyUserDetails/8 So all you have to do is zip up some replays (not too many at once) and upload them here: https://replay-pallas.wildfiregames.ovh/Replays/Upload

yeah, true. This is also making a difference. But maybe not that much of an impact as the autotrainer.

balanced does not mean fair. If I play a 1v1 against a better player, its fair but imbalanced. If I use progui to "balance" the game, then its balanced but unfair. Progui also offers strong enough advantages for particular playstyles that it actually alters the unit/strategy/civ balance. @strat0spheric do u know about autostart? thats also in progui, the units path to the nearest resource automatically teleporting thru the cc when necessary. Join a host with me later today and I can show you live.

Which also underscores the need for better viability. No one wants to be falsely accused either

I can claim 0.26 fast smooth and fast.. while 0.27 I have 4 fps issue for sure.. I guess you assurance that A26 had problem is not correct from player perspective.

If everybody in a match explicitly agrees to the usage of cheats, I wouldn't consider using them an unfair advantage. From my perspective that'd be fine and similar to a game where the "cheats" setting is enabled. However, I believe that's a pretty rare scenario and not what this thread is about.

Ah, sorry Atrik, I was purposefully exaggerating, trying to make a point. proGUI is way too weak to be used in a proper "hack vs hack". I consider proGUI a "non-harmful-cheat", much like autocivs building hotkeys or that panel with your teams resources on display (I think its also from autociv?).

hi Atrik, wdym with creating SmurfS? I hosted many games and i am not aware of the mods players use. I don't even know how i could be. This is beyond my technical skills. I am sorry. I dunno how everything i said is interpreted as a lie, Atrik. What exactly do you think i lied about ? I think there is no need to get personal.

@strat0spheric you are the one creating smurfS to hide, and bs again attributing to mod user "hide" the mod because it fit very well with the narrative that it's shadowy. Hosts are aware when someone join and use the mod. @BreakfastBurrito_007 is mad because his drama has often little effect, and he wish more people would make as much drama as he does. Some host like @chrstgtr and @roscany enforce rule "no auto-trainer". This topic has a tone of attention, you can check the views of this one, it's through the roof even if it's uninteresting and have been discussed 10+ times before. Basically every thing you say is a lie. Possibly, you think that you are in the right, just like @BreakfastBurrito_007 for "the game's integrity and dignity" but you are clearly flat out lying and hiding.

The host should be able to allow/disallow mods. This ticket was created in that direction https://gitea.wildfiregames.com/0ad/0ad/issues/7166 . Another reason to have this control as host is that during testing the rc's some members did not want to play without their mods and can't be reached by arguments. During the game OOS's occurred and everyone was blaming the mods. It should also be easier to share OOS logs by automating ziping a dated file from .config/logs/mainlog.html, oos_dump.txt and the replay file. It's a bit tedious to convince the players to go find the files and share them.

What would you do to achieve the current shift-click behavior? just deprecate it? No es bueno, senor.

Checkboxes next to the objectives of the scenario, etc.

The developers of the game.

Warring states China would be nice too.

If someone were to make some mods isolating some of the features (and people can enable whichever features they'd like to see via mods), that would be super cool. Doing so might also create a basis for some pull requests down the line.

I really wish we had visible upgrades

Typing banani should ban nani.

I know, i was just sharing.delete_projectiles.zip

A couple of days ago I got an update to the game and the problems disappeared. As far as I understand, the developers fixed the problem. Many thanks to the developers and thanks for the wonderful game.

I answered his other post.

Atrik's version is wonderful! I found a tiny bug when hitting enter in the host game dialog (instead of clicking on the "continue" button). I did my best to find a solution, and here's my fix: Edit autociv/gui/gamesetup_mp/gamesetup_mp~autociv.js and change line 19 from: input.onPress = () => confirmSetup() to: input.onPress = () => confirmSetup(attribs.loadSavedGame)

I think @nani autociv should be in vanilla. why should it be a separate project, @seeh's version of autociv has a lot of features too. if we could add them to vanilla it would be great, plus 0AD should allow double press of a key as a single hotkey( not sure if I said it correctly) for example in age of empires we can build houses using hotkey Q+Q, that could makes things easy. AOE hotkeys seems practical.

Like Atrik, who overestimates how many players know that he's using proGUI, I believe you overestimate how many players have a problem with it. Most 0ad players I know aren't that competitive, we just want to have some fun and play some games. And even if Atrik would be a little "overrated" since he's using proGUI, when the host knows how well he plays (with it), the game will still be balanced. If someone always uses proGUI, his skill will be estimated accordingly, so it will not affect balance. That's not an opinion, that's a fact. Only when somebody suddenly starts using proGUI, he will be underestimated (as he "suddenly got stronger"), until the other players learn how good he plays with the mod. Thus, I believe most players really do not care that much, even if you might disagree.