Talk:RoboRumble/Contributing to RoboRumble

Credits - RoboRumble/Contributing to RoboRumble Old wiki page: RoboRumble/StartingWithRoboRumble Original author(s): RoboWiki contributors

Old Wiki

---

I presume all older issues are not valid anymore, otherwise you can find them on /StartingWithRoboRumbleOld or put them here below again.

---

Sweet. Much easier now thanks. How can I control how many battles are run at once? Or should I just setup a for loop in a batch file for that? --Miked0801

• Halfway the file "roborumble.txt" you'll find "NUMBATTLES=xx", there you fill in the number of battles fought before uploading results and quitting robocode. In the batch-file I have made an infinitive loop so my client can run unattended all night. -- GrubbmGait
• (Edit conflict) There are .txt files for each type of rumble - roborumble.txt, meleerumble.txt, and teamrumble.txt - in the 'roborumble' directory. The "NUMBATTLES" controls how many are run before uploading, "BATTLESPERBOT" is the minimum number of battles a bot needs before it stops getting priority, and "USER" is just to identify yourself in the logs and such. I have mine with "ITERATE=NOT" and I do use a shell script that loops to keep it running. -- Voidious

this bash script will be good for unix "roborumbler". Run forever battles, it catch standard and error stream and put it to a file in the directory ./log/tempNUMBER_OF_BATTLE.txt (the script have to be in the roborumble directory). For Linux: save it to a file in the roborumble directory, right click and set the file executable, create a directory called "log", then run the script from shell:

#!/bin/bash

echo #  new line
count=0
while [ "$var1" != "fine" ]     #  forever
do
  let "count=count+1"
  echo "battle n: " $count
  sh roborumble.sh &> ./log/temp$count.txt
  echo
done  

exit 0

p.s.: it's very useful for catch error, someone can traslate the script in windows's dos? Asdasd

Wow - is 256MB still the default for the rumble? Why not at least 512, if robocode's default itself is 512? -- Simonton

I'm not sure - maybe because the GUI takes a lot of memory? -- Skilgannon

Ehh, the GUI shouldn't, not compared to many adaptive bots (particularly log targeting). Personally I always set 512MB in the rumble, and the only time I've had an out of memory problem with 512MB was when some particularly memory-heavy team (can't remember which one) was going. Personally I'd support defaulting to 512MB, at least for teams/melee, if Fnl is listening :-) -- Rednaxela

Can someone please zip a new update, i've unzipped the archives above and still get a ton of "Ignoring xxx..." message because they weren't download...thank you! (or even better someone start a new repository and put the zipped bots there...) --Starrynte

RoboRumbler

I didn't know where to post this, but I guess the talk section is always good enough. I created an Java Application called RoboRumbler to help controlling the resources RoboRumble uses. It's basically an application to let me work and run RoboRumble at the same time, I further explain it in it's page if anyone is interested. --zyx

Hmm, I'm curious about this. How does it account for the fact that RoboRumble is highly sensitive to the amount of CPU allocated to it? (i.e. other apps taking lots of CPU can make bots skip turns and potentially give very wrong results). If this limits the CPU allocated to RoboRumble, does it correctly make sure the constant for the time robots get per turn is increased suitably? (P.S. on the new wiki you can use --~~~~ or the signature button to sign your messages with time/date easily. Personally I'd recommend it because it makes it possible to look back at conversations and know when they happened. :)) --Rednaxela 21:45, 26 November 2008 (UTC)

Right now the application is not intended to work with CPU intensive applications, it basically runs them in the same way as they would normally do, but allows you to run then from time to time, and then forever by itself again and stuff like that. So you could be working in the machine, but not hogging the CPU yourself, you can set it to have a few battles and then sleep for 20 minutes. You could be writing some code(I did it to work on my thesis in the mean time), but not execute it until the RoboRumbler goes to sleep. Then you would have those 20 or any other amount of time to use the whole CPU when no rumble battles are running, so you could compile and test your application, and then, when the rumble is about to start again, you lower your activity. And when you are heading to your bed, set the sleep time to 0 and let it rumble without stop.

Hopefully it will grow to a system that doesn't need for the user to be careful, but right now is the best I have. I was doing the same thing but manually, I ran the rumble battles while I was writing stuff, waited for it to finish so I could ran my application and then set the rumble again. But in no moment my idea was to really lower the CPU usage for RoboRumble during battles, but to have some deterministic break times when I could use the computer. (P.S. Thanks about the --~~~~, I saw it before in your post, but thought you wrote it yourself, and seemed like to much work) --Zyx 23:44, 26 November 2008 (UTC)

==stable rumble client==

The stable rumble client is 1.5.4 and, 1.6.0 or 1.6.0.1? someone have tested the new robocode version? --lestofante 15:44, 10 December 2008 (UTC)

We're (finally) getting our internet sorted tomorrow so I should be able to start running more battles again soon. Is there any reason I shouldn't set BATTLESPERBOT to something higher to get some of the newer melee bots caught up a bit?

Surely you can set this variable as large as possible, since most bots already had way more battles than this value. And there could be a pull request to robocode to change the default settings.

That's what I figured but I didn't want to be the person who screwed up the results and forced them to be recalculated from scratch so figured I'd check with those who know better than I do. Looks to me like a default of 100k wouldn't be unreasonable for melee. Not sure about duels, maybe 30k?

I think the best is to dynamically adjsut the value based on current battles per bot, e.g. 80% * pct1 of battles per bot. In the meanwhile, you can safely set this value lower than the second lowest battle counts.

If I recall correctly, even if all bots have more than BATTLESPERBOT battles, bots with less battles get some priority. An other priority is 'old' battles (where f.e. the last battle is from 2020) even if those bots have a lot of battles. Also if I recall correctly, in melee there is some protection to prevent battles between only 'new' bots, I think only 1 new bot per battle and the rest quite randomly. Setting the BATTLESPERBOT higher does not influence this. Ofcourse bots with incomplete battles always get the highest priority.

Currently, the Robocode download site shows versions 1.9.2.6, 1.9.2.5, 1.9.0.0, 1.8.0.0, 1.7.4.4, 1.6.1.4, and 1.0.7. Versions 1.8.1.0 and 1.8.2.0 are not available. Also, the Roborumble Superpack link is now a dead link. Are there any other versions that are okay to use? If not, we may need to host the older suitable Robocode versions somewhere and update this page accordingly.

Hey, according to [1] the currently used version is 1.9.2.5. I can update to 1.9.2.6 if we need it.

Otherwise feel free to fix old links and reword pages, this is a wiki for a reason =)

Ah, I didn't know the version was reported there. I'll update the page that suggests older versions. Thanks.

The Superpack download link(to Dropbox) is broken, Dropbox says "File not Found 404", please update it.

Rednaxela setup this automatic mirror which includes a big zip of all the current RoboRumble participants: [1] ... We should probably replace the superpack link to just point to that.

Seeing as I was going to try this on a RP2 soon, I was going to get it working on my laptop first. But I had a couple of questions for those in the know that don't seem to be answered on the page or the discussion:

1) Should we always run the latest version of Robocode available for the rumble? (Starting with Rumble page mentions several versions of Robocode, none of which are the latest) 2) Does it matter any more what version of Java we use to run the Rumble with? 3) Does it matter if I interrupt the rumble process at any time? Will this corrupt the results? Or can I run a few battles, quit, start again etc etc.

Thanks! (I might turn the answers into an FAQ on the rumble page)

As an addendum to this, the same applies to the robots you submit to the RR. I see the latest Agent Smith has disappeared from the RR results but i'm not sure why but I was wondering if it was because I compiled it against the latest version of Robocode and Java but I'm not sure how I find out what the problem is! :)

1. Roborumble version allowed is here: [1] - currently 1.9.2.3
2. Anything Java6+ should be fine for running
3. Interrupt away! It will have to re-download some of the files on startup though, and will only upload results once it has been running for a while. And you only get priority battles when you upload results, so until then you might be running battles the server doesn't think is important.

Addendum: Try to compile with Java 6 (or 7) compatibility, since you don't know how old the JVM they are running on is. Also, it looks like it has been a few days since anybody has run battles, and until they do nothing will happen =)

Have fun!

I'm running battles right now

Can someone update this page with the correct URLs to get roborumble to work? Thanks.

Might also be good if someone puts a note on the page about Java versions. Lots of "Unsupported major.minor version 51.0" running with Java 1.6. I'm not sure what we should be using at this point.

I tried simply replacing darkcanuck.net with literumble.appspot.com, but apparently it's more complex than that. Roborumble can't download the ratings file and can't upload results.

That should be all you need, make sure you replace the URL for all 3 instances. The default Robocode install should come with the correct URLs now.

A couple of things. One, the URLs no longer have "/rumble/" like the used to. Removing that fixed the URLs. Also, it appears the accepted clients are now 1.8.1.0 and 1.8.2.0. It appears the 1.7.3.x clients are no longer accepted. I'll have to check, but the 1.8 Robocode clients may require Java 1.7. Guess I'll find out in the next few days. I'll try to update this page, but I am kind of learning as I go to figure it all out.

I updated the "From standard Robocode" section. Additional updates are required to bring the page up to date. Someone needs to bring all the superpack info up to date. I'm not personally up to date on what superpacks are available. If no one else updates it, I'll get it figured out in a few days and update it.

I'm sure the "major.minor" thing has come up before, but I didn't find it in a quick search. The list of robots I see this on includes: alpha.RainingFire ancientpyro.megas.kbot.KBot bots.UberBot bumblebee.Bumblebee cb.DeepThought cb.droid.Polyphem cb.Femto cb.mega.Enigma cb.micro.Haiduc cb.nano.Chasseur cb.Sabertooth cb.test.Provocateur com.timothyveletta.FuzzyBot daemons.DizzyA dhn.Immortal fromHell.C4H10O kb.PingPong kenran.InfiniteObscurity Lo_Ian.Gandalf_V4 mae.Mae1 mb.Beast mb.Monte qualidafial.MajorDick rc.RCBot romz.robot.circular.WildRabbit romz.robot.guessfactor.TeasingFox romz.robot.Test sfergus.Terminator stranger.nano.TestBot suh.micro.MirrorPM suh.micro.WallPM suh.nano.AntiGravityL suh.nano.CornerRL suh.nano.MyFirstAdvancedRobot suh.nano.RandomPM tkt.RedShift zignd.ZigIndexOutOfRange

Yikes! We're only supposed to require Java 6. And in the past I've removed bots from the rumble for requiring Java 7 and put a note on the participants page for those bots. But with that many, I wonder if it's time for us to just say to use Java 7?

At this point, I'd note that Java 6 is no longer being maintained for security fixes, and has outstanding exploits against it so... better be upgrading to Java 7 for other reasons.