Hickup in rankings

The rankings for roborumble, minirumble, and nanorumble experienced a hiccup, causing the rankings to restart from zero. However, all older results were added as soon as one battle was fought. Every bot had to fight every other bot once to get the rankings up-to-date. LiteRumble was able to recover the rankings with only 2000+ battles, thanks to a fix by Xor. However, there was a bug in the rumble client that prioritized already existing bots over bots without a ranking, making it harder to add missing bots back. Xor submitted a fix for the bug. The rankings were eventually stable again, but many pairings only had one battle, sometimes from two years ago. It's unclear if the lost battles can be retrieved.

— ChatGPT

Hi all, seems that for some reason the participants list for roborumble, minirumble and nanorumble had a hickup (not for microrumble ??)

This means that the rankings start again from zero, but luckily all older results get in as soon as one battle has been fought. In order to get the rankings up-to-date again, every bot has to fight every other bot one time.

So, if you have the time and opportunity, please start your rumble client.

It seems less worse than I thought at first sight. As soon as a bot has fought a battle, it appears in the ranking.

When all bots are present, all bots have to fight one battle to get all pairings back. Hopefully LiteRumble is smart enough to get that done in one pass.

That happens once every a few years ;( Maybe LiteRumble should have some check to prevent removing more than 100 bots at a time? Anyway LiteRumble *is* smart enough to recover with only 2000+ battles (1000+ to add back, 1000+ again to fix pairings), instead of 1000000 battles.

However a bug in the rumble client actually prioritized already existing bots over bots without ranking, except in the clean run case. So it actually takes much more battles to add missing bots back ;(

I submitted a PR for this bug. https://github.com/robo-code/robocode/pull/61.

Bots without rank should always take highest priority, in all scenarios.

Bad news. Once a bot is added, the pairings are only updated for newly added battles. e.g. one bot with 400 pairings, gets to 401 when one battle is submitted. The rest of the pairings seems not to add automatically. So this means 1000000 battles are needed. ;(

I submitted a PR to literumble. https://github.com/jkflying/literumble/pull/3 Hopefully this PR will solve the issue, and with 1000+ battles, the ranking should restore stable.

Merged and deployed, thanks. Should we also update Robocode versions?

Great! Anyway I think we could wait for the next release, where the fix for unranked bots are merged ;)

Looks like the ranking isn't recovering as fast as expected, bots with 400 pairings still goes to 401 instead of 1189 after 1 battle. Any idea of this behavior after the PR?

Note that in the 507 still unstable bots of roborumble, 449 are from minirumble, 421 are from microrumble and 228 are from nanorumble. So it seems that bots that also in mini/micro/nano rumble takes longer to get to stable state.

Also note that 391 / 507 unstable bots are last updated since the deploy of the fix.

It is restoring quite fast. At this moment half of the bots in roborumble have all their pairings back. And most of the others have at least 800 pairings.

That may be caused by the batch processing. However, it should be fully recovered if it's caused by batch processing.

Rankings in roborumble, minirumble and nanorumble are stable again, microrumble was stable from the beginning. But as Xor indicated, a lot of pairings have only 1 battle. Sometimes even 1 battle from 2 years ago. Is there something we can do to retrieve the lost battles, or should we continue with the current situation.

Think again, there may not be data loss. For each pairing to have 1 battle, we need 500000 battles, which takes contiguous running of a few months. It's not surprising that it takes 2 years for a round.

Most of the 1 battle pairings are from 2022.3.23 (or 2020.10, didn't remember that though), the exact time the last hiccup happened. This strongly indicates that the data loss happens when a battle is fought for a missing pairing.