Talk:RoboRumble

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

Subpages

Should we replace ALL of the subpages? or just the 'important' ones? -- Starrynte 22:16, 17 November 2007 (UTC)

Name

Since the new wiki supports symbols in page names, should we put this page at RoboRumble@Home instead of RoboRumble? We already have a redirect from that page to this one... --AaronR 23:34, 17 November 2007 (UTC)

I second this change. » Nat | Talk » 02:30, 28 April 2009 (UTC)

RR seems to be down

Roborumble is returning 503 Unavailable for all pages today. Not sure why. -- Synapse 03:07, 19 September 2008 (UTC)

Are you sure? Both rumble.fervir.com and ABC's work for me. -- KetsuNfwu 03:33, 19 September 2008 (UTC)

I fail. I meant Robocode Repository. -- Synapse 05:44, 19 September 2008 (UTC)

Not a big surprise there. =P -- KetsuNfwu 13:21, 19 September 2008 (UTC)

Hi! What the heck happened to RR@H again? The main roborumble has only ~60 bots again... Otherwise, I uploaded Pugio 1.2 1 week ago and has only 120 battles in nanoRumble. Situation is the same in Darcanuck's page, too. Nobody is contributing?--HUNRobar 12:30, 11 October 2008 (UTC)

Both ABC's server and DarkCanuck's server have no full pairings yet. Once the megabots have full pairings, the minirumble will get filled completely and as last the micro- and nano-rumble. Be patient, but it probably requires a few weeks before all nanobots have 1000 battles. Remember, 640 * 640 bots means a lot of battles! Pulsar's server has another issue. I don't know what happened, but I still run (repair)battles there. --GrubbmGait 13:14, 11 October 2008 (UTC)

I realised that in Darcanuck's server the older versions of bots are still in game. I think the competitors there should be cleaned up. For example, I don't want to generate battles for Pugio 1.0 when I wait for the results of 1.2. --HUNRobar 14:57, 11 October 2008 (UTC)

That's a temporary thing -- I'm uploading a huge amount of data from ABC's server which includes old participants. There's a big performance hit to activating/retiring participants repeatedly, so for now everyone's in the rankings until I get caught up. But don't worry, no rumble clients will actually run these bots. They'll use only the version from the participants list. In a few days you should see the old bots disappear from the rankings. --Darkcanuck 15:03, 11 October 2008 (UTC)

Whoops edit conflict, accidentally overwrote Darkcanuck's reply with this: "What versions get battles doesn't depend on the server, it depends on the participants list that clients are configured to (which should be the old wiki's one, the one here has not been synced for a long time). The server would have nothing to do with that so you shouldn't be generating battles for Pugio 1.0 unless your client is misconfigured I believe." Anyways Darkcanuck's reply clearly explains why there are currently old versions listed :) --Rednaxela 15:10, 11 October 2008 (UTC)

Ok, thanks but I'm very excited about the results of Pugio 1.2. :)--HUNRobar 17:40, 11 October 2008 (UTC)

Why can't I access ABC's server? My connection get timeout before it finished loading! -Nat 12:42, 6 January 2009 (UTC)

Lynch the Multi-Threaders!

A thought just occurred to me. I have never liked the fact that robots could be threaded. Why?

1. On a single-core (non-hyperthreaded) machine it cannot help the bot without hurting the opponent. Either a) all computation is done on one CPU during your turn, in which case you could have done the same computation with less overhead without the threads, or b) you do computation past your turn, eating up CPU cycles from your opponent.
2. On a multi-core (or hyperthreaded) machine, it violates the idea that all bots are equal except for their AI. You suddenly get 2 CPU's in your robot, essentially.

This is a reality we have had to live with, because that's the way robocode is designed. HOWEVER - it just occurred to me that we could enforce a rule saying that no multi-threaded bot is allowed in the rumble! Which I hereby propose. Besides being unfair to the bot's opponent, acting like a virus stealing CPU, it steals CPU from bots in OTHER battles now-a-days when more than one rumble client executes at a time on multi-core machines! Any bot caught using multiple threads would be immediately removed from the rumble. Does anybody agree? --Simonton 02:47, 23 September 2008 (UTC)

Agreed. It isn't fair on the opposition, and makes it impossible to design a bot within the CPU-constant constraints. --Skilgannon 10:34, 23 September 2008 (UTC)

I either didn't see or forgot about this section. There are already bots that use multiple threads in the rumble: Toad definitely does, possibly X2 (which shares some Toad code), and probably others. Not sure how I feel about removing them at this point, just contributing some facts here... --Voidious 02:20, 7 August 2009 (UTC)

Well, there are java APIs that allow things like only measuring the time used in a particular thread. Robocode could start to use these in order to make this fair, AND as a major bonus it would make using Robocode on a computer with a heavily loaded CPU not cause skipped turns. The issue is... those APIs don't give the same kind of resolution, thus meaning that the only way we do it would be if we calculated something more like "How much CPU time did threads of this bot use in the last 20 ticks?", instead of "How much time did this robot take between the start and end of this turn?" which would make skipped turns behave a bit different. Personally I think that may not be such a bad thing, but I'm not really entirely sure... --Rednaxela 02:51, 7 August 2009 (UTC)

It looks like this » Nat | Talk » 12:53, 7 August 2009 (UTC)

Hm? "ERROR This artifact is not accessible." is what that page gives --Rednaxela 13:11, 7 August 2009 (UTC)

Sorry, I never noticed that this is 'private' tracker... Fnl thought that he needs more precise time and mem.usage detection. I have a comment on some time measuring much like to your "How much CPU time did threads of this bot use in the last 20 ticks?". However, we didn't mention a thread at all. But I believe that Robocode allow Robots to create up to 5 threads, I'll email Fnl this. » Nat | Talk » 13:53, 7 August 2009 (UTC)

The tracker is public now. :-) Basically, I want to measure the CPU usage with the new features in Java 5.0 for measuring the exact CPU per thread. Hence we will (when using the TheadMXBean) know for a fact exactly how much time all threads in a robot is using in total. However, the time interval when measuring using the ThreadMXBean is big compared to what we are used to with the CPU constant currently used in Robocode. So we need a solution that can deal with this issue. I have waited with this improved feature as this will have a big impact on the scores for the robots in the RoboRumble. We have already seen how much difference the getNextVelocity() makes, so imagine the difference when we make change the concept behind the CPU constant. --Fnl 21:07, 7 August 2009 (UTC)

Personally, I'm actually not too worried about the impact of this change. Most bots don't skip many turns at all, and the effects of a few skipped turns are often overstated. As long as the average amount of CPU allowed per tick is still similar, I can't imagine it affecting scores too much. I suppose it might have a big impact on bots that abuse the currently untracked multi-threading, but I think we can all agree that they're sort of abusing the system right now, anyway. Of course, I'd be happy to run extensive tests, too. =) --Voidious 21:55, 7 August 2009 (UTC)

I'm agreement with Voidious on this. I doubt there would be any problems caused by this so long as the correct amount of time was chosen. I would say though, that I think that this feature should be targeted at a 1.7.1.5 release, for the same reason that it's generally considered bad practice to change both a bot's movement and gun in the same rumble iteration, haha. As a side note, I wonder if while we improve the measurement method to not be affected by other things on the system, that maybe we should also improve the cpu constant calculation. For one, it should use the same ThreadMXBean methods to be accurate, but also I wonder if we could have a more realistic benchmark of what a typical bot actually does with it's time. I propose we include a small suite of some of the things a more cpu intensive bot does in order to create a more representative benchmark. I propose coding a small suite consisting of something like the following: 1) KD-Tree, 2) Nanobot-style pattern matching, 3) Array operations (searching for peak, addition of a gaussian curve to an array, multidimensional array access), 4) 'Play-It-Forward' simulation, 5) GF calculation (aka simple trig). I think I'll begin a page for comments on and code for an improved benchmark --Rednaxela 00:00, 8 August 2009 (UTC)

1.7.1.5? It was there for about eight months. I think maybe 1.8 or so... » Nat | Talk » 06:10, 8 August 2009 (UTC)

What Now?

How can I submit the new versions of DrussGT and Cunobelin? Has anybody heard any news on the old wiki? Will it be recovered? Is it gone forever? --Skilgannon 15:47, 8 December 2008 (UTC)

Well on November 30th I emailed PEZ and got a reply that it's an ugly error and that he'd look into it. I haven't heard anything since but I guess I might email PEZ again. I certainly hope it won't be gone forever as I'd at least like to have a read-only version due to how much great stuff there is there that's unmigrated. --Rednaxela 16:12, 8 December 2008 (UTC)

I really hope the old wiki content still lives on. In the meantime we could agree to use this wiki's list for my server. I don't have time this week to make the proposed participant list changes, but I could lock out add/removes for all but a few select clients to make sure we all use the same list? --Darkcanuck 18:28, 8 December 2008 (UTC)

Well, the old wiki is back! I do wonder though, should we switch to using this wiki's participants list anyway? or should that wait till some other day in the future? --Rednaxela 18:17, 9 December 2008 (UTC)

I'd like to keep using the old wiki at least until I can code up something to validate participants on the server side. Then it would be easier to switch and not have to worry about some clients using the wrong list. --Darkcanuck 05:39, 10 December 2008 (UTC)

Random question: How much do you think the local client would speed up if I compiled it natively? Right now, we haev a bit of a bottleneck figuring out battles andif we could speed it up by a factor or 3 or so, why not? --Miked0801 21:52, 25 May 2009 (UTC)

Nanos get little love when things get busy

I've been waiting for nearly 4 days for my latest bot to get to 2k battles against nanos, and I'm probably gonna have to wait 3 more for it to happen. Why? Nanos, after they get to their 1 battle per bot limit, are the last bots to be updated under the current system. I understand why the system was done this way, but is there anyway we can add a time component to the battle chooser to make sure that when things heat up in the rumble, nanos get some love as well? --Miked0801 20:47, 19 June 2009 (UTC)

I hear ya. Even in Mega-land, it can take a while to get to 2k battles, and I don't really trust a rating until it does (even with all pairings). There are some RR client options you could try, like excluding bots or running NanoRumble only, but the latter will just do random battles, I think. A couple of nice client side options, imo, would be mini/micro/nano while still honoring pairing priority, and ignoring pairings while running bots with under NUMBATTLES (in all applicable rumbles). I'm definitely in favor of RR contributors having control over what battles they want to run... --Voidious 22:48, 19 June 2009 (UTC)

Nanos get way more than their fair share of processing time. By a time a nano reaches 2000 battles in its own class, it has typically reached 5000+ battles in the main rumble. Few, if any, megabots have yet to reach that level. Not only is it unfair to folks releasing larger bots, it also takes away cpu time from other nanos. So should we abolish nanos? Of course not!

I'd vote for changing the client's battle selection such that when a new bot reaches full pairings, the remainder of its 2000 battles are fought against opponents in its own size class. Those battles will still count for the higher classes, so a nano would really only need 2000 battles overall. This would mean faster results for nanos and more cpu time for everyone else, regardless of size. --Darkcanuck 03:19, 20 June 2009 (UTC)

I second Darkcanuck's suggestion, as it seems most fair to me. :) --Rednaxela 05:12, 20 June 2009 (UTC)

And yet, some nanos love to beat up on their larger sibling... But yes, when things slow down, nanos do get a ton of extra battles, but to be fair, most nanos run much, much faster than megas so the hit isn't that bad. My main concern was waiting at the back of a line of never ending micro/mega selections. Impatients and such. If we're going to change things to minimize waits, then first completing pairings, then 2k in class, then low priority updates across other classes would be awesome. Unlike melee, just 2 or 3 battles with a mega are usually sufficient to get a strong idea of where things stand. --Miked0801 09:10, 20 June 2009 (UTC)

You can also set RUNONLY=NANO, but alas then no priority battles are fought, just random ones. And I set the battlecount to 1000, so nanos will get their battles earlier. --GrubbmGait 10:51, 20 June 2009 (UTC)

• setting RUNONLY=NANO is not a good idea. The results only count for nano, so is not counted at micro/mini/mega. Setting the battlecount lower does pay off however, except when the bigger rumbles are flooded with new versions. --GrubbmGait 11:00, 20 June 2009 (UTC)

It would be awesome if roborumble could execute smart battles with runonly parameters. For example, run prioritary battles but only among nanos. I don't think it would be such a difficult developement. --HUNRobar 14:33, 20 June 2009 (UTC)

I think the RUNONLY setting needs to be fixed -- as GrubbmGait pointed out, the battles don't get uploaded to the bigger size classes, which they should. I might put together a patch for this, but first I have some wave surfing to iron out... --Darkcanuck 17:41, 20 June 2009 (UTC)

About battlecount, one habit I have, is constantly making my battlecount set to just a little above the lowest value in the rumble. That seems to have nice results sometimes. --Rednaxela 16:03, 20 June 2009 (UTC)

All right, I think I've figured out how to implement the change I suggested, plus fix the RUNONLY problem. If enough people are ok with this, I'll put together a patched 1.6.1.4 client with the changes and send the patches to Fnl for future releases too. --Darkcanuck 18:21, 21 June 2009 (UTC)

Quick question: Would this only affect the 1v1 pairing order? I definitely support it there, but making your suggested change in Melee pairings would have a major impact on some bots' scores... And thanks as always for your RoboRumble efforts! --Voidious 19:33, 21 June 2009 (UTC)

Only at first. The game already does all class battles for roughly 50% of the numbers in nano now. That's why DustBunny has been slowly rising in APS - he does worse in nano only. --Miked0801 20:42, 21 June 2009 (UTC)

Well, right now a NanoBot gets 2,000 battles against the whole field, then a bunch against MiniBots and below, then MicroBots and below, then NanoBots. With this change, it would get some amount of battles against the whole field, then all NanoBot-only battles. Depending on the bot, I think it could have an impact. Then again, that's a quirky aspect of MeleeRumble that's tough to really regulate, anyway, so maybe it's not worth worrying about. --Voidious 21:51, 21 June 2009 (UTC)

Ah, good point, I hadn't considered melee. It does use a different routine for preparing battles though, so it's possible to patch 1v1 without affecting melee. Looking at the melee routine, it does create an interesting mix of battles -- I didn't realize that there were all-nano matchups. That must skew the scores depending on the ratio of battles a nano gets with mixed sizes versus all-nano? --Darkcanuck 02:15, 22 June 2009 (UTC)

I don't think it is a bug, i think it was made on purpose the way it is. Alas I don't remember the reason . . . --GrubbmGait 21:03, 21 June 2009 (UTC)

Mobile Devices

Who here things I'm crazy to try running roborumble on my Ipod Touch? :) --Rednaxela 02:01, 7 August 2009 (UTC)

• Definitely crazy. --Simonton

I think you're crazy, but only because the iPhone OS doesn't have Java. =) I actually just looked into this the other day, lol. Was there some tech you were looking at to make it work? --Voidious 02:03, 7 August 2009 (UTC)

Actually, when you don't limit yourself to the app store, there is a port of JamVM w/ GNU Classpath. There's no JIT so it won't be fast... but it'll run.. or... almost:

Iteration number 0
Downloading rating files ...
Downloading participants list ...
Downloading missing bots ...
Removing old participants from server ...
Preparing battles list ... Using smart battles is true
Prioritary battles file not found ...  
java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
   at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:607)
   at robocode.security.RobocodeSecurityManager.<init>(Unknown Source)
   at robocode.manager.RobocodeManager.initSecurity(Unknown Source)
   at robocode.control.RobocodeEngine.init(Unknown Source)
   at robocode.control.RobocodeEngine.<init>(Unknown Source)
   at roborumble.battlesengine.BattlesRunner.initialize(Unknown Source)
   at roborumble.battlesengine.BattlesRunner.<init>(Unknown Source)
   at roborumble.RoboRumbleAtHome.main(Unknown Source)
Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer') in gnu.classpath.boot.library.path and java.library.path
   at java.lang.Runtime.loadLibrary(Runtime.java:763)
   at java.lang.System.loadLibrary(System.java:662)
   at gnu.java.awt.peer.gtk.GtkToolkit.<clinit>(GtkToolkit.java:173)
   at java.lang.VMClass.forName(Native Method)
   at java.lang.Class.forName(Class.java:233)
   at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583)
   ...7 more

It seems that both:

1. RobocodeSecurityManager is foolish and tries to query the default graphics toolkit even if run from the command line
2. The install of GNU Classpath is foolish and thinks it has GTK avaliable when it's running in command line only

Were it not for one or the other of those issues, it'd probably run just fine... Now can i fix this I wonder... --Rednaxela 02:13, 7 August 2009 (UTC)

Wow, that would be really cool. But I'm a wuss and I'm afraid to jailbreak and void my iPhone's AppleCare; I was thinking more from the perspective of writing an iPhone app myself that could do it. Good luck, though, I'm curious to hear your results! --Voidious 02:17, 7 August 2009 (UTC)

Aha! I got around that stupid issue! I just had to pass the VM -Djava.awt.headless=true... When you see rumble uploads with a user of "RednaxelaIPod", that'll be it :) --Rednaxela 02:32, 7 August 2009 (UTC)

Ouchie, building the robot database this first time sure isn't fast... --Rednaxela 02:39, 7 August 2009 (UTC)

Sadly, while it mostly ran, it didn't quite work:

java.lang.ArrayIndexOutOfBoundsException: 1
   at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:27
5)
   at java.util.AbstractList$1.next(AbstractList.java:354)
   at robocode.battle.Battle.updateBullets(Unknown Source)
   at robocode.battle.Battle.runTurn(Unknown Source)
   at robocode.battle.Battle.runRound(Unknown Source)
   at robocode.battle.Battle.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:743)

...

java.lang.NullPointerException
   at robocode.battle.Battle.updateBullets(Unknown Source)
   at robocode.battle.Battle.runTurn(Unknown Source)
   at robocode.battle.Battle.runRound(Unknown Source)
   at robocode.battle.Battle.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:743)

...

Exception in thread "sul.Pinkbot 1.1" java.lang.NullPointerException
   at robocode.peer.RobotPeer.setEnergy(Unknown Source)
   at robocode.peer.RobotPeer.setEnergy(Unknown Source)
   at robocode.peer.RobotPeer.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:743)
Exception in thread "serenity.moonlightBat 1.17" java.lang.NullPointerException
   at robocode.peer.RobotPeer.setEnergy(Unknown Source)
   at robocode.peer.RobotPeer.setEnergy(Unknown Source)
   at robocode.peer.RobotPeer.run(Unknown Source)
   at java.lang.Thread.run(Thread.java:743)

Though if a workaround can be found for those issues (most likely bugs in the version of GNU Classpath in question. May not apply to newer versions, or a patched robocode might be able to work around it), it may work. Not sure that'll be possible though. Oh well... --Rednaxela 03:54, 7 August 2009 (UTC)

Rumble Computers

I'm curious, what kind of computers are people using for roborumble? Voidious and Simonton seem to really have some nice ones I think. Personally the computers I have avaliable to run rumble consist of:

• Intel Core 2 Duo T5300 (1.73GHz), 2GB ram, laptop, usually avaliable
• AMD Athlon XP 2000+, 512MB ram, often avaliable
• AMD Athlon XP 2400+, 1GB ram, rarely avaliable

I would also have my wimpy iPod were it not for one little bug preventing successful running of bots in the VM installed there. Sometimes... I'm really tempted to get a brand new shiney quad core monster for the sole purpose of storing backups, and running RoboRumble/Research :) --Rednaxela 03:41, 16 August 2009 (UTC)

I have:

• MacBook 2.0 GHz Core Duo, 2 GB RAM, and I can run two clients on it safely. It's actually 3+ years old, but it holds up pretty well.
• AMD 2000+, 768MB RAM (Ubuntu 8.10), which I've been running a rumble client on almost 24/7 for a while now.
• Just yesterday, I ordered a MacBook Pro 2.8 GHz Core 2 Duo with 4 GB RAM. So that will more than double my total rumble power, I think. =)

I wonder what Corbos had, I couldn't have kept up with him if I tried when he was rumbling recently. I've also been tempted many times to spring for a quad core Linux box just for Robocode, but so far I've been able to resist... (mmm, quad core...) --Voidious 03:55, 16 August 2009 (UTC)

Haha... I unfortuantely can't run two clients on my Core 2 Duo laptop... the CPU just plain gets too hot. What I really want to see though, is MXThreadBean timing in a new robocode version, which would make it safe to enable the option to allow robots to run concurrently, when in rumble... Then one could take advantage of a 8 beast when running melee rumble with only one client... --Rednaxela 04:29, 16 August 2009 (UTC)

My client runs on an old laptop -- all it does is run roborumble + meleerumble:

• Intel Pentium M w/512MB ram, 100% available

Occasionally I press my main machine (MacBook Pro, Core 2 Duo, 3GB) into service, but mostly I need it for work or running RoboResearch (that's what it's doing right now, in fact). It's also where the development rumble server lives, so this client is normally pointed at that anyway. Running both I was able to keep ahead of GrubbmGait for awhile until Voidious et al made our upload counts look puny by comparison. --Darkcanuck 04:26, 16 August 2009 (UTC)

My client is a 2.66 Mhz Pentium4 (single-core) with 1GB. There was a time that I ran roborumble on a 400Mhz laptop with 128Mb using robocode 1.0.7. Btw, Darkcanuck, are you able to remove (or rename) those somewhat embarrasing contributions of GrubbmGait_15x and GrubbmGait_17x at the very low bottom. --GrubbmGait 11:08, 16 August 2009 (UTC)

Wow, 2.66 MHz!!?! :-D J/k. --Voidious 15:04, 16 August 2009 (UTC)

When I used to run it, I ran it on my Intel Centrino 2 P8400 2.26GHz with 4GB of RAM (but with 32bits OS it only sees 3GB) laptop, which I used for other works too. The time I run I only use FF to surf the web, but now I need to use Photoshop, Eclipse, LAMP and one virtual machine almost all the time so it doesn't available anymore. » Nat | Talk » 11:31, 16 August 2009 (UTC)

I run my client in a Pentiun Dual Core 1.86 GHz, and I usualy run 2 clients, but right now I'm using it to test several new versions of my robot, so the rumble has to wait...--Navajo 14:36, 16 August 2009 (UTC)

Lower Rank Limit?

Wouldn't it be reasonable to remove bots that gets negative ELO Rating (i.e elvbot.ElverionBot(ELO: -191.0) & ry.Worst 1.0 (ELO: -365.3) ) ? They almost always score 0% and uses cpu-time while they contribute with near to nothing.

Could someone please explain me what the difference between the normal client (found in robocode/robocode.bat ) and the Roborumble Superpack (found at http://robowiki.net/wiki/RoboRumble/Starting_With_RoboRumble#With_the_Roborumble_Superpack ) are. Is the second one better ,faster? Everytime I try to download the superpack from the wiki I get a Dropbox 404 error ,so I downloaded it somewhere else, but after I unzipped it , I only found roborumble.sh and twinduel.sh. I have some Linux distrutions installed on my system, but I almost never use them. So where can I get a superpack for Windows? Thank you.

You can just use a normal Robocode install, then copy all of the bots from [1] into the robots directory.

I just did a head-count on the number of robots in each rumble (of only that weight class).

Which comes to this: 458 megabots 132 minibots 170 microbots 229 nanobots

I found that interesting, that there we're fewer mini and microbots then nanobots. Maybe a microbot (>250 + <750) only or minibot only (>750 + <1500) rumble would make those robots more interesting to develop.

Thats interesting indeed, the 'Do the best you can with the least possible code' paradigm is challenging to a lot of people. My vote for an extra rumble would go to 'ExtendsRobot', although I know the winner will be kawigi.robot.Girl. I am not sure if such a rumble is possible, because I don't know if it can be (automatically) detected which base class is used.

It could use the honor system, like the twinduelrumble.

Yeah, that should be fine. And LiteRumble makes it super easy to start new rumbles. I'd also be a little interested in a perceptual rumble. I think RetroGirl would have a good chance at #1.

I second the motion of a perceptual rumble. I find perceptual bots interesting, and I would like to make a good one someday.

I'm pretty sure that of all the current perceptual bots, RetroGirl would be a definite king.

I noticed this a while ago.

I don't think that it's a very big deal. After all, the minirumble is for all robots that have a codesize of less than 1500 bytes, the microrumble is for all robots with a codesize less than 750 bytes, and the nanorumble is for all robots with a codesize less than 250 bytes. So, nanos and micros fit into the minirumble because, well, they are minis in the sense that they are all under 1500 bytes.

To say that minis and micros could could have their own exclusive rumbles would require different definitions of the weight classes. And, if you're going to all that trouble, you might consider more consistent brackets, like 250, 500, 1000, 2000.

While technically true they fit multiple ranges, I don't really consider nanobots to be micro or minibots, even thought they are. In my mind they are separate.

I only mention possible minibot and microbot only categories because setting them up would be relatively easy and painless. We already have all the battles for those robots done, they just need to be arranged differently. This would hopefully stimulate more interest in microbot and minibot development.

As for other rumbles. I think they would need enough interest to really justify a rumble for them. Though a Robot only one is probably a bit overdue.

It is indeed an interesting observation. Especially since I'm used to thinking of NanoBots as the fewest, since they're always calculated as a strict subset.

But I'm not sure I see the benefit of excluding smaller bots from the bigger rumbles? How would it stimulate interest? It kind of makes sense Nanos and Megas would be the most popular. If squeezing bots down to tiny sizes interests you, NanoBots are kind of the optimal version of that. If you're not, you might stick to MegaBots. I'm not sure why it's worth Wallaby losing his MiniMeleeRumble title, or LittleBlackBook not being allowed to take pride in crushing most MicroBots.

Precisely. I don't see how it would be a more interesting rumble if GlowBlowMelee wasn't beaten by a bot literally half its size.

I wasn't saying removing/replacing the current rumbles, that would be silly. I apologize if that is how it sounded.

Ah, gotcha. I'm still not sure it would change much... But I do think any kind of new competition can be a great/fun way to spur some interest. The Twin Duel was a ton of fun when a few people were actively contributing. But it's hard to gain traction, maybe since anyone who's actively Robocoding is usually already busy with a bot in one of the existing formats. And coding something for a new rule set is just harder.

Where can i find the rules for roborumble?

Or aren't there any limitation what my robot is allowed todo? (e.g. reflection, sockets, file-operations, etc.)

sorry if this is a repost. i'm new in this forum

Welcome! I don't think there are any rules like what you're looking for, except for what is allowed by Robocode itself. Reflection, network access, and general filesystem access are all disabled by Robocode's security manager, and your CPU time is limited to a few milliseconds per turn. You do have a small amount of controlled disk access - see AdvancedRobot.getDataFile. As for CPU time, if you use more than the amount Robocode calibrated for your system, your bot will skip some turns to make up for it.

Hope that helps and let us know if you still have questions.

But as for rules, anything in the spirit of the game is generally okay. That means anything that strictly uses the robocode API within the game. Anything that tries to attack the robot from outside the game is disabled, forbidden, or frowned upon. Examples of that are things like killing the enemy robot thread, or altering/reading internal robocode classes, etc.

Ah, yeah, I think the only "unwritten rule" is that people will get mad if you use multiple threads. This is an exploitable aspect of Robocode, since Robocode only tracks CPU time in the main thread, and you could theoretically steal CPU power from the opponent in your alternate threads.

In Twin Duel, disk access is disallowed despite the engine allowing it. It is written in the page there.

And the ban on multiple threads is written in a discussion page somewhere I can´t find anymore.

Those 2 are the only house rules not enforced by the engine that I can remember.

There is also a limit of 512MB heap space. You can see it in the client´s initialization scripts.

There was a great discussion on the old-wiki that started-off talking about multi-threading, but quickly digressed into deep philosophy.

Yeah, multiple threads are 'frowned upon' but not disallowed. Some robots use them (such as pear).

thanks for your replys! :)

what works in robocode will work in roborumble right?

Pretty much. If it works on stock Robocode, it should work in the rumble.

how many robots CAN i submit to roborumble?! i know it should be just 1

It depends how different they are. If it's just an improvement on an old one, then rather remove the old one, but if it's entirely new and different then it's fine keeping the old one in. It's usually better to give it a new name as well, if you're going to do that.

Yeah, submit as many as you want, but replace previous versions. If you add DrussGT 2.9.1, remove DrussGT 2.9.0 - you can revert if 2.9.1 is worse. And it's ok to have multiple bots that share some code, even though that's kind of like "different versions".

There's no guideline that it "should be just 1". I have 5, Kawigi has 15, and Stelokim has 20.

okay thanks guys :-) i hope i am able to upload one soon... i'm not very into robocode yet but i'm making progress

Just noticed Darkcanuck's RoboRumble server is down. Anyone know how long it's been down? Without any response from him in so long, I think it's probably the right time to transition to a new server, either a LiteRumble instance or setting up Darkcanuck's code on a new server.

Skilgannon, is it worth even trying to just transition our full load to your LiteRumble instance? Or would we need to upgrade to/setup a new one in a paid tier first? I don't think robowiki.net could handle a copy of Darkcanuck's server running but I could setup a new server somewhere if that's what we want. The query API that powers @roborumble is the thing I'd miss most. Though I could hack it to just parse LiteRumble pages (the first implementation did that on Darkcanuck's).

Country flags is what I'd miss most. Is the discussion page complete?

What do you mean by "complete"? If you mean all the requests have been filled on Darkcanuck's server, the answer is no. And also no if you mean any kind of automated flag system like the participants list.

By complete I mean if all flags used in Darkcanuck's server are registered as requests in the discussion page.

It would be "incomplete" if someone asked for a flag request without using the discussion page.

Ah, ok. I think he started off with all the same flags as the old server, so some of us never requested one, and I remember one unfulfilled request on his talk page. I think the list Chase posted + any outstanding requests on that page would be sufficient to get started though.

It will be really easy for me to set up another query API, I could even just make it an argument that gets added to the regular page request and it returns in JSON or something similar.

I think we see how it handles, and if it is constantly hitting the quota. If it is, upgrading should let it expand pretty much as far as we want, although the minimum for paid tier is $2.10/week.

A lot of times, when I stop my rumble client there will be several battles completed that just stay on my machine until the next time I start my rumble client. I've always thought this was fine in the past, but if one of those battles is for a robot who is retired before the next time I start my client, it seems like when it is uploaded the retired robot reappears in the rankings. Should I be trying to avoid this? And if so, how do I clean out the stored battles before starting the rumble client?

It wouldn't hurt. I personally try and shut down my client after it has finished uploading but before the first battle has finished. So there won't be a to upload log.

I always clear out roborumble/files/* and roborumble/temp/* before starting up my client, that clears out any cached results from last time. Would be nice (and not hard) to protect against that case somehow though.

I know I can't compete with giant clusters like bwbaugh, and it's not that scientific since it depends on what bots are submitted, but in case anyone's curious.. In September, I ran my i7 with 4 clients all month to see what I could max out at for battles contributed. Best I saw in "last 30 days" was 1,269,511.

I know my client spends more time on the upload than running battles, not sure if it's due to the extra latency from South Africa or just Darkcanuck's delays. That slow upload was one of my motivations for writing Literumble.

I built a custom results uploader which uploads battle results in parallel. Up to 15 simultaneous connections (configurable) are made to the server to work around latency issues. It makes a huge difference in melee, and also helps in 1v1.

As a side effect, priority battles are downloaded in parallel, and they are grouped together before writing them in the priority battles file.

If anyone is interested I can put it in the tools page.

I think it would be better to just allow both the server and the client to upload them in bulk, rather then one at a time.

It would be a lot more efficient to have batch uploads, but the work around above at least keeps backward compatibility.

Keep in mind that the delays in uploading to Darkcanuck's server were added intentionally because the server couldn't handle the load otherwise. So it might not be a great idea to circumvent them. But I do agree that they take a lot of time and it would be great to have a system with faster up loads.

On that note, maybe we should finally accept that Darkcanuck's server is "orphaned" and we need to setup a new one where we can update country flags / give people API access and so forth.

I think the biggest problem with Darkcanuck´s server right now is the admin, Darkcanuck, not being around. If the server suddenly goes offline for any reason, no one will be there to look after it.

That might be an idea, and while we are at it we can add support for bulk transfers at least to the server. Perhaps a modified url for bulk download of robot pairings as well. This should cut off considerable time required to run the rumble, as sometimes the uploading can take as long as just running the battles.

My feelings are split on if we should use the normal rumble or the lite rumble codebase. I like the idea behind the lite rumble, but python leaves much to be desired in the area of performance.

I would prefer Java EE, but there are a lot fewer clouds which support it.

I have never really used Java EE. But for web applications I still think that languages like PHP are best.

Java EE has features to ease web development while still allowing you to fallback to plain Java with all its features and libraries when needed.

But there are a lot more clouds supporting PHP than Java EE.

Google App Engine (where I've got LiteRumble) supports a subset of Java EE.

I'm not sure we really need any special casing of bulk uploads. The uploads already fly with LiteRumble with whatever he's doing now.

I'm also torn, as Darkcanuck's server has a pretty robust feature set and is time tested with the huge load of a real rumble server. But I don't think it would be hard for LiteRumble to gain the new stuff we want and I love how lean and flexible it is. It's also a code base someone active is familiar with. And I'm happy to pitch in for resources if we need anything to support "rumble scale".

Bulk uploads would be particularly nice for melee, because it would mean I wouldn't have to do as many database writes. But as far as upload speeds go, Literumble is way, way, way faster than Darkcanuck's server. Looking in his code, he has a 1 second wait hardcoded into each pairing upload, which is kind of ridiculous. That means that for each melee battle it takes a minute to upload once you count processing and connection overheads.

Finally a supporter!

I'll look into what would need to be done to do it later. I assume very little, since most of the system is already in place for it. But for reverse compatibility I will also see about adding an option to the roborumble configuration as well.

If you are going to change the protocol, a nice improvement would be to upload melee battle participants in a single group, so the server can keep track of full melee battles instead of pairings.

I am not sure. I would need a deeper look at the format of the results files, both for the normal rumble and for melee rumble.

The roborumble library is a bit of a mess. It also likes to use File IO. It writes and reads things a lot. I now want to fix that, but I know better then to fiddle with things beyond my (current) understanding.

It seems to upload each result individually. It then checks for an OK being returned and updates battlesnum. After it is done uploading all the results, it then sends this battlesnum to the server to update ratings. This seems like it would be better done all on the server when you upload the results.

So unless we want to get rid of that weird mechanic, I need to get the server to return a string of OK/NOT to the client so I can update this battlesnum.

Otherwise it is a simple matter of slightly restructuring the way it uploads battles.

Isn't the server which sends battlesnum back to the client? Which is deprecated with the improved priority battles list we have now.

How I think a good rumble protocol would work:

- Client requests and downloads the participants list from the wiki server.

- Client uploads participants list to rating server.

- Client uploads number of battles per iteration and downloads priority battles list from rating server. (can be done in the same request which uploads participants)

- Client downloads missing participants.

Run battles. If there is any error downloading priority battles list, fallback to random battle generation.

- Client uploads all battle results at once, keeping data structure as close as possible to how it is returned from the API. Server returns an OK or ERROR after the upload. If an ERROR occurs, keep the results for next iteration.

2 main differences are bulk uploads in the end and priority battles download in the beginning.

I am fully in favor of setting up a new rumble server, though I am fairly new to programming so I doubt I would be able to help much. Perhaps, if we are starting from scratch, we could go ahead with the Roborumble.org project that has been talked about for many years.

Would the entire ~1000 bot participants list move over to the new server, or would we start over fresh with active participants and a stable of "classic" bots that have historical/otherwise significance?

The answer to that question may decide who ends up with the #1 spot on the new rumble server. ;)

If it's just a matter of copying, I see no reason not to move the entire list. But, if we change it so that every bot has to be added individually, I doubt many people would be volunteering to move 1000+ bots. :)

I think it´s better to keep them all. For me, as long as the server can handle, the more participants the better.

If you want a smaller rumble, we can create another division.

About who ends up #1 being affected by others below it, we will end up ressurrecting the king maker discussion started a long time ago.

The "should we make another rumble" or "should we restart the rumble" was something that has been tossed around for years. Generally the answers have been no. Mostly since there was no very good reason to do so.

Perhaps when we get obstacles into the game, we can get a new rumble going with a special arena, or urban combat robots.

About obstacles in the game. There is a mod called Virtual Combat which is exactly that.

Also BerryBots has obstacles in a very robust / configurable fashion, as opposed to tacked onto a game not designed for it. =)

(I think you're both on Windows, though, and it's not on Windows yet. Very soon though. I bought Windows 8 and got BerryBots running on it, but there's some more stuff to be done before releasing.)

Just make sure it is usable on Windows 7. That is, don't use anything that is Windows 8 only.

Pretty confident that won't be a problem. I'm using MinGW, and the graphics libraries are wxWidgets and SFML, both of which are cross-platform and I'm compiling them from source too. But I'm not going out and buying any more friggin' copies of Windows =), so hopefully I can get someone to test it out.

I have Windows 7 and I am very excited about trying BerryBots.

Just out of curiosity, is 8 really as bad as they say?

I haven't really used Windows since XP, and I haven't played with 8 much yet. So far my impression is mainly that the UI has some nice little things, isn't much better or worse than XP, but definitely a lot weirder. I like that they're at least trying something different but I expected it to like it a little more than I do.

I'm turned off by Windows 8, myself. I like Windows 7, but I don't use it. I'm still using XP, primarily because copies of Windows are always about twice as expensive as I am willing to pay. I'm kind of hoping once Windows 8 is going full steam, that copies of Windows 7 might get discounted to a price I am actually willing to play.

You know what -- I make decent pay at my job, but I'm still not willing to pay what Microsoft wants for copies of Windows. I have to think that very very few people actually buy copies of Windows, if I'm not willing to. I would guess most people just use whatever comes on whatever machine they buy. I build my own computers, so that is not really an option for me. If I could get games to run under Linux, I would probably switch. Games are the only thing really holding me to Windows at this point.

Back a little closer to on topic, if there were to be a new Rumble, I would want the full list of robots in it. I probably would not participate in a combat with obstacles, just due to lack of spare time for play. If I had more time, I would get into the existing melee first.

Prompted by some interest from Chase, I posted the current in-development version of BerryBots, compiled for Windows (on Windows 8/MinGW): berrybots_wintest1.zip (~20 MB). You should be able to just unzip and run berrybots.bat. If anyone wants to test it out, I'd love to hear if/how well it works on other Windows's - I haven't tested anywhere beyond my own Windows 8 install.

One thing I'd be curious to hear is if tab navigation in the dialogs works - it's not working for me on Win8, but does on other platforms. Trying to figure out if I need to hand-code that for Windows.

I'm getting an error when I try to run on Win7: "The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem".

Ok, much thanks for testing it out. Chase got something similar, so I guess I have some research to do. Maybe it is depending on having MinGW installed or something.

I'm able to duplicate this by removing MinGW stuff from my path. I just need to straighten out static linking and/or including the .dll's for a couple things. Hope to have another test version posted soon for anyone still willing to help.

Well, the simplest solution is apparently to just include the MinGW DLL's I depend on. I've put them here (just drop them in berrybots/), and the updated zip with them is here.

I'd rather not be distributing all these DLLs so I'm going to look into statically linking against them. But since I'm also dynamically linking to wxWidgets, which links to these, I have to switch to statically linking against that first. I guess there's also debate about how dynamic vs static vs any linking at all relates to the GPL terms, but I'm already using a more permissive license than that, anyway.

If nothing else, this whole "build a cross-platform / native desktop GUI app" has been a pretty educational experience. :-)

That is understandable. In that case it should be fine. As long as you are not using the Windows 8 only apis (which do exist!). But from the soudns of it, you're not. Since I don't think MinGW supports any of that yet.

In december I ran my i7 with one client continuously, it delivered 280k battles in 31 days. It also depends a bit on the priority battles to do, a new micro usually is faster and delivers more battles than f.e. a new XanderCat. I was proud on my 9000 battles a day, I remember the time when only David Alves could deliver more battles per month.

I can't reach it, and my GTStats just failed so the wiki can't reach it either...

Yep, down for me. I definitely saw some RoboRumble uploads time out in the last day or so, too. Hopefully it comes back, but we can always make an emergency migration to LiteRumble... =)

Down for me too. Just wanted to know against which bots GeomancyBS is better than DrussGT ;-) (and also against who GresSuffurd is better than DrussGT. Out of 970 opponents there should be at least one)

It's back up.

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.

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.

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.

We haven't heard from Darkcanuck in quite a while, so as far as I know we're still at a max of 1.7.3.2 on his server. Skilgannon has been playing with his LiteRumble at literumble.appspot.com, and he's using 1.7.4.x, but I don't think it can handle the load we put on Darkcanuck's. Not sure how long we should wait before considering moving to a new server. We could setup a new instance of Darkcanuck's code elsewhere. (I hope everything's ok with Darkcanuck, just speaking personally.)

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.

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.

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.

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

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.

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.

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.

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.

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!

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.

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

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)

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.

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.

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?

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

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

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.

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.

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?

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.

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

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.

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.

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.

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

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

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. =)

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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)).

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

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.

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)?

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

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.

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).

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.

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.

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).