Talk:LiteRumble
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Hickup in rankings | 14 | 06:49, 22 February 2023 |
Some scores in TwinDuel have shifted a lot | 4 | 04:49, 19 June 2021 |
Allowed Robocode versions notification | 5 | 12:17, 29 April 2020 |
First page |
Previous page |
Next page |
Last page |
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.
It looks like the problem is more serious this time.
Have a look at this bot, a lot of pairings are last battled in 2020, and a lot of pairings have only 1 battle, meaning that some data isn’t recovered. http://literumble.appspot.com/BotDetails?game=roborumble&name=nz.jdc.nano.NeophytePattern%201.1&order=-Battles
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.
I'm noticing that some of LunarTwins' scores in TwinDuel have shifted dramatically from what they were as of RumbleArchives:TwinDuelRumble_20200126, despite the robots involved in said pairings not having been updated since. Particularly versus the following four:
- bvh.two.Valkiries 0.44tmk3b
- bvh.two.Ravens 0.2
- gh.twin.GrauwuarG 0.41
- krillr.mini.JointStrikeForce 2.0c
which are four bots that have been unchanged since 20200126, that LunarTwins used to win decisively against, but appears to no longer do so in the TwinDuel LiteRumble. Also appears those for some reason appear to have had their pairing count versus LunarTwins reset more recently than some others for some unknown reason? Not sure. I'll be looking into it more some time, but it makes me wonder if this was due a change in robocode version.
To update, it seems robocode version 1.9.3.8 through 1.9.4.1 had entirely broken getTeammates/isTeammate, which breaks various TeamRumble/LiteRumble bots, including but surely not limited to LunarTwins.
This bug appears to have been introduced to 1.9.3.8 as a side effect of the fix to this bug.
Version 1.9.4.2 fixes a bug with getTeammates/isTeammate.
So Skilgannon if you're reading this, we should probably update the literumble version to 1.9.4.2, and also clear all TeamRumble/TwinDuel pairing data that was from a client with one of the flawed versions. Given things appear to have went from 1.9.3.5 to 1.9.3.9 in LiteRumble, it looks like it's just the 1.9.3.9 results that need to be cleared from TeamRumble/TwinDuel pairing data. :)
Rumble is updated to only accept 1.9.4.2. I will wipe the Team / TwinDuel, unfortunately they aren't stored by upload version.
So, while updating to 1.9.4.2 fixed a badly broken TeamBot situation, it introduced a new problem that I first noticed with Tron. The precise cause is unclear to me at present and can't debug into a closed bot that isn't giving a stack trace, but some change between Robocode 1.9.4.1 and Robocode 1.9.4.2 appears to have broken bots that load data files that come preloaded in their JAR files. In the case of Tron this is used for a configuration properties file, and being unable to load this is causing Tron to start in challenge/reference mode instead of normal mode.
I'm doubtful this bug only affects Tron, and removing tainted data from the rumble could be troublesome.
Bug report: here
Hi Skilgannon,
Would you mind bumping this thread when you are changing the Allowed Robocode versions?
I run my clients pretty much unattended, so they try to upload rankings and fail. Unfortunately, there is no way to notify a human unless one stares at the console all the time.
But updates in the wiki thread would propagate to my rss reader quite quickly.
Happy New Year and thank for running the LiteRumble.
No problem. I actually only changed it about 2 hours ago, if you didn't notice I would have posted something =) I'm also going to add back those historical bots which were removed because of the compatibility issues. Have a good New Year!
As promised (in 2015), bump, I've upgraded to 1.9.3.5 =)
Hi all, Literumble has moved up to 1.9.3.9 (from 1.9.3.5)
Ah, I forgot about this thread. Yes, I updated the required version so that it will use the HTTPS links instead of HTTP, now that the robowiki supports these.
First page |
Previous page |
Next page |
Last page |