Talk:RoboRumble/Reported Problems

Repeated Battles

Not sure if this is the best place to put this, but here it is. My roborumble client would keep getting hung up running the same bot over & over, regardless of how many battles it already had or how many other bots were below the BATTLES_PER_BOT limit I set. I think I took care of the problem by deleting files between between runs of the rumble. This is my roborumble.bat file now:

:TOP
java -Xmx256M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;libs/codesize.jar;libs/roborumble.jar roborumble.RoboRumbleAtHome ./roborumble/roborumble.txt
del roborumble\temp\battles*
del roborumble\temp\priority*
GOTO TOP

I think the priority battles file was the culprit, but I'm leaving the other line in for good measure. --Simonton 16:35, 22 September 2008 (UTC)

Woah, I certainly see the results of these stuck pairings... such as Drifter vs Okami over 200 times, and similar for Fermat vs Okami. It sure feels unusual seeing over 100 battles in any pairing in RR, but at least we know those pairings are accurate haha. --Rednaxela 19:22, 22 September 2008 (UTC)

As for accuracy, below is the impact of battles on the score. This is 0.7*old + 0.3*new. For first battle you can also read 'all battles till now'. This means that 2 new battles will reduce the influence of the previous ones to 50%.

         1   2   3   4   5
first   100
second   70  30
third    49  21  30
fourth   35  14  21  30
fifth    25  10  14  21  30

--GrubbmGait 23:52, 22 September 2008 (UTC)

Sorry, Grub, I'm not really following you. What does this table represent? What is its relevance to rumble scores? --Simonton 23:57, 22 September 2008 (UTC)

It's the influence of each battle on the % score. From the table, after a bot has 5 battles in a pairing, the most recent battle has a weightage of 30%, 2nd most recent 21%, third is 14%, fourth is 10% and the first battle ever run for that pairing is 25% (the first battle always has a disproportionate weighting) towards the % score for that pairing -- KetsuNfwu 08:48, 23 September 2008 (UTC)

My fault, I should have explained it better. Its relevance to the stability of the rumble scores is this: The last 4 battles determine 75% of the performance against an opponent. So when 100 battles are fought against a particular bot, battle 1 till 96 determine only 25% of the performance. The good part is that this info can be used to 'repair' results from bad clients. --GrubbmGait 19:23, 23 September 2008 (UTC)

Now I understand! So - the rumble uses .7*averagePercentScore + .3*percentScore (similar to a Rolling Average) to calculate the %score of any given pairing, and you are showing us that running 100 battles doesn't really make that number any more reliable than running maybe 10 battles (at which point the first only has a weight of 4%). ABC talked about making his server use absolute averages instead of rolling averages; I wonder if he implemented that. --Simonton 20:15, 23 September 2008 (UTC)

Security exception 1.6.0

One bot suffers from a security exception in v1.6.0, namely axebots.SilverSurfer. It seems the only bot that has this problem, so the impact is not that big. Maybe someone (or Axe himself) can update the bot so it can be processed by the latest robocode versions. --GrubbmGait 23:52, 22 September 2008 (UTC)

IllegalThreadStateException

In response to a bug report I filed, FNL has made a patched 1.6.4.1 robocode.jar that doesn't suffer from the annoying IllegalThreadStateException while running the rumble. It is available at http://robocode.sf.net/files/robocode.jar, though it doesn't sound like it will be there forever. --Simonton 21:35, 14 August 2009 (UTC)