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

Are the stable rumble client 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)

I know 1.6.1.4 is stable (some earlier 1.6.1.x versions were bad), with a minor aesthetic bug that it sometimes spams the "Round 31 initializing...." to stdout but that doesn't affect the battles or the uploading so it's good for RR. Additionally, as of 1.6.1.4 the ITERATE option works properly again, so external loop scripts shouldn't be needed. I plan to test 1.6.2 Beta 2 some time but haven't done that yet. --Rednaxela 20:10, 10 December 2008 (UTC)

RUNONLY

I have RUNONLY=NANO in meleerumble, yet it still runs battles with tons of non-nano bots. 1) will this affect rankings improperly 2) how do you get it to run only nanos...as runonly is supposed to do (using version 1.6.0.1) --Starrynte 00:59, 3 April 2009 (UTC)

• I've never tried these modes so don't know how well they work. I'm pretty sure RUNUNLY=SERVER is the only way to guarantee full pairings, since that's the mode where the client uses priority battles sent by the server. Also, I think the client considers nano pairings in melee to be any matchups between two nano bots, even if there are other sizes in the same battle -- which means you don't need a battle with 10 nanos in order to get meleenano results. That's why ntc.Opposite's nano results are up to 600+ already. --Darkcanuck 01:18, 3 April 2009 (UTC)