From Robowiki
Jump to navigation Jump to search

Sub-pages: /Archive20130317

RoboRumble history

April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ

October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar

October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar

October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar

February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar

March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar


Thread titleRepliesLast modified
Publishing of scala robot416:46, 24 May 2021
Adding a new flag215:35, 31 October 2020
RoboRumble ranking unstable115:32, 13 July 2019 Could not load properties file: ./roborumble/roborumble.txt213:33, 24 March 2019
Upgrade client version3611:02, 7 November 2018
First page
First page
Previous page
Previous page
Last page
Last page

Publishing of scala robot

I decide to write robocode bot on scala to learn scala.
But there're a little problem - to run battles with them, you need download scala and add some libraries to rc classpath.
It's ok for me, if only my clients will run my bot. But will whole community agree, if i publish bot, which is not runnable in usual environment?

Jdev11:58, 22 March 2012

We shouldn't have bots in the rumble that can only be run on some clients. It's not really fair, and it makes us dependent on a few (or one) clients to get complete pairings for new bots.

There have been discussions about Scala in Robocode before and I think the current state is that we can't officially support it because it requires some insecure stuff disallowed by Robocode sandbox (like Reflection). See Talk:Other JVM Languages and this robocode-developers thread. Maybe we can revisit this discussion, but we'd need input from Pavel or Fnl, and possibly some Scala guru.

I'm also interested in Scala, and it might help us attract the edgy young functional programmers of the world if Robocode supported it. So it would be cool if we could. But I don't really know the details of how to do it right.

Voidious16:32, 22 March 2012

Edgy young functional programmers, eh? I must admit I am pretty interested in Scala too and that was one of the main things keeping me from giving it a real try.

Chase-san17:58, 22 March 2012

It's a pity... But i write robot on scala anyway. I will return to this question when take crown in my local tests:)

Jdev18:01, 22 March 2012

I'm also planning to write scala robot now ;) Since I write scala daily, and I was maintaining a fork of robocode featuring OpenGL, I think there must exist a solution to run scala robot without sacrificing robocode sandbox.

Xor (talk)16:46, 24 May 2021

Adding a new flag

Would like to add India's flag and link it to the code IND in the RoboRumble/Country Flagslist. I don't have a GIF. Help appreciated.

Vishius (talk)20:07, 28 October 2020

Welcome! I've added the flag, you should be good to go!

Skilgannon (talk)23:13, 28 October 2020

Thank you. Much appreciated

Vishius (talk)15:35, 31 October 2020

RoboRumble ranking unstable

For unknown reason, the RoboRumble ranking has lost a lot of pairings. MiniRumble and smaller seem not effected. So it will take a while for it to stabelize as there are lots of bots that are missing 1-40 pairings.

GrubbmGait (talk)11:35, 13 July 2019

That may be caused by a design flaw of the rumble client, which I didn't verify though. If the rumble cannot read robowiki's participants list, it will load a local cache instead. However, if that cache is outdated, it may cause the rumble to loose pairings, and recovering takes much longer. But this seems not to be the case losing 40 pairings.

Another possibility may be that the rumble client got a truncated participant list due to network issues, for this case, I may modify the client to check some flag to make sure the loaded participants list is full.

Xor (talk)15:32, 13 July 2019 Could not load properties file: ./roborumble/roborumble.txt

Hi all, has anybody had the same issue? When I start, it says "Could not load properties file: ./roborumble/roborumble.txt", and the execution stops right after initiating Iteration 0. In, everything seems to work.

Cb (talk)22:29, 23 March 2019

I never ever experienced the same thing. And the code change from is kept minimal that I couldn’t come up with whatever change could cause this to happen.

Anyway have you ever tried to have a clean install? Or maybe the path containing robocode contains some weird char that prevents robocode from processing (e.g. space, this bug is known)

Xor (talk)01:29, 24 March 2019

Thanks, that actually worked. I had to run the installation instead of simply unpacking the jar.

Cb (talk)13:33, 24 March 2019

Upgrade client version

Hi all

I've been thinking of upgrading the accepted client version. What are your thoughts on the matter? Have any of you tested extensively with the latest releases locally? Are there any changes in scores (or any changes that might affect scores) that we should do more extensive testing of first?

Skilgannon (talk)20:21, 5 July 2018

Finally released, with RoboRumble battle duplicating fix, and with shorter participants list check period from as well. It’s time to do a test and discuss to upgrade.

Question, what kind of tests should be done in local? Should we run a literumble locally and see whether it yields the same score as the main rumble? (which gives the best result but takes monthes). Or just using roborunner with a few robots (both 1v1 and melee certainly), and see their score is unaffected.

Xor (talk)02:08, 11 September 2018

Just roborunner and a few bots should be fine. At some point it would be good to reset the meleerumble as well, since old bots get biased downwards by excessive battles against new (good) bots.

Skilgannon (talk)07:02, 11 September 2018
Edited by author.
Last edit: 01:28, 4 October 2018

I've been always thinking about the pairing systems of meleerumble.

Once every combination of 10 bots had a run, the score is unbiased, which takes N = n! / (10! * (n - 10)!) ≈ 10^19 battles in current settings (n is the total of participants).

However we should get approximate score with feasible battles via monte carlo method. In current settings, ~10000 battles already gives a somewhat stable score (for the new participant).

Let each bot gets m battles, randomly selected from all (N / n) 10-bot combinations containing that bot, then the probability of meeting another specific bot in a battle is (N / n / (n - 1)) / (N / n) = 1 / (n - 1).

Assume that when a new bot is released, every battle contains that bot, then the probability of meeting that bot is 1 instead of 1 / (n - 1), which is highly biased.

To fix this, we have two options — mutate our current pairing systems to get unbiased score online, or to reset the entire meleerumble periodically.

Since the score of new bots are unbiased, all we need to do for an unbiased score is to ignore (n - 2) / (n - 1) biased battles randomly when calculating the score of an old bot. However this approach takes much more battles.

A more practical way is is, when bot A is added, for each battle, select another bot B randomly, and run melee battles containing those two bots as usual. A battle containing A, B and other 8 bots should yield 45 pairings, but only those matching (A, *) or (B, *) is taken into account. This produces 17 parings.

This scheme does not affect the pairings of the new bot itself at all, which is already unbiased; And for an old bot, the probability of being chosen as B is 1 / (n - 1), therefore the probability of a battle with A present being taken into account for old bots is 1 / (n - 1), the same as the unbiased one.

Xor (talk)10:29, 11 September 2018

Your second approach seems good, it will need patches on the client side so that if a priority pairing needs to happen it only uploads the battles which contain one of the priority bots. This filter will work fine for the 1v1 rumble as well.

Why don't we wait to update the client until this can be fixed too?

Skilgannon (talk)21:50, 11 September 2018

The only reason for upgrading earlier is that those two bugs are very annoying when running rumble client 7/24.

And it generally takes monthes for fnl to release a new version in normal cycle ;(

Anyway, since those two fixes are unrelated to robocode engine, one should expect no performance difference if we cherry pick the fix back to

Maybe we could release a special version of for those running rumble 7/24, before the melee pairing fix is released.

Or, we may just ask fnl whether he could please release soon after the meleerumble patch is applied.

Xor (talk)02:51, 12 September 2018

I patched robocode's roborumble by cherry-picking roborumble client fixes from and

The patched roborumble.jar can be downloaded from:

This should check participants list more often preventing retired bots from being battled and submitted nullifying smart battles. And on unstable network it won't upload 80000 duplicate battles for a single pairing any more. (See pulsar.PulsarNano 0.2.4 and ad.last.Bottom 1.0)

I suspect we should separate roborumble version and robocode version (since they are weakly dependent) and get roborumble bug fixes quicker than robocode, since roborumble bugs are generally more serious, and roborumble fixes has nothing to do with the rest of robocode users.

Currently fixes in roborumble takes almost a year to be actually deployed.

Xor (talk)05:57, 20 September 2018

I've enabled for uploads. Let's try it for a while and see how it goes. If we notice anything strange, well, the rumble probably needs a wipe some time soon anyway, and definitely melee.

Skilgannon (talk)17:18, 3 October 2018

I'll upgrade all my clients later and upload the same bot of mine with different version number to see the impact on score...

The melee part is already discussed, but why the 1v1 rumble needs a wipe as well? And how long it should take to reload the rumble? Or should we run the current rumble as a backup in parallel until the reload completes? (so that new players can still submit their bots)

Xor (talk)17:40, 3 October 2018
Edited by another user.
Last edit: 04:37, 18 October 2018

Seems something is wrong, ScalarN is suddenly first in mini, micro and nano rumble ! And ofcourse second in roborumble, which in itself is quite an accomplishment.

GrubbmGait (talk)01:07, 18 October 2018

Just removed ScalarN d.160

The only related change in d.160 is experimenting lambda expressions

And it seems that codesize.jar cannot analyze bots with lambda expressions and returning non-valid results

We should disable and wait for codesize fix along with my melee pairing fix.

Xor (talk)03:59, 18 October 2018

I submitted an issue:

The codesize utility currently uses BCEL 5.2 which cannot handle Java 6, 7, 8 features properly. And the roborumble client has a logical bug that treats codesize calc failure as codesize 0 and allowing it to participant in even nano. The correct logic should be treating codesize calc failure as infinity, only allowing it to participant in MegaRumble.

Xor (talk)05:14, 18 October 2018

I will definitely have to fix codesize as I have not touched it for many years. :O

Also notice that it will be faster to write to me a mail at fnl (at) in order to have me fix as many issues related to RoboRumble as possible (this has a high priority to me). Just tell me to look on this discussion, if all details are already provided. This way you'll not have to wait for me updating Robocode, Codesize, RoboRumble etc. :-) And thank you for providing me with patches for RoboRumble. It is a great help to all of us.

Fnl (talk)19:59, 19 October 2018

Thanks for the contact info ;) And it is my pleasure to help as well.

Xor (talk)06:23, 20 October 2018

Codesize 1.2 for Java 7, 8, 9 (Experimental) is ready.

Do we need to fix other stuff for RoboRumble before I make another release?

Fnl (talk)21:42, 28 October 2018

Sure, the meleerumble pairing algorithm also needs a fix. I’ll send you a patch then.

Xor (talk)03:35, 29 October 2018

The melee pairing fix is now fully tested and available as a pull request:


Xor (talk)06:22, 4 November 2018

Your pull request has now been merged and I have assembled and put a beta version here:

If you are satisfied with this version, I will make the release. :-)

Fnl (talk)00:03, 7 November 2018

Thanks, I will test it.

Xor (talk)08:11, 7 November 2018

It seems that the codesize part is not working completely. Both in roborumble and in the builtin editor. info: I'm using Oracle JDK 1.8.0_181 on mac.

Xor (talk)08:25, 7 November 2018

It seems that codesize-1.2.jar cannot work on my machine at all. Can you have a test of this version as well?

Xor (talk)10:51, 7 November 2018
First page
First page
Previous page
Previous page
Last page
Last page