Acero

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.