View source for 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
Version 1.7.3.6?615:05, 15 October 2012
Rumble Client 1.7.3.2 vs 1.7.3.0416:45, 26 June 2012
1.7.3.6111:43, 1 May 2012
Use POST instead of GET for uploading rankings304:09, 1 April 2012
http://www.robocoderepository.com/ domain name expired on 03/05/2012 and is pending renewal or deletion616:14, 27 March 2012
Melee ranking ... 1718:24, 18 March 2012
SQL error119:04, 7 December 2011
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

Version 1.7.3.6?

Anyone object to having Robocode 1.7.3.6 as a rumble-approved version? There have been a number of bug fixes over time, no changes I'd expect to introduce issues, and additionally 1.7.3.2 and 1.7.3.0 can't actually be downloaded from sourceforge anymore apparently.

Rednaxela19:28, 14 May 2012

I actually emailed Darkcanuck about this... he said he's been busy but he'll get on to this when he has time. Until 1.7.3.6 I can't really contribute to rumble as my client keeps hanging during upload - especially once all 4 clients try to upload at once.

Skilgannon20:00, 14 May 2012
 

Any update on this? I was looking to start setting up Robocode again, preferably a version that can be used for the rumble. I'm going to hold off until I know what version to use and where I can get it.

Skotty04:21, 14 October 2012
 

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:RoboRumble/Version 1.7.3.6?/reply (3).

If someone builds a new server, I would ask to not restrict it to only a few versions (i.e. 1.7.3.0, 1.7.3.2). Doing the opposite, banning only specific versions, with the latest versions being allowed by default, would work a lot better.

MN14:55, 15 October 2012
 

If we set up a new server I have some changes which will need to be made to the melee priorities battles. The current system sends back a priority battle for each pairing, and the client just runs the first N.

Skilgannon15:05, 15 October 2012
 

Very well. I'm going to check my backups and see if I have a copy 1.7.3.2 to use. I'm pretty sure I have a copy of 1.7.3.0, but I would rather not use that version due to the bullet bug in that version (http://sourceforge.net/p/robocode/bugs/303/). But if it's all I got, I'll go ahead and use it.

Skotty06:57, 14 October 2012
 

Rumble Client 1.7.3.2 vs 1.7.3.0

Hi mates. I recently spotted some robots that might only work well under 1.7.3.2 (Wolverine, Tachikoma) and i'm not sure how to deal with it. By now the score of these bots are dependent of the contribution version and this inflicts the overall score i guess. I'm running on 1.7.3.2 and mainly contributed to MeleeRumble so i guess all my results vs those bots are ok. On the other hand KID_RINZLER (the new main contributor, great job btw.) is running 1.7.3.0 and now these bots get worse. So the overall ranking now depends a little on how many games vs those bots my client (MN as well) picks and i'm quite unhappy with it. What do you think is the best way to handle this. I guess the best solution would be to change the RumbleServer to 1.7.3.6 but until Darkcanuck find the time to do this could we maybe think of a quick fix somehow.

Take Care

Wompi09:59, 26 June 2012

The quick fix would be making bots compatible with Robocode 1.7.3.0 and Java 1.5.

Usually, bots which are incompatible with the official versions in the rumble are removed from the participants list.

MN14:35, 26 June 2012
 

I dont think the rules are 1.7.3.0 only. Or did i miss something? Otherwise this would be a big surprise to me because i build my bots on 1.7.3.6 and have no idea what methods 1.7.3.0 supports and what not.

Wompi16:27, 26 June 2012
 

It seems very strange, especially considering Wolverine is an ancient bot. There should be no rule or API changes between those versions. If those bots are unstable, I guess I'd vote to remove them, at least temporarily until we can figure out what's up.

For some open source bots like SilverSurfer, people have fixed issues introduced by new versions of Robocode and posted the fix to the rumble, which is a cool solution when possible.

Voidious16:30, 26 June 2012
 

Wolverine is open source and he uses get...Events() to utilize his bot instead of overloaded eventMethods. My guess is, this is the issue somewhere between the versions. I only can say that every result uploaded by an 1.7.3.2 client leads to good behavior and 1.7.3.0 leads to "sitting duck" the bot.

Its up to you Voidious to remove the bots, i think it concerns you the most. Because Diamond would jump up and down his rankings. I personally don't care that much for now - they are not my weight class.

Wompi16:45, 26 June 2012
 

Hi darkcanuck Can you add 1.7.3.6 to the list of allowable upload clients? It's fixed a bug with upload timeouts so that they don't hang the rumble client, which has been holding me back from uploading at home.

Thank you!

Skilgannon11:16, 1 May 2012

Hi Skilgannon. You can take the 1.7.3.6 copy of "../libs/roborumble.jar" and copy it to your 1.7.3.[0|2] version. There you have the new rumble client with the fixed timeout.

Edit: Ahh i think i missread the question. You probably know that already.

I would also like to see 1.7.3.6 as new upload client.

Wompi11:36, 1 May 2012
 

Use POST instead of GET for uploading rankings

Some slight modification will need to be made to both the server and the client. But the only excuse I can really think against it is that 'it works as is'. But post is faster, and not really hard to do on either side.

How to use post on the serverside.

<?php

$postTotal = $_POST['total'];
for($i=0;$i<$postTotal;$i++) {
	handleUpload($_POST['r'.$i]);
}

?>

Wooo done, barring some parsing that should be already written.

How to use post in Java

public static final String sendPostAndGetReply(final URL url, final String post) throws IOException {
	URLConnection conn = url.openConnection();
	conn.setDoInput(true);
	conn.setDoOutput(true);
	conn.setUseCaches(false);
	conn.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
	
	DataOutputStream out = new DataOutputStream(conn.getOutputStream());
	out.writeBytes(post);
	out.flush();
	out.close();
	
	//IOToolkit.getAndClose just gets all the bytes from a stream then closes it
	return new String(IOToolkit.getAndClose(conn.getInputStream()),"UTF-8");
}

Barring some encoding which is also already done.

I know the encoded string looks something like this, except URL encoded.

roborumble,1,800x800,Chase,1326909734701,SERVER;cs.pm.Pytko 1.1,119,49,1;cs.ExclusionNano 1.1,19,19,0
Chase-san10:58, 31 March 2012

Practically, is this going to make any difference? I think the slowest part of processing a result is by far the database activity. "It works as is" is a pretty good reason up against virtually no impact. :-)

Also, I did some quick Googling to see how much faster it is, and it seems like everyone says they're the same or GET is faster.

(If we are going to change the protocol, maybe we should go with SPDY. ;) jk)

Voidious14:19, 31 March 2012
 

I remember POST already being used for uploads the last time I checked the client code. And the main difference between GET and POST is not raw performance, but how proxy servers deal with them. GET is usually cached while POST isn´t.

To increase upload speed, batch uploads (everything in a single request) and batch inserts in the database (everything in a single commit) would do a better job.

MN16:20, 31 March 2012
 

Ah, are they, that is sorta what I ment, meaning you can just bundle all of them in a POST and upload them all at once. I figured it was still using GET, which makes batching more difficult.

Chase-san04:09, 1 April 2012
 

http://www.robocoderepository.com/ domain name expired on 03/05/2012 and is pending renewal or deletion

My RR-client cannot download some robots:

Iteration number 0
Downloading rating files ...
Downloading participants list ...
Downloading missing bots ...
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:com.cohesiva.robocode.ManOwaR_1.0.jar
Could not download com.cohesiva.robocode.ManOwaR_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:FatalFlaw.FatalFlaw_1.0.5.jar
Could not download FatalFlaw.FatalFlaw_1.0.5.jar
Downloaded lxx.Tomcat 3.57 into ./robots/lxx.Tomcat_3.57.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:SFS.SamsSecondRobot_1.0.jar
Could not download SFS.SamsSecondRobot_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Megas.AGravitatorExcel_1.0.jar
Could not download sp.Megas.AGravitatorExcel_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Megas.AGravitatorExcel_1.4.jar
Could not download sp.Megas.AGravitatorExcel_1.4.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Megas.Trident_1.0.jar
Could not download sp.Megas.Trident_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Micros.LCreeper_1.0.jar
Could not download sp.Micros.LCreeper_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Micros.LExtermination_1.0.jar
Could not download sp.Micros.LExtermination_1.0.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Minis.LNightHawk_1.2.jar
Could not download sp.Minis.LNightHawk_1.2.jar
java.util.zip.ZipException: error in opening zip file
Downloaded file is wrong or corrupted:sp.Nanos.CopyMachine_1.0.jar
Could not download sp.Nanos.CopyMachine_1.0.jar
Removing old participants from server ...
Removing entry ... lxx.Tomcat_3.56 from roborumble
OK.  Removed bot lxx.Tomcat 3.56
Preparing battles list using smart battles...Prioritary battles file not found .
..
Executing battles ...

Can anyone share this robots? Or, maybe, we should remove them?

Jdev09:23, 22 March 2012

I understood scale of tragedy... We're really needing in new robocoderepository server

Jdev09:32, 22 March 2012
 

I updated the robots database pack in the Starting With RoboRumble page. It was after robocoderepository went down, and was complete at the time.

MN14:53, 22 March 2012
 

Do we have access to the last sources and data somehow? If so, i could try to set up a temporary repository on my server.

Wompi16:32, 25 March 2012

I think the repository need a major rewrite anyway. (Even the redirect has serious bug that prevent it from working in some browser. It returns non-standard HTTP header [302 Temporarily Redirect]). The data could be re-uploaded from RoboRubmble Starter kit.

As for the source code, it seems that neither of us has hold of it.

Nat Pavasant04:30, 27 March 2012
 

Well, rewrite would be a little to much for me by now. I wrote an email to the repository maker once but didn't get an response (probably to dated) but i'm sure one of the veterans have a current email address of him.

What do you mean with the data could be re-uploaded from Roborumble starter kit? Do ypu mean the current robots who are registered at the competitions? Not every robot package includes the sources, most of the old robots had his sources published over the repository. And it would be a great pitty to loose the comments of the authors as well.

Has someone an idear how to handle this issue?

Wompi14:07, 27 March 2012
 

The RoboRumble starter kit is enough to keep RoboRumble alive for now.

But contacting the Robocode Repository admin somehow would be best. So we could recover all that robot archive and mirror it somewhere else.

MN16:14, 27 March 2012
 
 

Melee ranking ...

Hi mates... (sorry for my bad english) Can i suggest a discussion about the melee ranking in mini, micro, nano weight? Maybe i don't fully understand how the ranking is working, please correct me if i'm wrong.

To me it looks like, that the lower weight classes are influenced by the battles against the higher weights. Lets say we have a nano bot who is specialized on close combat. Against the own class bots it could survive very well because the other bots are also limited and you can put more code in the gun than the movement. If it now comes to pairings against the, lets say mega bots, it has to die very quickly because it goes still close to the enemy (not the best idear against a heavy gun). This is just an example. What it shows, is that you have to deal with the mega bots and there is only one option - improve the avoid movement. If you improve the movement you have no codesize left for a competitive gun against your own class and so on. I think the current ranking system fafors the movement more than it should. One more point is that the current ranking favors mega weight (more bots) and so you get way more battles where you are paired against bots of other classes (it looks like 3:1 battles against higher classes). My suggest is to make the weight classes indepentend. I think you can still be paired against the higher classes but it shoul'nd count for your current class if there is another bot of your class within this pairing.

I hope it is clear what i meant and you should see what i want to say. My english writing isn't that good and i wished i could explain it a little more ... but well you know:)

Wompi

Wompi14:06, 14 March 2012

You want nanobot rankings to use battles with nanobots only.

I think it is not being done mostly because of historical reasons. 10 years ago there was barely enough CPU to process a single melee league, much less 4 independent melee leagues.

Today it might be viable. But the client needs to be modified and the melee rankings in the server needs a reset.

MN14:41, 14 March 2012
 

Yes this is what i want. Aswell mini and micro. Hmm are you sure about the historical reasons? Because the single bot weight classes are independent as far as i can see this. My thought was that the battle pairing script isn't capable of matching the bots on weight classes for melee.

I'm not sure if the client has to be changed, would'nt it be the same logic just with other battle pairings? I mean if the client is ready to run shuffled melee it should be ready to run weight class battles just as good. I think there might be some work on server side to bring the right battlepairings up, but i could be wrong. About the reset of the current ranking results, well i have'nt thougt about this. I'm not sure how big the influence would be on the current results. On the other hand, maybe a reset brings back some vets to work on there bots again - who knows.

All in all i really would like to see a ranking by classes. I find it very educational to start with the lower classes, because there is plenty to learn from.


Sidenote: MN can you do something with your mn.SuperSittingDuck 1.0 it says on both (1.7.3.0 and 1.7.3.2) clients that i cannot handle this bot. It is something around version minor/major. (not quit sure i can recheck this if you want) ... no offense. It would just be nice.

Wompi16:52, 14 March 2012

Did someone find a bug in my single-line-of-code bot?

That bot was generated with the internal Robocode IDE. The only causes I can think of are Java 1.5 incompatibility, or corrupted downloads.

MN22:40, 14 March 2012
 

Todays download (1.7.3.4 client) .. rebuild database Got an error with mn.SuperSittingDuck: java.lang.ClassNotFoundException: mn/SuperSittingDuck : Unsupported major.minor version 51.0

Wompi14:34, 15 March 2012

Java 1.5 incompatibility then. I´ll update the bot later.

MN15:16, 15 March 2012
 

I think there are quite a few bots compiled with Java 6. Any chance you can upgrade? Java 5's pretty old. Even us Mac users have Java 6 now. =)

Voidious15:25, 15 March 2012
 

Hmmm .... i got:

Terminal: java -version java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

Robocode About: Running on Java 1.6.0_29 (64-bit) by Apple Inc. 

So i'm almost half sure :) that i'm runing on 1.6 ... i will recheck this. And SuperSittingDuck is the only bot who gives me this exception.

Edit: looks like you used 1.7 ... according to wiki - class version 51 is 1.7.

Wompi16:03, 15 March 2012
 
 

One thing to be clear about: while a battle containing MegaBots is not ignored in the NanoBot rankings, only the relative score of two NanoBots in that battle is contributed to NanoMeleeRumble. If NanoBot A gets 9th with 500 points and NanoBot B gets 10th with 300 points, what's logged to the NanoMeleeRumble is A winning over B with 62.5%. NanoBots that do particularly well or poorly against MegaBots will still have their rumble score impacted by how many NanoBot-only battles they get, though.

Since most bots in a weight class have similar weaknesses against bigger bots, I don't think it's having a huge effect, but it isn't zero either. I've seen MicroBots have their MicroMeleeRumble score change by maybe 0.5 APS from the time they have 2000 Mega-battles to the time they have 2000 Micro-battles.

I agree counting only all-NanoBot battles for NanoMeleeRumble would be better, and that the CPU load is probably not a huge issue. (Non-MegaBots tend to be so much faster, Melee rumbles have less activity than 1v1, and our CPUs have gotten much faster, too.) I think the biggest hurdle is how much work it would take to implement vs how much it would really change scores. I think it would require client changes, too, because the client is what decides which pairing data gets uploaded to which rumble.

Voidious17:24, 14 March 2012

Those 2000 Micro-battles all have megabots in them.

In a nanobot only league, nanobots will be killed by other nanobots. Simple targeting against simple movement. It might completely change survival scores and rankings. If you watch a samplebot only melee battle, Walls usually survives last. Add a single megabot and Crazy tends to survive longer. (flatter movement profiles tends to be ignored by top bots in melee)

I could volunteer to update the client, although there are other things in the rumble bothering me more, like slow client uploads. I would prefer to fix those first.

MN22:59, 14 March 2012
 

What do you mean? As far as I know, it works like this:

  • MegaBot battles until 2000 battles in MeleeRumble.
  • Battles against lowest weight class bots only until 2000 battles in lowest weight class.

It used to go MiniBots until 2k in MiniMeleeRumble, then Micros, then Nanos, but it was changed to result in less overall battles for Nanos/Micros, since they're already getting so many extra before they've stabilized in every weight class.

Voidious02:15, 15 March 2012

Currently, all melee battles mix all weight classes.

All bots battles until there are 2000 battles in megabot ranking. 2000 is the sum of all pairings against nanobots to megabots.

But in nanobot rankings the sum of all nanobot pairings is still lower than 2000. Then all bots battles until there are 2000 battles in nanobot rankings. Which means the sum of all nanobot pairings is 2000, but all those battles in nanorumble still include megabots.

Almost no battles have 10 nanobots. A battle with 2 nanobots and 8 megabots also counts for nanorumble. And those 8 megabots affect the APS between the 2 nanos. Those 2 will be crushed before having the chance to interact with each other, the nano with worse movement profile being crushed first.

MN15:09, 15 March 2012

I was very strongly under the impression "but all those battles in nanorumble still include megabots" is not the way it is. Yes, the battles from when megabots are getting to 2000 score *are* still counted, but new battles made specially for the smaller league only include smaller league bots. At very least, that's how it used to be I believe.

Rednaxela18:12, 15 March 2012
 

Really? Definitely not how it used to work, and sounds like it could even be a bug in the client. Maybe Darkcanuck can comment.

Voidious15:26, 15 March 2012
 

I had a look at the client source and to me it looks that the battle generator works a little bit different. As allways i might be wrong with that but to me it looks that the client pairs allways first the bots out of the "prioritymelee.txt" (send by the server) against the whole competition. If the server sends no priority file (does that ever happen?) the client checks the bots current battles against the BATTLESPERBOT property. The client checks this property from top down GENERAL,MINI,MICRO,NANO. If you have the standard property of 2000 battles this means by the way you come to the nano class you have 2000 general (all bots) 2000 mini (mini,micro,nano) and so on battles until you reach your own class weight. Til then it it is very possible that you have the 2000 battles reached in your own class and you never come against your own class only. You can recheck this by having a look at the "PrepareBattles.java" class.

Beside the battlegeneration i still find there is another reason while we should think about weight class only competitions. Voidious stated above with his example of bot A and bot B only the relation between this two bots. But if you take all bots of your weight class into account you see that bot a might be better in this particular battle and might be the best bot in his class. But if bot B has an overall better movement he will sum up scorepoints against all weaker bots of his class and so in the end he will be better than A. Maybe the example is'nt so good but i would just show that you have to look on the influence on the whole weight class. If a bot has a stronger movement it is most likely that he will gain an overall more score than one bot with a weaker movement but a strong class releated gun. Moreover, how the client picks the opponents is very random and it can be that bot B allways (or at least more) become weaker mega bots then bot A and this can generate another influence on the overall scoring.


Please feel free to correct me if i'm wrong. I'm still very new to robocode/roborumble and it might be this lack of experience that took me the wrong way.

Wompi18:02, 16 March 2012
 

Slow upload isn't client problem; it's the server. I believe darkcanuck is throttling the upload on the server because the server can't handle the load,

Although if we do this we should clear all the battle data from nano/micro/minimeleerumble, too.

Nat Pavasant12:38, 15 March 2012

Its how the protocol works which slows down uploads. According to Bwbaugh, the server can handle about 30 clients. Or can handle 30 times what a single client uploads.

The ideal would be to adapt the protocol for batch uploads, but it is also possible to achieve a similar speed up changing the client alone.

Faster uploads would benefit all leagues, melee leagues even more, since a single melee battle generates about 45 to 180 pairings.

MN14:58, 15 March 2012
 
 

Hi mates.. I had today another closer look at the meleeranking and it turned out there is a kind of a bug in the prepare battle behaivior. The client, as i somewhat above stated, takes allways the "prioritymelee.txt" entrys first and then pairs it against the whole competition field. The prioritymelee file contains single competition bots as well what is not much of a problem because these bots will be filtered and the pairing will be rejected. On the other hand, there are alot of bots who take place in both competitions. This has an influence on the meleebattle generation.

Example: Bot A registers for melee and single competition. The server sends from now all priority pairings for this bot. Now, everytime the server sends a priority pairing for A and B (aswell registered for both - melee/single ) it comes to a meleebattle generation against the whole meleefield. Despite the fact that there are alot of bots registered for both competitions it is almost impossible for bot A to get ever a battle against his own class only, atleast until the single competition pairings are finished.

With this in mind you can see the melee compatition as one big competition only. Bots who are registered for melee only have a slight advantage over her classmates :) because they get more class specific battles if they reach the BATTLESPERBOT property.

Maybe someone can recheck this and if it works like this, maybe we can discuss how we could give the melee rumble a makeover.

Take care

Wompi18:24, 18 March 2012
 

Getting this error when I try to access any of the rankings: ERROR: connection failed to server localhost user rumbleuser-darkcanuck (mysql error: Access denied for user 'rumbleuser-darkcanuck'@'localhost' (using password: YES)).

Voidious16:16, 7 December 2011

Sorry about that -- there was an unplanned outage earlier today. Service was back to normal around 10:30 EST.

Darkcanuck19:04, 7 December 2011
 

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