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.

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.

While reading the endless "ProGui" promoters and detractors posts in this forum, an idea came back to my mind. I think ProGui gives an advantage to low level and mid level players by assisting their boom (requiring less attention for the training, and leaving more attention available for other tasks). While you could think of it like a negative (which in many cases is), it has a "good" aspect, which is that lower level players can now participate in higher level games, something that is especially welcomed now that 0AD has lost so many old players. This reminded me of a feature AOE2 has, which is the possibility of adjusting the "handicap" of each player. This adjustment is basically a multiplier on resources collected for that individual player. For example, if you give a player a 20% handicap, he will get 20 more resources for every 100 resources collected. If I am not mistaken, this is the exact same mechanism PetraBot difficulty levels are implemented. Vinme was complaining that he had no players of his level to play 1v1s against. And many of us can often either not fill a TG, or find suitable 1v1 opponents. I think, if added to 0AD, this handicap adjustment (per player) might make balances possible when currently they are not. They would promote lower level players joining higher level games (and the opposite can also happen). They would allow more 1v1s and team games to be played, and reduce the waiting time before games can be started. Graphically, I think the handicap percentage should be shown in the row of each player in the pre-game screen. 0% handicap should be the default, and the host should be able to change it. Before starting, everybody should be able to see this percentage next to each player name, as we can see the team number and civilization chosen currently. Maybe someone can tell here if this could be developed as a mod first to test it, or it has to be hardcoded into the game engine right away, to be able to work. What you think about this idea?

real_tabasco_sause, I tried this command on the console. It fails on single player mode, so I had to open 2 instances of 0AD, one as host and one as client. As soon as I entered the command on the host machine I got an OOS. And when I tried this command on the client it failed telling me only hosts can enter this command. So apparently both host and client should be patched via mod before the game starts.

Can this command be entered during a 4v4 replay? It would be an interesting test to make for sure. But, while testing turn length on a single computer might be interesting, I want to test it on actual multiplayer games from the lobby. Testing it just on my own CPU does not give us the whole picture probably.

Regarding these charts: Can someone explain what the x-axis stands for in both left and right charts? The screenshot seems to be cropped just where it is written. I can't understand the meaning of these charts without it. If someone can explain it would be great. If the turn rate can be changed in JS, then maybe @Atrik idea of doing a quick mod to test it could be worth. The only question would be if there is a way that the host can communicate the selected turn rate every time a new game starts. Else the mod would have a hard coded turn rate, which would not allow us to test different values on different games.

Just to summarize, after reading the previous discussion, I would be in favor of: Allow the host to change the turn rate (maybe a settings option). Make the game report the real speed the game is running at (as a moving average for example). Make the game indentify the player responsible for slowing down the game to its current speed. Just with those tools we could study the problem of setting an optimal turn rate in real games played in the lobby instead of speculating. I suspect the optimal turn rate will not be a single number set in stone for every type of game. There are plenty of smart players and hosts that can give feedback about how turn rate impacts games after a while of testing. I would not disregard that help from the community.

Regarding the new Vulcan improvement on performance, we are all eagerly awaiting for it, hope the new alpha sees the light soon. But I think this proposal does not get invalidated by this. I am sure we all can agree that 0AD will never run fast enough in the foreseeable future. We are already orders of magnitude away from optimal performance in TGs, especially in big battles where a single turn can freeze up to 10 seconds, when it should take 200 miliseconds. That's 50 times slower. And if, by some miracle, surplus performance was available, we can always find new ways to make use of it, for example: We could revert the collision sizes to previous normal values to make units behave in more realistic ways instead of lumping together like they do now. We could play larger TGs, like 5v5, 6v6, etc. So a simple tweak that could potentially increase performance by 2x or more should not be ignored in my opinion.

Thanks real_tabasco_sauce for pointing to the reasons for the change back to 200ms. On the one hand it would be nice to see real data about the effect on performance by the change in turn rate. I haven't seen the benchmarks Feldfeld mentions. If someone can point to them that would be nice. My own experience says it was bad for large TGs in general. On the other hand what could be a better benchmark than to allow the community itself to change and test this in real TGs. To make it possible, the host should be able to tweak the turn rate (maybe a settings option). Also the game should report the real speed the game is running at (as a moving average for example). Lastly the player responsible for slowing down the game should also be identified. This way, several games that include this "slow cpu player" could be ran and conclusions drawn after a few days or weeks of testing. Doing testing over time on real TGs is way more solid that a few "laboratory tests" we could come up with. Also way more brains could be involved in observing the advantages and disadvantages of higher or lower turn rate values. Remember that performance issues can happen for different reasons, as unit placement and terrain will be different on each game. It's not a one-dimensional problem. For example, currently we know that if cronelius is playing a 4v4 TG, and the game makes it to late game, the actual lobby time will be between 2 and 2.5 times higher than the actual game time. In other words, the game will run between 0.4 and 0.5 the normal speed. That's more or less a rule. If we could already experiment with the turn rate, it would be possible to find out almost overnight which setting makes more sense in these type of games. On the other hand, In 1v1s it might make more sense to use a different setting.

If you open any replay file (command.txt) you will find that the duration of each turn is stated on each line a new turn starts, like "turn 0 200". The 200 stands for 200 ms. In a23 you would see "turn 0 500". The example below comes from a multiplayer 4v4 tg on this alpha: turn 0 200 end hash b6f05acff08e123cde8c1c43ec19627c turn 1 200 end hash-quick 2c00bb0c9b7ad23bd7f74ea4a261fa82