Acero

Devs (with the help of players like guerrin and seleucids) seem to be developing and testing patches that are promising in terms of getting back some performance (full hashes, dead bodies). But let's not forget the elephant in the room: why did performance get worse for so many in this alpha? Correcting inefficiencies present in A26 as well will not explain what happened in this alpha.

I understand this. Will 0ad do full hashes in replays too for example? Are you triggering all and each of the CPU intensive functions used during a team game when running a replay? That's why I asked you if i was missing something. And regarding the word "lag" it is not only related to networking. There can be all kinds of lag. For example input lag with a mouse/keyboard, display lag with slow refresh screens, network lag, but in our case also lag caused the CPU not able to keep up with the speed of the game. For a player who owns a fast CPU the lag that a slow CPU player will induce into a TG will feel exactly the same as if there was a comparable network lag. Correct me if i am wrong on that.

Itms, as players we now only have one very crude but objective number at our disposal to measure performance degradation, which is comparing 'elapsed game time' vs 'elapsed lobby time'. When you see that a 25 min game has been running for 50 mins in the lobby (assuming no pauses) then you know this game is running horribly slow. You can convert this ratio to a speed factor, like 0.5x. As most games get slower as the game progresses, this game is actually running probably at 0.3x in late game. This is why i have proposed in the past a few features you could add in order to measure performance improvement/degradation objectively between alphas, between types of maps, etc. Here are two ideas i already proposed: Next to each turn in the replay file, write a miliseconds elapsed timestamp. This way you can know how long each turn took in real time. Maybe also record pause and unpause events in order to remove the pauses from the time keeping. With this simple change, combined with a site like replay palace, you could have an objective historical record of how performance in real tg games has been evolving. During team games we have warning in the top-right of the screen that shows players that are having a slow network connection. But we dont have the same for players who have unsually slow CPUs, and lag the game this way. Make every client send to the host the average FPS over the last second in order to warn other players of clients with slow CPUs. This way we can isolate who is causing the most lag in network games and keep investigating from there. I can think of many more ideas like these, but you get the point. I you dont want to rely on "vague feelings" from players you can help fix this by providing some simple tools to capture basic performance data like the onces i mention. wraitii, by just profiling replays you are omitting the whole multiplayer aspect of lag. Am i missing something?

I think this kind of comments from a leading developer is the reason why a bunch of old school players have the feeling that 0ad devs, which are almost never seen in the lobby, live a bit disconnected from reality and disregard players opinions. Here Itms says in a dismissive tone and with categorial certainty that a27 MUST be more preformant than a26 given all the performance improvements released on the latest alpha. Guess what Itms: For a lot of players a27 performs WAY worse than a26. And devs have been degrading 0ad perceived performance over the years even as computers have been getting more powerful. You should be asking yourself why, instead of denying reality. While a handful of players reported an increase in performance, and some did not notice a change, i would say half or more feel the performance of 27 is worse in 4v4 games. Even veteran players and hosts like Said have expressed they lost a lot of motivation to play 4v4s anymore due to the extreme lag we experience in a27. Chrsgtr went out to say that he thinks this alpha is the one that will kill 0ad due to the lag. Related question: Is there any way i can install alpha23 on linux without recompiling? Any appimage or other source is available. I would love to do some tests, because i am pretty confident I will make some very interesting discoveries of how performance has evolved over the last 5 alphas. Alpha 23 was the last alpha that had 2 turns per second among other things, and the last alpha i remember ran decently well on rather older CPUs. I would appreciate if someone could point me to official executables for linux for alpha 23. I will prob not download a compilation from a random player tho probably, for security reasons. If the official executables are not available, i would also appreciate some instructions on how to compile myself. Thanks.

Hi, As 0AD has a notoriously big linux-based playerbase percentage compared to other games, its a shame that the linux distribution options after a new alpha have always felt a bit chaotic and kind of a hit or miss. If you go to https://gitea.wildfiregames.com/0ad/0ad/wiki/GettingTheUnixRelease you can see a long list of instalation options for several different linux flavors, but many of them are not available right after a new release. Moreover if you are using a linux distribution that is not the latest (but still active and not end-of-life) you might be stuck with an old version of 0AD for years until you reinstall or upgrade to a newer version of your operating system. Only at the end of that long list you can see two distributions formats that are compatible with most linux distributions (Flatpak and AppImage), but none of them are managed by wildfiregames and it is not clear if they have the latest release available just yet (the word 'rc1' is present in the appimage at least). Also sending non technical users to dive into Github to install their game is not good imo. This is problematic for current players, but even more so for new players, which will install 0AD from their repositories and find an almost empty lobby of a previous alpha with 2 or 3 players maximum. It happened to me years ago. This is terrible marketing for a game. Instead of forcing the 0AD devs to navigate the complexity of every mayor linux distribution system in order to release a new alpha of the game, why not just choose to make it available as a single AppImage file, which should downloadable as the first option here: https://play0ad.com/download/linux/ In my own experience as a perpetual noob linux user, AppImage is the format that has given me the least amount of friction to install software when the version i am looking for is not available in my distribution repostory. What can be easier than downloading a file, making it executable, and double clicking it. Its even simpler than Flatpack as it does not requires any previous package managment system. This is the marketting for AppImage: Linux apps that run anywhere. Download an application, make it executable, and run! No need to install. No system libraries or system preferences are altered. "As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application." "As an application author, I want to provide packages for Linux desktop systems, without the need to get it 'into' a distribution and without having to build for gazillions of different distributions." I think 0AD is the ideal candidate for using AppImage as: The 0AD version/alpha changes very infrequently so we don't need constant upgrades every week like firefox for example. While it is true that AppImages are bulkier than a distribution version beacuse all dependencies have to be bundled in the file, this is not a problem because the few hunderds of megabytes 0AD uses is tiny compared to the the disk usage of modern games. It is a relatively obscure program installed by relatively few people, so distributions dont care a lot about having the latest version available. After you release the official AppImage you could spend your time (if available) making sure most repositories of most distributions support your new alpha, but that should come after an official cross platform universal executable for linux has been released. If you want to reply that linux users should get used to compiling their stuff, and/or learn to navigate dependency hell, i can only say: "Think about the noobs!!!"

Sorry, did not notice that @Atrikalready posted about this exact same issue yesterday. Feel free to merge the topics.

This bug has been bothering me for a long time, and yesterday another player mentioned it, so i post it here in case it has not been reported before, or is not yet in the devs radar. When playing both cavarly and infantry sometimes you want to treat them as one single army. One of the obvious ways to arrange your troops before engaging in a battle is to put melee troops in front and ranged in the back, so that the more tanky units protect your ranged. And one of the most efficient ways to achieve this is to put your army in a formation. Compared to a manual approach to achieve this goal, using a formation reduces clicks and at the same time engages the "running" speed of your troops so that it takes considerably less time to reach their final positions. Every player above rank 1500 probably knows this and takes advantage of formations. The problem arrises when your army has ranged cavalry in the mix, as the cav is put in front of the formation every time, which in my opinion makes absolutely no sense and invalidates the usefulness of the formation in this case. The solution I use is to put cav in a different control group and micro it independently ofc, but as I said, one would expect to have a sensible formation option available with or without cavs in the mix. The fact that precisely cavalry of all ranged units is put in front is even worse than if it was ranged infantry, because the enemy will probably have spears or pikes in front of his army, which has a counter of 2.5x or 3x against cavalry! So you are sending your precious and expensive ranged cavalry directly to a silly and miserable death. Another problem is that players with less experience will probably engage the formation without understanding the implications, trusting that 0AD is doing something logical for them, and they will waste their cav while probably not even realizing why they are loosing the battles. At the very least, ranged cav should not be considered at all in such formations, but the optimal situation is to fix the formations so that all ranged units are put in the back of the melee units. And ideally the more range the unit has, the more in the back it should be placed. So skirms in front of slings in front of archers. This way units will have to move and bump into eachother the least when the battle begins. I dont know if the fix is a simple xml template change or something more complicated. In the former case, maybe a comunity mod would be all we need to fix this long lasting problem. @real_tabasco_sauce

If I understand correctly what Norse says here, the event of any new user connecting to the lobby refreshes the ratings for all players, including the ones with the bugged ratings. If this is the case, two ideas come to my mind: 1) This problem of aborted games due to the rating bug probably happens mostly for us late night american players which usually play when the lobby is at its lowest in terms of connected players. At this time of the night it is common to not see any new player connecting for minutes or even tens of minutes at a time. On the other hand, at any other time of the day this problem is probably not as important beacuse on average you see new players connecting very often. 2) A convoluted but effective method of saving games for late night american players could be the following: always have the credentials of a second account ready, and when you or another player looses ratings: (a) leave 0ad, (b) log in with the other account in order to refresh the ratings for everyone, and (c) rejoin with your original account. With this method any player should be able to fix the ratings bug for any other player, even if the player with the bug does not have a second account for this purpose.

Sometimes you dont get a rating when joining the lobby freshly. If you then start a new game and later disconnect, you wont be able to rejoin the game as a player if the ratings bot is working well, because the game will be expecting a version of you without rating, but you will be joining with rating.

This issue so dreaded that I have known players with unstable connection to not play any rated 1v1 game just so they dont have a rating associated to their accounts in order not not have problems rejoining games after disconnections.

If you want to find the cause of the ratings bot malfunction, I suggest looking into the user beging given a different xmpp id after rejoining as guerringuerrin noticed, and see how the ratings bot behaves in that case.

Even if you join the lobby without having disconnected recently you can get no ratings for a while. It is less common than loosing ratings just after disconnect, but it can happen as well. If you join a game in this state, and later disconnect, while the ratings are working as expected, you will join as spectator too.

No pattern that anybody that I know had been able to indentify.

When players drop from games, and rejoin the lobby, it`s very common that they don't see any ratings in the lobby. Not own rating nor other player's ratings. It can take several minutes for the ratings bot to be working again for this player. We have tried a number of tricks, but none of them seems to solve the issue. Some of the tricks usually tried in order to recover the ratings after disconnects are: Rejoining the lobby several times Restarting 0AD several times Rejoining the game several times Hosting a game and closing Hosting a rated game and closing None of these tricks solve the issue. The ratings just come back on a random basis without any known pattern. If the ratings bot would be trustable and work every time after rejoining, no other fix would be needed I guess. But still this dependency on ratings to rejoin a game as a player does not seem to be logical. I remember this problem existing since at least the previous alpha. Not sure if it happened before. If a player has an unstable connection, the problem becomes bigger, as even if he manages to rejoin after several minutes, on the next disconnect the problem has to be tackled again, and there is never certainty on when the ratings will come back.

If I remember correctly, guerringuerrin told me the problem with the ratings bot not giving ratings seems to be a bug related to the user getting a different xmpp ID on rejoin, which the ratings bot is not able to resolve quickly. But this problem should be totally unrelated to games being able to indentify a returning player, as ratings does not need to be part of the identification process. That's why I suggest decoupling the ratings bot from game rejoining altogether.