Talk:RoboRumble/Participants

Why it still have "No chatting on this page. Use the /ParticipantsChat page for that."? We can have this discussion page for chat. » Nat | Talk » 05:11, 27 April 2009 (UTC)

Entering rumble via infobox

You know, it would be kinda cool if people could enter their robots in the rumble via Template:Infobox Robot. Just add the appropriate data to the box and an argument that says, effectively, "Yes, enter my bot in the rumble," and boom, it gets picked up. RobertWalker 19:10, 12 December 2007 (UTC)

Thats sorta possible, if say, we added a category to the template then had it use that category and trace the link to the bots page and look for its jar. However thats a lot of extra skipping around, and its a realy strain on server resources to have to 'check' for these things. --Chase-san 20:07, 12 December 2007 (UTC)

A couple issues with that, though not show-stopping issues: one, we have bots in the rumble with no bot pages. (Vanessa, for instance.) Two, you don't always have your latest version in the rumble, or you have to post a temporary RRGC version or something like that. With all the little caveats, the Participants page might still be the most elegant solution. --Voidious 20:13, 12 December 2007 (UTC)

Is there a reason this list isn't being used for the rumble yet? Also, is there an updated zip of the rumble bots around? (Or could someone make it? :-D? I'd like to start running battles again. -- Alcatraz 12:52, 8 December 2008 (EST)

robowiki.net is running again, but maybe is time to activate this participant list? --lestofante 13:40, 5 January 2009 (UTC)

Agree. Many down of the old wiki can make newbie like me try many new idea on rumble! --Nat 11:44, 6 January 2009 (UTC)

Anyone still interesting with this issue? This can accomplish via a bot. If we have property name rumbleLocation in infobox, and the template automatically put any robot with that parameter into some category, I can make my soon-created bot handler that, say once per hour? For special RRGC/WSGC or a bot without page, there can still use another participant list and it will be merged to another page when the bot run. » Nat | Talk » 09:35, 2 May 2009 (UTC)

Personally anyway, it seems that trying to make entry via infobox just overcomplicates things really. I'd much perfer there just be one simple way to do it: Add it to the participants page by hand. --Rednaxela 14:33, 2 May 2009 (UTC)

I agree. The only change that I'd like to see (eventually) is to have the server maintain the participants list and bot storage. But I'm not ready to commit to programming that yet. --Darkcanuck 17:25, 2 May 2009 (UTC)

I would personally like to see it done via roborumble.org (which has sorta dropped). — Chase-san 03:09, 10 August 2010 (UTC)

---

Tigger

Hey man, you don't need to remove Tigger, one of us would gladly host it. Darkcanuck has posted most rumble bots to his server already, so you can make it point here if you want: http://darkcanuck.net/rumble/robots/stefw.Tigger_0.0.23.jar. Of course it's your call, but it seems a shame to remove such an old-school bot. --Voidious 14:01, 14 May 2009 (UTC)

• I wouldn't just call it an old-school bot, but also a very interesting one that gives a fair number of surfers some trouble if I remember right.. :) --Rednaxela 14:54, 14 May 2009 (UTC)

• Because its unique and only Tile Coding? » Nat | Talk » 15:01, 14 May 2009 (UTC)

• Well, it trounces Komarious, gives PulsarMax, Lukious, Engineer, and WinterMute a rather hard time... not sure if that's because of it's unique Tile Coding things, but it might well be --Rednaxela 15:35, 14 May 2009 (UTC)

• It could be its unique stats system. Since it's a reference bot for the TC2K6, the Targeting Challenge 2K6/Results give us at least some insight into its movement. Clearly, some top bots can really zero in on Tigger, but a lot of still very strong guns have some trouble with it. And the low scores against Linear Targeting and Circular Targeting seem odd, but might mean that he always enables a flattener, or just has some anomaly or bug that has a similar effect. --Voidious 15:58, 14 May 2009 (UTC)

• Well, it's reference scores against linear/circular targeting don't look that weird to me. I mean, the only reference bots that do better against the simple targeting are either surfers or the tremendously well-tuned multi-mode known as GrubbmGrb --Rednaxela 16:51, 14 May 2009 (UTC)

• Tigger is a surfer, though. :-P And his score against HoT is respectable. --Voidious 17:17, 14 May 2009 (UTC)

Hey guys, should we re-enter Tigger? StefW's only reason given was about Geocities going down, so I say we do it. Any objections? --Voidious 02:04, 20 July 2009 (UTC)

Agree. And the Geocities isn't going down till October, I can still access my webpage right now. But we can have the Darkcanucks' one. I think we usually grab it from the zip files, btw. » Nat | Talk » 13:17, 20 July 2009 (UTC)

Re-enter it. It is a decent and quite unique bot and also away to honour StefW for his development of the initial onPaint. --GrubbmGait 22:03, 23 July 2009 (UTC)

Broken Links!

I just fixed a ton of them! Also, thanks to Darkcanuck for the http://darkcanuck.net/rumble/robots/ hosting of them. Now.. I hope we can keep them more fixed than they have been, as that was rather tedious :P --Rednaxela 00:25, 6 August 2009 (UTC)

TheBrainPi fix

I just added the fix version of TheBrainPi, I did some testing and it didn't seem to throw any exceptions. I uploaded it to my google site because roborepository would upload it as mine, and show Zyx as author and that didn't seem right, but I don't know if it is better if Darkcanuck can host it in his sever? All I changed in the code has a comment that contains the words Unofficial fix very close from which it can be easy to see the changes. --zyx 01:21, 5 September 2009 (UTC)

Very cool of you to take care of that! Check out the comparison: [1]. It's little things like this that make me appreciate what a great community we have here. --Voidious 16:28, 5 September 2009 (UTC)

Thanks just a very small retribution to Albert's immense contributions. And you are right, this is a great community, I wish I had more time to help more. --zyx 17:41, 5 September 2009 (UTC)

Ok, the fixed version is now on my server (along with all other current 1v1 and melee bots) so you can change the link if you like. Thanks for doing this! --Darkcanuck 19:51, 5 September 2009 (UTC)

Removing duplicates

Wow, there are a lot more duplicates in the participants list than I realized. Any objections to me removing all but the highest ranking version of each of these bots?

altglass.Exterminans2oo8 alpha0328,http://d-gfx.kognetwork.ch/robocode/altglass.Exterminans2oo8_alpha0328.jar
altglass.Exterminans2oo8 Build0411,http://d-gfx.kognetwork.ch/robocode/altglass.Exterminans2oo8_Build0411.jar
am.Miedzix 2.0,http://www.robocoderepository.com/BotFiles/3383/am.Miedzix_2.0.jar
am.Miedzix 3.0,http://darkcanuck.net/rumble/robots/am.Miedzix_3.0.jar
cjk.Merkava 0.1.1,http://www.robocoderepository.com/BotFiles/2637/cjk.Merkava_0.1.1.jar
cjk.Merkava 0.2.0,http://www.robocoderepository.com/BotFiles/2640/cjk.Merkava_0.2.0.jar
cjk.Merkava 0.3.0,http://darkcanuck.net/rumble/robots/cjk.Merkava_0.3.0.jar
kurios.DOSexe .9a,http://www.kuriosly.com/roborumble/kurios.DOSexe_.9a.jar
kurios.DOSexe .9b,http://www.kuriosly.com/roborumble/kurios.DOSexe_.9b.jar
pak.Dargon 1.0b,http://www.robocoderepository.com/BotFiles/3388/pak.Dargon_1.0b.jar
pak.Dargon .2c,http://www.robocoderepository.com/BotFiles/3389/pak.Dargon_.2c.jar
paulk.PaulV3 1.7,http://www.robocoderepository.com/BotFiles/3502/paulk.PaulV3_1.7.jar
paulk.PaulV3 1.6,http://www.robocoderepository.com/BotFiles/3497/paulk.PaulV3_1.6.jar
paulk.PaulV3 1.5,http://www.robocoderepository.com/BotFiles/3496/paulk.PaulV3_1.5.jar
paulk.PaulV3 1.3,http://www.robocoderepository.com/BotFiles/3495/paulk.PaulV3_1.3.jar
zyx.micro.Ant 1.1,http://www.robocoderepository.com/BotFiles/3481/zyx.micro.Ant_1.1.jar
zyx.micro.Ant 2.1,http://sites.google.com/site/zyxsite/robocode/zyx.micro.Ant_2.1.jar

Also planning to remove "whind.StrengthBee 0.6.4", as that was just a test of Strength with CassiusClay/Bee gun. And is this "rule" actually written anywhere? (I know it's kind of a "soft rule", but I still think it's a good one, in general.)

--Voidious 22:39, 9 October 2009 (UTC)

I don't think there is this rule written anywhere. But I think we should add the second rule to the RoboWiki: "Common sense is the rule" =) --Nat Pavasant 04:38, 10 October 2009 (UTC)

I agree with that, it is common sense. About micro.Ant, I didn't know there were two versions of it (in life not only in the rumble). I'm removing v2.1 but I think that maybe they only share the name, there is a good chance they have no code in common, it's been quite a while since I wrote that. --zyx

Common sense indeed. The number of participants has gone from 300 when I started to nearly 750 now, so duplicates and testbots should be removed, preferrable by the author. Authors should even consider if older bots with successors and without 'unique' setup could be removed. (Says the man with 8 1v1 and 6 meleebots.) But the latter is strictly a matter for the author and not for the community. --GrubbmGait 09:51, 10 October 2009 (UTC)

Yes that's a good idea. How about also removing bots that reguarly freeze/skip many turns/take lots of memory and/or have to be stopped by robocode? --Positive 11:05, 10 October 2009 (UTC)

Cool - I'll give this another couple days before removing any of the dups myself. zyx, that's funny =), and if they are indeed different bots, of course feel free to leave them both in. GrubbmGait, well said, I completely agree. Positive, I personally agree about bots that crash frequently (DogManSPE and SmallDevil come to mind), but IIRC, I suggested removing DogManSPE once before and met with some resistance. =) --Voidious 17:02, 10 October 2009 (UTC)

I think you may have forgotten to do this... --Darkcanuck 03:55, 13 July 2011 (UTC)

I completely agree as well, I will probably be removing a number of out dated or test robots of mine (such as prototype, sou, orbit, and problembot). Also duplicates and robots that crash often or have to be stopped by robocode, or that use problematic methods (such as the static reference of Advanced/Team robot). These should be removed, unless they can be repaired, or if some reason exists for retaining them. For example gg.Wolverine I repaired a long time ago to keep it from losing battles due to calls to getXX. But it wasn't a simple fix. — Chase-san 14:56, 24 July 2010 (UTC)

Wow, that was a long time ago. Finally removed the ones that hadn't been already. Also skimmed the participants list and didn't notice any other duplicate versions. --Voidious 01:53, 14 July 2011 (UTC)

Melee list, gg.Wolverine and wiki.Wolverine, wiki.Wolverine is a fixed version of gg.Wolverine (probably shouldn't have ever have been changed from gg now that I think about it). — Chase-san 02:10, 14 July 2011 (UTC)

Removal of crashing bots

Ugh... I was about to post here proposing the removal of DogManSPE due to the great deal of instability it has and then I read in the previous section that there was some resistance to such removal in the past. Personally... I'm finding this one to be highly irritating because it always shows up as a high score diff when comparing bot versions, and often a big enough difference to have a non-negligible impact on overall score. --Rednaxela 03:59, 13 January 2010 (UTC)

Looking on the old wiki for references to DogManSPE, the only mentions I see are countless complaints and comments about it being a high PBI bot for them (due to it happening to not crash against them), and some mention on oldwiki:RoboRumble/RankingChat20070224 which isn't really resistance to DogManSPE specifically I think, particularly considering how it doesn't look like it was entered by it's author in the first place. --Rednaxela 04:12, 13 January 2010 (UTC)

As you may have seen in those discussions, I'm also in favor of removing DogManSPE for that reason. But I've lived with it this long... =) So whatever. --Voidious 04:33, 13 January 2010 (UTC)

I have no sympathy for DogManSPE. That said, if there were enough battles then this crashing effect would be smoothed out. There are other crashing bots stuck at the bottom of the rumble, presumably abandoned by their authors (eg. ElverionBot, Dreadknoght)... --Darkcanuck 04:51, 13 January 2010 (UTC)

Update of RoboRumble Version

What I don't get is why RoboRumble uses Robocode version 1.6.1.4 (I think, it might be slightly newer). Right now we are on release 1.7.2.1 Beta. The least we could do is use 1.7.2.0... --PiRocks

Because the 1.7.2 line is still not stable enough. True, there is a lot of changes, but from 1.6.1.4 to 1.6.2, 1.6.2 to 1.7 and 1.7 to 1.7.1 has a lot of very big changes, which is inevitable for bugs to occur. There were at least three discussions of this, but I can't remember where they are. --Nat Pavasant 12:45, 24 June 2010 (UTC)

Actually, unless you know bugs that you haven't reported, 1.7.2.0 and 1.7.2.1 Beta may be stable enough (Unless PiRock's 'workaround' truly shows a security bug in the current version). I haven't had a good enough chance to fully test either, but I was very heavily testing just before 1.7.2.0 release and I'm pretty sure 1.7.2.0/1.7.2.1 will be stable enough. Just need to test it properly. --Rednaxela 13:04, 24 June 2010 (UTC)

Unfortunately, my workaround most definately shows a security error. 1.7.2.1 Beta doesn't protect the main ThreadGroup, so my robot accesses it and waits for enemy robots to be scanned. Then once scanned, it calls interrupt() on their Thread and they get destroyed due to inactivity. —Preceding unsigned comment added by PiRocks (talk • contribs)

Heh... I've created a bug report for this now. Also, removed the bot from the rumble, because 1) Generally not good to have exploit bots there and, 2) As you noted it's broken anyway in 1.6.1.4. Thanks for uncovering the issue. --Rednaxela 00:22, 25 June 2010 (UTC)

Removal of old bots.

I didn't want to be the one to suggest this. I dislike hanging myself in public. But I do think it is a good idea. There are so many now, that the rankings have many very old very poorly performing robots. We already want to remove robots which time out due to getXXXX calls, or which just don't work anymore. But consider back in 2004 or so and we only had around 350 robots in the rumble, that number has doubled and then some.

I am all for the history, but the number of old, poorly performing, buggy or just out of date robots is staggering. With almost 800 participants the number of battles needed to stabilize its ranking is rather high. All I am suggesting is a one time trim, pick a target number and carefully select the robots in which we can live with (an no one complains about) dropping. I say at the very least 400.

(I don't expect many people to like this idea, however much I do)

— Chase-san 03:22, 10 August 2010 (UTC)

Only time for one quick comment before bed, but... Reducing the number of bots would not decrease the number of battles required to get a stable ranking. Only removing the bots with the highest variance would do that. (Assuming you've faced everyone at least once.) Even if you are just facing one bot, it would take 1500-2000 battles to get a result as accurate as we want in the rumble. At least, I'm pretty sure that's the case. Hopefully some resident math wiz can back me up. =) --Voidious 04:35, 10 August 2010 (UTC)

I don't have time right this moment to comment on any other aspects, but I'll quickly comment on the impact of number of bots on rank stability. First off, you're most definitely correct asymptotically Voidious, in that number of participants wouldn't impact stability as the number of battles becomes very large. When the number of battles is not very large though, I can think of two effects which cause a deviation:

1. The obvious one, is that before pairings are complete, the accuracy/stability of the rank is reduced due a high chance of scores against many bots not being what's expected (i.e. problembts). 500 battles with 300 participants will be more stable than 500 battles with 800 participants, due to this.
2. When pairings are complete, battles are not distributed randomly, and not necessarily evenly. Because each pairing is weighted equally, each additional battle added has more impact on score stability when added to a pairing with few battles so far. What this means is, say you have Robot A, which has results against Robots X, Y, and Z. If the pairings A vs X, A vs Y, and A vs Z each have 2 battles, the resulting score is more stable than if A vs X has 1, A vs Y has 3, and A vs Z has 2.

I'm not sure if factor #2 has that big an affect really, but it's a non-zero effect. #1 is definitely a noticeably effect I'd say, though only temporary. --Rednaxela 13:16, 10 August 2010 (UTC)

As for #2, I don't really think that matters. I agree that 1/3/2 is less stable than 2/2/2, but 2/6/4 should be the same stability as 1/1/3/3/2/2, I think. So I don't think it really pertains to number of bots. --Voidious 14:53, 10 August 2010 (UTC)

Well, I imagine my opinion is pretty predictable =), but I vote not to remove old bots. Personally, I like the ridiculous diversity we have in the rumble. I like when some bot I've never heard of exposes some obscure flaw in my own bot. I like the idea of old Robocoders coming back 5 years later, checking the rumble and finding their bots still competing. And while we may have twice as many bots as 2005, our computers are 5x faster (or more) anyway.

I also don't really see the value in removing them and I just don't see a fair way to choose which bots to remove. Being old or having a low ranking doesn't seem like good criteria to me. "Buggy" is tough to gauge, and we've already removed or fixed the buggiest rumble bots (with inactive authors). If enough people are in favor, maybe we can vote. But this is not a decision to be taken lightly, so if it does come to that, I think we should give it lots of lead time (like months) to discuss and vote on it.

--Voidious 14:53, 10 August 2010 (UTC)

I honestly do agree with you in the most part. However I still feel like there are just to many. I would must rather everyone take a gauge of their robots and remove all but they want rankings for in the rumble. But considering many authors are no longer around, that isn't an entirely feasible option. — Chase-san 19:19, 10 August 2010 (UTC)

How about this, instead of choosing which robots to remove, we choose which robots to keep, which is a much less stressful and guilty endeavor. But limit it to a few dozen robots per person to add back in (nothing exact), just so no one just copies the entire list and says 'all of them'. Of course we could end up having the entire list back given enough people. — Chase-san 19:27, 10 August 2010 (UTC)

I am in support of removing any nonworking robots (the ones that time out from getXXX or any other errors) but I think that the other older robots that still function should be kept. --Exauge ◊ talk 23:08, 10 August 2010 (UTC)

I agree. I know that I would be a bit peeved if I came back to Robocode a few years later only to find that my bot and all the bots I had known had been removed because they were considered weak and old. On the other hand, if it *specifically* was slowing down the rumble due to crashing, timing out etc. then I wouldn't mind as much. --Skilgannon 19:03, 11 August 2010 (UTC)

Well to be fair, in your case, I find it rather unlikely they would be all removed. Though in this case I am only suggesting a one time trim, and if those people want they can reenter thier robots in the rumble at that time. Also might get an older robocoder to rejoin the game (which is always nice) — Chase-san 16:45, 12 August 2010 (UTC)

Instead of removing the robots from the lists, they could be moved to another page (old participants list). This way they are not completely gone, and we would have a kind of "history" of robots that previously took part in the rumble. Just a suggestion. --Fnl 20:42, 11 August 2010 (UTC)

That is a good idea. — Chase-san 16:45, 12 August 2010 (UTC)

Some bots aren't downloadable, so my rumble client is never using them in fights. It's jab's bots hosted on freewebs.com and simonton's bots hosted on frozenonline.com

• jab.avk.ManuelGallegus 0.6: [2]
• jab.DiamondStealer 5: [3]
• jab.micro.Sanguijuela 0.8: [4]
• simonton.micro.GFMicro 1.0: [5]
• simonton.micro.WeeklongObsession 3.4.1: [6]
• simonton.mini.WeeksOnEnd 1.10.4: [7]

Anyone have these bots and the ability to give them a hosting home? -Tkiesel 18:00, 14 November 2010 (UTC)

Sample bot

Personally, I vote against sample bot in RoboRumble. Even though right now ranking stabilize fast, they still add loads to server (and the server is already under very high loads). Since most sample bots don't perform well in main Rumble anyway, probably beaten by most nanobots, I see no reason for sample bots in main Rumble, unlike the melee one.

(And I don't think it is really good for RoboRumble client and server have them added and removed so fast like this.) --Nat Pavasant 10:23, 4 July 2011 (UTC)

I'd vote to keep them in. I think their importance as bots vs how much they increase rumble size is worth it. But either way is fine with me. If there's not a clear concensus, maybe we could actually have a poll... --Voidious 16:17, 4 July 2011 (UTC)

I also vote to keep them in, obviously, as I am the one who put them. Everyone knows them, and its funny to see how many megabots perform less than 100% survival against them. And there are worse bots in the rumble and nobody complains about them. --MN 00:35, 5 July 2011 (UTC)

Unfortunately there´s no "extends Robot" category in the rumble. They would be a lot more competitive in such category. --MN 00:35, 5 July 2011 (UTC)

I'd disagree with "And there are worse bots in the rumble and nobody complains about them", because there has been complaining about those others sometimes... Overall I feel neutral about the presence of the sample bots, because they do have the redeeming quality of being decent reference points for beginners. --Rednaxela 02:59, 5 July 2011 (UTC)

I still personally think we should at some point do a major trim on the number of participants, or have a Rumble2 (with only new/er participants), but I thought they were removed for the reason Nat originally posted. If you they serve as good references for beginners that is fine, I won't object. — Chase-san 09:25, 5 July 2011 (UTC)

Super Slowbot

I noticed my rumble client grind to a near halt when running gf.Centaur.Centaur against any other bot, its slower then pitting Diamond against Shadow. Anyone else getting similar behavior? — Chase-san 06:36, 17 July 2011 (UTC)

I haven't noticed whether or not Cenetaur is slow for me, but just as a note, "Diamond against Shadow" is not something I'd expect to be hugely slow anyway as far as things go, since Shadow is one of the fasted high-ranking bots last I checked. --Rednaxela 07:06, 17 July 2011 (UTC)

Diamond's not particularly slow either, at least compared to other surfers... Anti-Surfer Challenge/Pre-Chat has a good comparison of CPU speed of various surfing movements, though it might be slightly out of date (like I bet DrussGT is faster now). --Voidious 15:30, 17 July 2011 (UTC)

Yep, Centaur makes my system crawl, even against a samplebot. Battles between two topbots can take longer, not particularly because they are slowbots, but because they perform on par, stretching battles to the last drop of energy. --GrubbmGait 16:47, 17 July 2011 (UTC)

Sorry didn't mean to insult anyone with my reference. Two top surfers vs each other are usually the slowest battles. I just picked two I particularly liked. — Chase-san 17:07, 17 July 2011 (UTC)

Centaur 0.6.5 is indeed very slooooow to run. If I didn't have other things to do, I would go play with it manually and see if it's skipping a lot of turns or doing other odd things. -- Skotty 02:31, 19 July 2011 (UTC)

Rumble Pairing Selection Algorithm

Beaming raises concern over a ranking of a bot in the roborumble and the number of matches it has played with certain opponents. Xor clarifies that LiteRumble selects missing pairings first and each bot should have a similar number of battles given enough time. GrubbmGait speculates that there may have been a hiccup in the rankings last year. Xor suggests that older bots with more than 5000 battles aren't selected until everyone has had at least 5000 battles, and newer bots have a priority because they have less than 5000 battles. They also suggest that the current algorithm doesn't have any problems and that older bots will eventually get more battles in the next 100 years. Beaming thanks Xor for the explanation.

Hi, I just looked at ranking of Vodious Jen http://literumble.appspot.com/BotDetails?game=roborumble&name=voidious.micro.Jen%201.11&order=-Battles

for a bot which is in the rumble for many years, there are quite a lot of opponents with which this bot has less than 5 matches and those are bots which are also in the rumble since forever.

I wonder why match selecting algorithm avoids particular bots. Is it normal?

What do you mean by avoiding particular bots. From the code, LiteRumble selects missing pairings first, then pairings with less battles, etc.

Given enough time, each bot should have similar amount of battles.

Ups, I posted wrong link to Jen rating, see http://literumble.appspot.com/BotDetails?game=roborumble&name=voidious.micro.Jen%201.11&order=-Battles

I do use LiteRumble to check for my bot improvement (if I run clients anyway, why not update "real" rating). But the issue I report is unrelated to my bot.

OK, a thought the missing pairings is related to your bot (which just get updated), but it turns out to be an ancient one.

If you look at Jen pairing, you will see almost 200 bots, with which it has only one pairing. This is not normal for a bot which is many years in the rumble. http://literumble.appspot.com/BotDetails?game=roborumble&name=voidious.micro.Jen%201.11&order=-Battles

1. We need to find out whether they have only 1 pairings 10 years ago. If so, we could add back the missing pairings from backup.
2. From the code, "Battles" is merely a counter. If it shows 1 pairing, then there must be data loss unless it's 1 initially.

as far as I can remember, some time ago (~1 year) there was a hickup which resulted in the strange rumblerankings. Bots had disappeared from the ranking, and when they came back after a battle, their stats against others was either complete or just 1 battle. Just can't find evidence of it on the wiki

Must be this discussion Thread:Talk:LiteRumble/Hickup in rankings

The pairings are already missing in 2021, so it mustn't be resulted from the 2022 hickup http://web.archive.org/web/20210127174934/http://literumble.appspot.com/BotDetails?game=roborumble&name=voidious.micro.Jen%201.11

A strange thing is that most pairings wit 1 battle (of nz.jdc.nano.NeophytePattern 1.1) are either 2020.10 or 2022.3 (which is the exact time the last hiccup happened). This may indicate that the loss of pairings are resulted from restoration process.

http://literumble.appspot.com/BotDetails?game=roborumble&name=nz.jdc.nano.NeophytePattern%201.1&order=-Battles

Would it mean that there is a lingering database which has old pairing number? I.e. literumble thinks that there are plenty of pairing (thus not asking for more battles) but it shows in the stats only actual ones.

No, you can clearly see from the code that all data is saved into bot.PairingsList, which gets overridden each time a new battle is ran. So if a pairing is missing, the data may not be lost, but if a pairing shows 1 battle, then that's all LiteRumble has.

Skilgannon once said that he had backups. We could ask help from him and do a merge, e.g. take whatever pairing with max battle counter.