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.

Thanks tabasco, Maybe you could suggest in the posted issue to decouple the player rating from the identification of players in games. This might help devs to narrow down the issue and facilitate fixing it. The involvement of the ratings bot in the rejoin process is currently the issue, as it often happens that the ratings bot is not working for several minutes after a rejoin to the lobby. Also to be super precise in the steps to reproduce, you could also have problems rejoining if you join the lobby, dont get a rating, and start a new game. When reconncting after disconnection, if you get a rating inmeditely, you will join as spec as well.

Atrik, I am happy to hear it can solve this problem. Can you please explain how to use it to solve the game rejoin bug? You just install the mod and create a custom rating equal to your actual rating before rejoining the game? Hope to learn how to solve this problem using this mod. On the other hand, as most players are not interested in having custom cosmetic ratings, few players will have this mod already installed when they disconnect, and most will probably not be willing to search for mods in the forum in the middle of a game just after disconnecting in order to rejoin. So, while this solution might be a band-aid for now, we need this problem fixed once and for all, as it surely is a simple thing to fix. Relying on the the ratings bot to work in order to rejoin games is like relying on your football team to win this weekend, in order for you to go to work next week. Those are two totally unrelated things. Is nice if your team wins, but it has nothing to do with your capacity to work. Creating a depency among both things does not make sense, and is preventing many many games from being played until the end.

We need this rejoining game bug fixed ASAP. Especially because the fix should be ultra simple to implement. It has ruined countless games and it will continue to do so. The devs should simply identify rejoining players by name only ignoring rank. Including rank into the indentification of players in a game makes no sense, as there cannot be two players with the same name in the lobby. In case of TGs, too often it ruins the TG for all 8 players, making them all waste the played time so far. But it gets even worse: as there is a small chance you can fix the rejoining issue by insisting for several minutes, most players try rejoining non-stop until they can join or the game is restarted. So we can easily add an average of 5 to 15 minutes of wasted time for all players every time this bug happens, on top of the time lost on aborted games. The longer the game has been going on, the longer most players are willing to wait for the missing player to try to join back, before closing the game. Devs, plz look into this problem, as it is a serious quality of life bug affecting games, and surely very easily fixed. The effort-reward ratio must be very high on this one.

Stan, two ideas come to my mind: I guess somewhere in the game there must be a function for recording and sending the data produced a player every turn. Just dont record a command if another exact same already exists on this turn. Its not about undoing commands as you suggest, but saving just one of each type of command each turn. This repetition pattern of a keypress being held, reminds me of the typical repetition of a normal text editor if you press and hold any key: for example the "u" key you get this: uuuuuuuuuuuuuuuuuuuuuuuuu. In most operating systems control panels this feature is adjusted by two sliders: "repeat delay", and "repeat speed". Clearly 0AD does not obbey the operating system "repeat speed", but maybe there is a way to lower it down in the 0AD code itself, so that the repetition of a pressed key does not happen on every frame.

On another topic, if we want to analyze players APM (actions per minute) or APS (actions per second) to detect abnormal cheaty/automatic behavior, it will be necesary that the replay file (commands.txt) not only saves the turn number as it does now, but also the clock time elapsed (for example in miliseconds) on each turn. Due to game pauses and game lag we have absolutely no way to know how long each turn took in real clock time, so any APM analysis on replays will be flawed, no matter how sophisticated the analysis tool is. I would advocate for adding this extra piece of information to every turn on the commands.txt file in the next alpha. If we limit it to miliseconds elapsed since the game started, the number would not be too huge and would not bloat the replays too much. On another thread someone posted a stockfish game where he had a spike of about 20 unique attack commands in one turn. We can only wonder how long that turn took in real clock time, as that information is lost forever. A turn can take more or less clock time depending on different factors, like: cpu lag, network lag, and even pauses (autociv allows to issue commands even when the game is pauses). This is just an example of how if elapsed time per turn was recorded in the replay, discussions about automation could be way more grounded. Another benefit of this, would be that the devs could actually use Replay Pallàs to detect which games have bigger lag spikes and when in the game these spikes happen, in order to use these replays for optimizing 0AD further, instead of relying on abstract tests.

Nice experiment. I think you can get higher spikes in team games when the game lag is at its highest, and also if you PC is quite fast. You will tend to keep the "U" key pressed down for longer because of the lag util all your troops teleported , and your fast PC will have a lot of frames to capture a lot of useless repeated commands during that time.

Another benefit of fixing this issue in 0AD (besides making replay files smaller and use less network bandwidth) would be that analizing replays for APM spikes in search of cheat behavior would not be cluttered by noise caused by 0AD malfunction, and would be actually more useful.

Congratulations for the replay sharing platform. Regarding the @guerringuerrin spike of 80 ungarrison commands in one turn, that's a bug in 0AD, and should be fixed. During the sniping autoclick trend of last year, some players analized spikes in 'command.txt' files like the one mentioned above, looking for click amplification during sniping on some games, and by chance they found this problem existed. The situation is caused when, during lag spikes in games, the user keeps the ungarrison key pressed for several seconds. 0AD seems to record the key press every frame, so the amount of commands start to accumulate super fast, even if you keep the key pressed for only a few seconds. Of course it makes zero sense to record and send so many commands over the network, when just one command per turn is enough. Keeping the ungarrison key pressed for several seconds is useful when you want to teleport a lot of troops, say through a castle: 1. You set the garrison point of the castle the way you want. 2. You order your army to go into the castle 3. You keep the ungarison key pressed for several seconds until all troops teleported. If you make repeated key-presses instead of holding the key down it will likely not produce this spike. As this behavior is useful in normal gameplay, and players will continue to use it, it would be ideal if 0AD would not spam the replay file and the network with such useless identical commands on one turn.

Some AOE2 players talked about estimating how many ELO points the handicap tended to "give" to players. I might have heard that +5% handicap increased your ELO rating by 100. Of course this is a simplification, because it will not increase the game knoweldge and the micro of said player, but some useful estimations were made, in order to better balance games. So, under this loose logic, if you wanna play with your friend that is 300 elo points below you, you can give him a 15% handicap and enjoy the game better.