Talk:RoboRumble

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

Contents

Thread titleRepliesLast modified
Remove some of my battle contributions207:48, 23 November 2011
Improve RR Battle management.406:02, 9 September 2011
First page
First page
Next page
Next page
Last page
Last page

Remove some of my battle contributions

It seems a recent backup restore may have selectively reverted my robocode roborumble config file, dramatically decreasing the cpu constant I use in my rumble configuration. Since I run many concurrently this `could have had` considerable negative rating for some robots.

So I ask you remove my contribs from the 15th onward. I apologize for not noticing this sooner.

Chase-san12:41, 20 November 2011

No worries, I have a mostly-automated method for cleanup. Will do this in the next few days as soon as I get some free time. Everything from the 15th to the 20th (inclusive)?

Darkcanuck07:12, 23 November 2011

That should do it. I cannot be sure it actually corrupted any rankings, but better safe then sorry right?

Chase-san07:48, 23 November 2011
 
 

Improve RR Battle management.

Have the server run the main rumble against robots like it does now, with the following addition.

First give option of running a random battles a lower chance (say 20% to 40% area).

After it has gotten the most critical robots stabilized (current behavior).

Find the pairing that has the lowest number of battles run, and run that. If there is a tie, run the robot that has the lowest number of battles. If there is a tie of that, just use the first one that comes up in the query (less server work then random).

That way even old robots with tons of battles are still considered for more battles and it helps overall stabilization.

Chase-san03:30, 8 September 2011

The optimal criteria for prioritizing battles depends on the ranking system, although aiming for equal number of battles per pairing works well for most systems. Old robots with tons of battles are still considered whenever a new competitor enters the rumble.

Old robots don´t really need more battles on old pairings except with incremental Elo rating system. Incremental Elo works better with random pairings (equal frequency instead of equal quantity).

MN02:00, 9 September 2011
 

Not old battles on old pairings. But rather battles on low number of battles for a pairing. Even if a robot has hundreds of thousands of battles. Those battles were selected randomly before, meaning there may be pairings that only have 2 or 3 battles (possibly, I cannot name any, but it is within the realm of possibility). Which is why I stated select those pairings that have low number of battles, regardless of number of battles the given robot has.

Chase-san02:58, 9 September 2011
 

That's how the current system already works: it seeks out pairings with low battle counts, regardless of either bot's total battle count. The tie-breaking you've proposed is unecessary, although perhaps the random % could be reduced. Try finding a pairing with less than 7 battles now; before the change it was common for ancient bots to have some 2- or 3-battle pairings, now they're extinct.

Darkcanuck03:42, 9 September 2011
 

I think the more stable we can make the rumble by running a great deal of battles, the better. Since my clients are almost pulling around the clock battles (and will be for awhile yet).

Chase-san06:02, 9 September 2011
 
First page
First page
Next page
Next page
Last page
Last page