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)

It's done. I merged GrubbmGait_15x into GrubbmGait_154, and removed the lone battle from GrubbmGait_17x (the upload still shows up, merged into GrubbmGait). --Darkcanuck 17:38, 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. --Rsim 15:37, 16 August 2009 (UTC)

Whoops

Err... sorry my client reactivated some old melee bots due to old data lying around, seems they crave pairings now... plus a large number of recently released melee bots... means sloooow melee right now... --Rednaxela 05:10, 10 September 2009 (UTC)

Iteration

I wonder if this happen to everyone or just me. When I run RoboRumble client, both 1.6.1.4 (which upload to darkcanuck's server) and 1.7.1.4 (which I use to test locally because it is faster), I found that after iteration 80 things got slower. I mean with 1.6.1.4 I can run 100 iteration in 4 hours, then another 4 hours it can run only 50-60 iterations. SO I tend to restart my client every 80 iterations. (and cool my hard disk down a little, it is around 80 degree Celcius when I run it for 150 iterations) Do anyone, especially who run RoboRumble overnight, have similar situation? --Nat Pavasant 03:10, 11 October 2009 (UTC)

I've found that 1.6.1.4 still seems to have some long-term memory leakage actually. Not as bad as older version, but enough that it's still worth not using the ITERATE option actually. --Rednaxela 03:54, 11 October 2009 (UTC)

JVM Crash

After running the RoboRumble client (1.6.1.4) for about 12 hours, my JRE crashed. I have not been able to reproduce the problem, but I thought I'd post about here in the event it has happened to someone before. I've submitted a bug report to Sun and saved the logs [Here]. It may not be relevant, but this happened when evaluating Krabb.sliNk.Garm 0.9u. --Christopher.Hilla 22:06, 7 February 2010 (UTC)

Huh... that's a very peculiar bug. I doubt there's anything more to it other than there being a bug in the JVM though, assuming this isn't something you're able to repeat reliably. --Rednaxela 22:48, 7 February 2010 (UTC)

Contributor's Sum

I started contributing less than 30 days ago, yet my "All time" and Monthly sums don't match. My "All time" sum is much larger than what I've actually contributed. Even though my point tally is sort of like keeping score on "Whose Line Is It Anyway", it's worth mentioning :) --Christopher.Hilla 06:49, 9 February 2010 (UTC)

The monthly and 30-day totals are based on battles, whereas the all-time list is number of uploads. For a 1v1 battle between megas there is only one upload, but for smaller classes there will be one upload per size class (e.g. two nanos will generate 4 uploads). Melee is even more complicated since a full set of pairings for 10 megas will yield 45 uploads, even more if there are smaller bots in the mix. So your all-time uploads should be greater than the sum of the battles you've contributed so far. --Darkcanuck 07:41, 9 February 2010 (UTC)

Thank you for the explanation. --Christopher.Hilla 19:49, 9 February 2010 (UTC)

Incomplete robot list

Hey Darkcanuck, I 've been running a few rumbles..and noticed I am missing a large number of bots " can't file specified file". Any Suggestions? Thx.. oh , I should mention Last night while Running an iteration envolving DR3.06 , Portia and 8 other bots. Something probably on my end screwwing up results for 1 battle. Not sure how, or why, but just one battle. -Jlm0924 20:06, 27 April 2010 (UTC)

DogmanSPE

I just ran a few tests to try and figure out the discrepancy between 1.8.0 and 1.8.2 of DrussGT, and now I can't repeat 1.8.0's results against DogmanSPE. I then decided to try a few rounds against Diamond 1.5.5, and it seems he also isn't living up to the scores he's getting on the rumble against DogmanSPE. The only thing I can think of is that it may be different versions of Robocode, as I'm doing my testing with 1.7.2b2. Any ideas? Maybe Dogman gets smart only at certain times of day? --Skilgannon 15:06, 9 May 2010 (UTC)

Eh, DogmanSPE is a major troublemaker and always has been. It sometimes doesn't crash, but when it does crash it crashes for every subsequent round of the battle. This makes it's results always unpredictable. It doesn't affect overall APS too badly because of the sheer number of bots, but it's probably the single worst offender in the rumble. Issues with DogmanSPE have been pointed out before. Personally, I'm in favor of removing DogmanSPE. --Rednaxela 15:25, 9 May 2010 (UTC)

So am I. Anyone object? --Voidious 17:28, 9 May 2010 (UTC)

Done =) --Skilgannon 19:17, 9 May 2010 (UTC)

LRP

Perhaps we should have a section on what the LRP does. I mean most of use from the old wiki know but... Anyway in the words of Paul,

May seems a stupid question, but, what is the blue line, and the 4 quadrants?
I can guess that on the X axis there is the expected score and on the Y the difference between expected and actual score.
But what the blue line is supposed to mean? -- [[Simonech]]

You are correct on the X axes and Y axes scales - the Blue line is a best-fit straight line through the data. if it has a negative
gradient slopes downhill (left to right) I believe it would indicate that the movement for the bot is stronger than the gun. A
positive gradient would indicate a good gun is being let down by relativley poor movement. -- [[Paul]]

— Chase-san 04:55, 4 July 2010 (UTC)

Rumble use of 1.7.2.1 Beta?

Guys, do you think that Robocode 1.7.2.1 will be good enough to replace the very old 1.6.1.4 for RoboRumble? If not, what must be done? --Fnl 22:06, 29 June 2010 (UTC)

The main problem I have with 1.7.2.1 is that objects from the data section in jars from inside zips at least do not get extracted to the cache. I also have problems with duplicate robots in the repository (mostly only ones on the development path). — Chase-san 00:57, 30 June 2010 (UTC)

Huh, I was under the impression that the data files were extracted properly still. (note, it's technically not a robotcache anymore). Also, what do you mean by duplicate robots, and is this different than older versions? --Rednaxela 05:30, 30 June 2010 (UTC)

Well, I haven't noticed any new problems myself, but I've yet to have a chance to test very extensively, but I plan to on what is a long weekend coming up here. I'm going to clear my localhost rumble server and re-run testing with the latest version. Does anyone thing it would be good if I opened up the 1.7.2.1 testing rumble server to the world so others could speed up the process of testing it? --Rednaxela 05:30, 30 June 2010 (UTC)

I think it would be good. I am more than willing help you. If not due the stability of internet connection of my server I would open a testing server ages ago (well, my server located at my school in the university's infrastructure which is like twenty years old or more). Just a side note, 1.7.1.x runs at least five times faster than 1.6.1.4. --Nat Pavasant 12:51, 30 June 2010 (UTC)

Okay. I will wait a little with releasing 1.7.2.1 so you guys get the chance of testing it a bit more. 1.7.2.1 is "just" replacing the Jikes compiler with ECJ + some bug fixes compared to 1.7.2.0. I have started working on the 1.7.2.2 with some new features + I try to improve the speed with loading/updating the development paths, which are loaded extremely slow compared to the .jar files. :-) --Fnl 19:57, 2 July 2010 (UTC)

Alright, I just moved the bots that are known to not work in 1.7 for "WontFix" reasons out of the participants list. Anybody mind? I kept them on the bottom of the pages with links to the SF ticket that's relevant. --Rednaxela 20:46, 4 July 2010 (UTC)

Okay, I now have a rumble test server facing the world on [[1]]. It should be secured and fast enough now, I think. Feel free to run 1.7.2.1 Beta clients on it for testing! :) --Rednaxela 21:56, 4 July 2010 (UTC)

I have my roborumble and meleerumble client pointed to your server now. --Nat Pavasant 13:29, 6 July 2010 (UTC)

Red, do you have any comparing method planned? The melee is almost completed, though it should need more before becoming stable. --Nat Pavasant 14:48, 12 July 2010 (UTC)

My current comparing plan is:

1. First look for obvious outliers (things missing from high ranks, things at extreme low ranks)
2. Then import the 1.6.1.4 rumble and 1.7.2.1 rumble results tables into a spreadsheet, sort each by name, line them up beside eachother, create a column for rank difference and PL difference, then sort by those to find outliers.
3. Test any outliers. Determine if it's a bug to report, or the bot doing something that it shouldn't

Currently, 1v1 rumble has two outliers at the bottom. I already reported the bug for one and it was fixed, and I think the other is breaking due to using File IO without using the proper robocode streams. About to do the spreadsheet with melee :) --Rednaxela 02:13, 13 July 2010 (UTC)

The biggest melee outliers by APS. Positive numbers mean improvement:

	Rank change	APS change
jab.DiamondStealer 5	145	20.07
gg.Squaraus 0.6	-72	-14.08
com.syncleus.robocode.Dreadnaught 0.1	49	9.40
stelo.Spread 0.2	62	6.34
bayen.nut.Squirrel 1.615	48	4.36
stelo.Moojuk 1.3	10	3.95
stelo.SoJNanoMelee 1.1	-23	-2.95
exauge.GateKeeper 1.1.121g	21	2.37
sgp.JollyNinja 3.53	18	2.12
lrem.micro.SpikeSoldier 0.4	19	2.00
sample.TrackFire 1.0	-0	-1.87

I suspect DiamondStealer may have had bad results on the main rumble server, and I suspect the APS differences below 3% are probably a fluke. Maybe some of the larger are too, but I plan to test Squaraus and Dreadnaught anyway. --Rednaxela 05:16, 13 July 2010 (UTC)

Dreadnaught also had bad results in the beginning (not complient to 1.5.4 I believe) --GrubbmGait 08:49, 17 July 2010 (UTC)

.NET

Is it possible to submit robots written in .NET to RoboRumble? --dserbia 15:18, 15 July 2010 (UTC)

No, not at the moment. We have to make sure Robocode 1.7.x reach the really stable phase before. And I think we should wait for jni4net to reach at least beta status, for Mono support. Many of high-contributing RoboRumble clients are running under either Linux or OSX. --Nat Pavasant 15:38, 15 July 2010 (UTC)

Thanks for the quick reply! --dserbia 17:21, 15 July 2010 (UTC)

Personally, I'm not sure I'd ever be in favor of allowing them into the rumble. There would then be bots in the rumble that Mac/Linux users could never test against (and there are a lot of us), and it would also make us dependent on .NET users to contribute battles for those bots when we post new versions of our own. But I do sympathize - if/when more .NET Robocoders come onto the scene, things could change.

Keep in mind that all of this stuff is community driven, though it may all seem very "official" to a newcomer. Anyone is free to setup a competition / tournament / rumble that includes .NET bots if they want! We've had tournament style competitions like the MiniBot Challenge and Twin Duel in the past, Robocode has APIs that make automating battles for tourneys fairly easy, and Darkcanuck posts the source to his rumble server somewhere (Nat or Rednaxela would know). And there's always Challenges you can compete in, too.

--Voidious 17:38, 15 July 2010 (UTC)

I think Pavel Savara has plan for suporting jni4net, which is the core of .NET Robocode, on Mono, which can be run under Linux and Mac OS X. I don't think there is a valid reason for not supporting those when that day come. --Nat Pavasant 06:57, 16 July 2010 (UTC)

Yeah, it could work out, but there's still lots of room for issues. How stable is Mono? Will Mono add behavior discrepancies to .NET bots? Or will Java bots hit subtle behavior discepancies when battling .NET bots on Windows? (Either of those could be very hard to debug for the bot author.) Will .NET bots run much slower when running through Mono? Will that count against them in terms of CPU time/skipped turns? We've seen plenty of issues just from different JVMs / CPUs / OSes, so adding Mono and .NET to the rumble definitely requires caution. Or it may work perfectly smoothly and we'll all coexist peacefully. =) --Voidious 15:18, 16 July 2010 (UTC)

As long as one isn't doing GUI or calls to native libraries (not allowed for bots anyway), I'm pretty sure Mono is quite accurately compatible, however my concerns are around the fairness issues. x86 Java is reasonably uniform in terms of what parts of the code get optimized how well by the JVM. As I understand, Mono's performance is pretty reasonable overall, however since it's coded from scratch it's optimization characteristics are notably different I think, which makes cpu fairness somewhat tricky for having MS .Net and Mono running the same rumble. If one looks at this, it's fairly old, but shows large performance differences going either way in terms of different types of operations. That exact issue only becomes larger between the JVM and .NET, so I really do think it makes sense for .NET to be kept to a separate rumble (possibly on the same server but separated like the different formats?). --Rednaxela 19:23, 16 July 2010 (UTC)

New Rumble

Rednaxela and I have been talking a bit, and we have put considerable thought into a new 1-vs-1 rumble. Unlike our current 1-vs-1 rumble, this would have no data saving, be single round battles on a 800x800 field. Also considering having the game 'white out' names in a battle to just numbers, so there can be no hard-coded specific bot data saving either. I personally feel this kind of 1-vs-1 competition would allow for much greater competition from non-adaptive movements, and lower the bar considerably for newer robocoders. But not too much, since obviously, Crazy would never be able to win over DrussGT.

We also considered non-random starting positions (for greater fairness) and a 4 bot single round melee on the same field size.

— Chase-san 16:16, 24 July 2010 (UTC)

Yeah, I think this would be a really neat thing to have. Now, I don't think it should replace the old-style rumble, but I think it would make a very interesting competition, and perhaps much less daunting for newcomers. And to clarify on what the "white out" of names, it means robot names that bots would see would just be like "1", "2", "3", or perhaps "robot 1", "robot 2", "robot 3". Now, that does require a modification to Robocode, but I think it would probably be relatively simple and quick to get implemented. (I say it should be simple because Robocode already alters names when multiple of the same bot are in a battle, so I'd imagine the same code path can be reused, so just a matter of changing it for a certain rumble flag) --Rednaxela 16:27, 24 July 2010 (UTC)

We have put togeather a seed of 60 robots, please keep in mind this is just a seed, and you can add your own robots when it gets started. This is just to round out the robots so that we can get some meaningful rankings.

abc.Tron 2.02
ags.micro.Carpet 1.1
ags.polished.PolishedRuby 1
apv.Aspid 1.7
apv.NanoLauLectrik 1.0
apv.ScruchiPu 1.0
ary.nano.AceSurf 1.2
axeBots.Musashi 2.18
axeBots.Okami 1.04
chase.pm.Pytko 1.0
cjm.Che 1.2
cx.Lacrimas 1.36
cx.mini.Cigaret 1.31
darkcanuck.Gaff 1.50
davidalves.net.DuelistMini 1.1
davidalves.net.DuelistNano 1.0
dummy.micro.Sparrow 2.5
gh.GrubbmGrb 1.2.4
gh.GrypRepetyf 0.13
jam.mini.Raiko 0.43
jk.micro.Toorkild 0.2.4b
kawigi.robot.Girl 1.2
kawigi.sbf.FloodHT 0.9.2
kawigi.sbf.FloodSonnet 0.9
kc.micro.Needle 0.101
kc.micro.Thorn 1.252
kc.mini.Vyper 0.311
kc.nano.Splinter 1.2
kid.Gladiator .7.2
Krabb.krabby2.Krabby2 1.9o
mld.Moebius 2.9.3
mue.Hyperion 0.8
mz.NanoDeath 2.56
pe.SandboxDT 3.02
pe.SandboxLump 1.52
pedersen.Ugluk 1.0
pez.mako.Mako 1.5
pez.mini.Tityus 0.9.1
pez.mini.VertiLeach 0.4.0
ry.VirtualGunExperiment 1.2.0
rz.Aleph 0.34
rz.GlowBlowAPM 1.0
sample.Walls
sample.Crazy
simonton.beta.LifelongObsession 0.5.1
simonton.micro.GFMicro 1.0
simonton.micro.WeeklongObsession 3.4.1
simonton.nano.WeekendObsession_S 1.7
stefw.Tigger 0.0.23
synapse.Geomancy 15
techdude.Carruthers 1.2.6
tzu.TheArtOfWar 1.2
voidious.micro.Jen 1.11
vuen.Fractal 0.55
wcsv.Engineer.Engineer 0.5.4
whind.Strength 0.6.4
wiki.BasicGFSurfer 1.02
wiki.mini.Sedan 1.0
wiki.nano.RaikoNano 1.1
zyx.micro.Ant 1.1

— Chase-san 17:36, 24 July 2010 (UTC)

1.7.x rumble eventually...

Hey guys... I kind of think I dropped the ball on working on getting 1.7.x to main rumble before... but I still think it would be good to eventually. Now... unlike before (where the rumble server was a little VM on my machine that I sometimes had to shut down for lack of memory), I have a more proper server I could use for rumble. I probably won't get around to setting this up till after winter holidays (have plans with family), but just wanted to ask, how much interest in this is there? Best Regards. --Rednaxela 07:29, 21 December 2010 (UTC)

I am still interested in. Right now (well, not really, since I am not actively writing robots), my movement predictor have flags for 1.6.1.4 or 1.7.1.3+ movement. Since rumble runs 1.6.1.4 but 1.7.x+ runs much faster. Also, the whole rumble would take less time to stabilised (but it would put more load to server, since client can run, as Pavel claimed, ten times faster. --Nat Pavasant 11:36, 21 December 2010 (UTC)

I'm still interested. Kept meaning to ask you why the test rumble server went down but never did. Do you still have all the results, or would we start from scratch? Anyway, it would be good to be current. A lot of new people get 0 scores because they use new APIs, plus there's the performance benefits. --Voidious 14:00, 21 December 2010 (UTC)

Yeah, I do still have the old data, but I'm not sure we want to use it. Presumably we'd want to test now with the very latest version, and mixing the results in this of multiple versions in this test could cloud results. --Rednaxela 14:59, 22 December 2010 (UTC)

Alright! I have a new rumble test server up and running at http://rednaxela-robocode.dyndns.org/rumble/. For ease of use, rumble configuration templates are linked from it's main page. Also, if you want, here's a convenient zip of all the bots currently in rumble: [2]. This one is located on a more proper type of server, rather than a virtual machine on my laptop. So... time to get testing 1.7.2.2 and prove it stable? :) --Rednaxela 06:37, 19 January 2011 (UTC)

Hm, I thought I had this page "watched" but it looks like I've missed a lot... Is the new server running the same code and database schema as the current one? --Darkcanuck 06:43, 19 January 2011 (UTC)

Yep, same code and database schema. The only changes I made were to the front html page, and changing the accepted version of robocode to 1.7.2.2. --Rednaxela 06:57, 19 January 2011 (UTC)

I found my old laptop, I will set it to run, I might tweak the CPU constant up a little too, since it is a older/slower machine. (I will just set it in my closet, away from hustle and bustle). — Chase-san 09:32, 19 January 2011 (UTC)

Nice! I'll start running my clients against this again. Thanks Rednaxela! Btw, the superpack .zip is gone from RoboRumble/Starting With RoboRumble. I'll make a new one with the above archive unless you could just repost the old one. --Voidious 14:47, 19 January 2011 (UTC)

It turns out both my laptops puked at some point while I was out (one locked up while loading rankings, the other I forgot to make a loop and iterate was NOT). Not sure if you still have to do iterate not, and make a script loop, but I did. Only my main system had kept running the rumble. But I restarted both of those now. — Chase-san 02:36, 20 January 2011 (UTC)

As far as I know, all the memory leaks have been fixed. I had my client run over the whole day and the memory use plateaued nicely with no issues whatsoever. --Rednaxela 02:39, 20 January 2011 (UTC)

Ah well, I will switch them to use ITERATE then. Thanks. — Chase-san 02:59, 20 January 2011 (UTC)

Is there anything that we're waiting on for the switch to the 1.7 rumble rankings? I'd love to help make this upgrade happen. Ncj 16:45, 4 April 2011 (UTC)

I know Rednaxela was investigating some of the outliers from the test server's rankings. I'm not sure there was really anything "stop ship" though. I think the rankings look pretty good. Rednaxela, what do you think? --Voidious 20:38, 4 April 2011 (UTC)

Well, here's the "Table of Anomalous Results" I made when the 1.7.2.2 rumble first stabilized:

	Old Rank	Old %	New Rank	New %	Rank Diff	% Diff		ABS % Diff	ABS Rank Diff	Explanation
CharlieN.Omega.Omega 1.03	319	55.29	774	9.19	-455	-46.1		46.1	455	tracker item 3207405
NDH.GuessFactor 1.0	787	0.42	578	39.54	209	39.12		39.12	209	uses post-1.6.1.4 functions
jeremyreeder.Vincent 2011.12.09	788	0	645	33.68	143	33.68		33.68	143	uses post-1.6.1.4 functions
Krabb.krabby2.Krabby2 1.9o	71	73.63	528	43.12	-457	-30.51		30.51	457
gg.Squaraus 0.6	714	26.3	786	4.62	-72	-21.68		21.68	72	tracker item 3207405
elvbot.ElverionBot 0.3	785	0.72	751	19.75	34	19.03		19.03	34	uses post-1.6.1.4 functions
TJ.Exupery 1.39	403	50.02	174	63.3	229	13.28		13.28	229
zh.UnderDog 0.0.2	782	4.31	762	14.11	20	9.8		9.8	20	1 on 5 exception in TacticalAdvisor in 1.6.1.4
reaper.Reaper 1.1	357	53.1	194	62.6	163	9.5		9.5	163	crashes on some clients in 1.6.14 but not 1.7?
sm.Devil 7.3	517	44.13	351	53.45	166	9.32		9.32	166	crashes on some clients in 1.6.14 but not 1.7?
xiongan.Xiongan 1.1	709	27.05	614	36.22	95	9.17		9.17	95
ag.Gir 0.99	762	13.25	739	22.26	23	9.01		9.01	23

The case of "CharlieN.Omega.Omega 1.03" was tracker item 3207405, and has been fixed in 1.7.3.0 Beta. Unfortunately I've yet to investigate the other results.

Some of positive results I suspect may have been from using some Robocode 1.7 features perhaps (i.e. some new events). The case of Krabby2 I in particular mean to investigate because that result looks quite odd. Some other positive changes like Devil seem strange to me, because Devil predates Robocode 1.7 by a huge margin, yet seems to do better than in 1.6 by a notable margin. I've yet to be able to figure that out either. Anyone have any theories or can look into these cases?

Anyway, presuming these issues can be worked out, what do people think of moving straight to 1.7.3.0 perhaps? The difference relative to 1.7.2.2 is small so I don't see it as that high risk, and if it turns out there were issues, then we're no worse off than if we had spent the same effort to test 1.7.3.0. Thoughts?

--Rednaxela 04:45, 5 April 2011 (UTC)

SmallDevil crashes on my clients (dunno about others), so his 1.6 score is probably just wrong. I'm probably OK with moving to 1.7.3.0, but I'd prefer to just go with 1.7.2.2 since that's the one we've actually spent so much time testing. The difference being small could support either decision. =) 1.7.3.0 is still beta, too. --Voidious 12:44, 5 April 2011 (UTC)

Well, of course some testing of 1.7.3.0 needs to be done, but that should be possible to complete before it's out of beta. I think it's changes from 1.7.2.2 are definitely seem small enough to me that it's not like we need to do a full rumble run again. --Rednaxela 13:23, 5 April 2011 (UTC)

The three bots 'NDH.Guessfactor', 'jeremyreeder.Vincent' and elvbot.ElverionBot' all use post-1.6.1.4 functions, no further investigation needed for them. SmallDevil indeed occasionally crashes, why it does not do that on 1.7.2.2 I don't know. I believe the same goes for 'reaper.Reaper'. Friday I will have some time to check other differences. Is there a possibility to check all '2100-0' scores on the server for a specific bot? A bad client on the moment of submission has a permanent influence now. On the old server (years ago) these bad results faded away with each new battle (0.7*0.7*0.7 etc). --GrubbmGait 18:35, 6 April 2011 (UTC)

I suspect SmallDevil just crashes due to some corrupt saved data, tho I haven't investigated it. I've seen the same with other bots, like TheBrainPi. I wiped my robotcache today so I'll watch out for SmallDevil battles from me with any new bot releases. --Voidious 00:30, 7 April 2011 (UTC)

Interesting. Tomorrow I think I'll be able to look into these more, especially Krabby2 I think. --Rednaxela 05:00, 7 April 2011 (UTC)

For reaper.Reaper and sm.Devil just check their scores against ad.last.Bottom. There is the possibility that these bots still could crash in 1.7, as it only happens occasionally. Is there a way to reject/ignore 21xx-0 scores (if other scores are available) and scores way outside the normal range? That would be like an aspirine for the ranking. See example below. --GrubbmGait 14:18, 7 April 2011 (UTC)

BATTLE DETAILS FOR "reaper.Reaper 1.1" VS "abud.ThirdRobo 1.0" IN GAME "roborumble"

|% Score |% Survival |score |bullet dmg. |survival |score |bullet dmg. |survival |Battle Time             |Submitted by 
|                    | reaper.Reaper 1.1           | abud.ThirdRobo 1.0          |
|90.622  |100.000    |5991  |3233        |35       |620   | 614        | 0       |2010-05-31 12:57:18:835 |cberendt@178.63.10.12 ver.1.6.1.4 
|90.927  |100.000    |5963  |3215        |35       |595   | 590        | 0       |2010-02-09 07:49:56:713 |Miked0801@207.170.253.83 ver.1.6.1.4 
|90.044  |100.000    |5960  |3209        |35       |659   | 657        | 0       |2010-01-06 02:27:33:942 |darkcanuck@24.85.46.67 ver.1.6.1.4 
|89.834  |100.000    |5956  |3200        |35       |674   | 667        | 0       |2009-01-15 16:51:12:182 |darkcanuck_154@24.85.45.250 ver.1 
|90.435  |100.000    |5928  |3187        |35       |627   | 622        | 0       |2008-09-10 15:49:11:187 |ABC@import ver.1 
|88.993  | 97.143    |5862  |3179        |34       |725   | 643        | 1       |2008-09-21 12:06:41:943 |ABC@import ver.1 
|0.000   |  0.000    |   0  |0           | 0       |2103  |   0        |35       |2010-11-09 13:21:30:209 |Voidious@76.15.102.168 ver.1.6.1.4 
|0.000   |  0.000    |   0  |0           | 0       |2101  |   0        |35       |2010-07-04 13:50:23:859 |Voidious@76.15.102.168 ver.1.6.1.4 
|0.000   |  0.000    |   0  |0           | 0       |2101  |   0        |35       |2009-10-13 23:34:34:50  |Voidious@173.50.167.108 ver.1.6.1.4 
|0.016   |  0.000    |   1  |0           | 0       |6179  |3395        |35       |2008-10-29 04:30:08:727 |darkcanuck@24.85.45.250 ver.1

I think we could wait for Version 1.7.3.1 is out of beta and use that for its bug fixes (or just go with 1.7.3.0). It is kind of silly to still be using a version for the rumble that is nearly 3 years old, it is unlikely we are ever going to get a `perfect` version. Also might be able to eventually get .Net bots into the rumble. — Chase-san 11:09, 5 July 2011 (UTC)

I agree, we should do a switch. The new Robocode runs a lot faster, meaning faster updates on battles for any given number of clients. Moreover, there are a lot of bots that don't work on older versions due to painting methods etc that have been added in the latest Robocodes. Also, using the latest Robocode version makes it easier for beginners to contribute to rumble as well as submit their bots. I haven't seen any widespread change in scores, the problems all seem to be due to individual bots having bad programming practices or being buggy. About .Net bots in the rumble, AFAIK there is no way to run .Net reliably on Linux, which is how I (and many others) run rumble clients, but having an up-to-date client is certainly the first step. What think ye, people? --Skilgannon 12:28, 5 July 2011 (UTC)

So, lets do it already. If we just don't do it it will never happen! After that we can maybe try to talk again about trimming the participant list, mostly because I think it really needs to happen eventually. Cause as things are going in 2046, we have 2900 participants, we still haven't trimmed the list and are running a robocode version from 2016. ;) — Chase-san 15:18, 5 July 2011 (UTC)

My only concern about 1.7.x on RoboRumble is server load. 1.7.x runs much faster than the older versions. About .NET, I think Pavel is still working on jni4net on Mono, but it is not stable nor usable as far as I know. And the main .NET is still in alpha. It would be long time before .NET robot can run on RoboRumble. --Nat Pavasant 12:46, 5 July 2011 (UTC)

Agreed, let's do it. The test rumble server results looked very good. But we might have to wait until Darkcanuck says he has time to oversee it in case there are any issues. Agree on leaving out .Net and disagree on trimming participants list... 4x the participants in 35 years when we have 1,000,000x the processing power doesn't seem like a problem. =) And maybe by then we will have moved to Robocode 2 anyway. :-P --Voidious 16:09, 5 July 2011 (UTC)

You forget that robots get more complex as time passes. ;) — Chase-san 17:28, 5 July 2011 (UTC)

Let's switch. What about the current results, are they kept or dismissed. I think with the switch from 1.5.4 to 1.6.1.4 we kept all scores. Only the problembots listed above need some attention in that case. Next to this switch, maybe it's time to create a new division: Robots, and move the 'Extend Robot' ones to that place. It depends a bit if can be distinguished if a bot is a Robot or an AdvancedRobot though. It should help in two ways, first Robots finally have their own ranking and can be compared, second the 1v1 becomes a bit less crowded (although that does not seem to be very annoying right now). --GrubbmGait 17:42, 5 July 2011 (UTC)

I am pretty sure the number of "Extends Robot" robots is proportionally small. Being generous, maybe 120 of them at most. — Chase-san 17:47, 5 July 2011 (UTC)

Like the previous switch, the server should temporary accept 2 versions of clients for the rumble. And I agree with Voidious that Darkcanuck should have some time to monitor the switch. And regarding a 'Robots' division, many robocoders start with ExtendsRobot as part of a (school)project or because they think it is easier :-P . Teamrumble and Twinduel do not have many participants either, although it is true those are very different than 1v1 --GrubbmGait 17:54, 5 July 2011 (UTC)

So it sounds like we're ready to add 1.7.3.0 to the approved list? The change is easy for me and I should have enough time to keep an eye on the server for the next week or two. 1.6.1.4 will still be allowed for a short period, but I think it would be good to disable it soon (because of bot compatibility). And if 1.7.3.1 looks good it shouldn't be such a big deal to add it in soon (ie. don't need to wait 2 years!). --Darkcanuck 19:23, 5 July 2011 (UTC)

I say go for it. Having looked at the code, I know you use an array for the version checks. (should put that into the config!) — Chase-san 20:08, 5 July 2011 (UTC)

I'm definitely in support of moving to 1.7.3. Also, a couple comments on other aspects of the conversation:
- About .NET, I think that even when there are no technical issues to running it with the roborumble client, it would be best kept in it's own rumble league. I say this because I doubt there cpu constant fairness could really be achieved.
- About the concern of server load that Nat mentioned, I know that my 1.7 roborumble test server held up just fine with a peak of many more clients than the main rumble server has ever had to cope with (thanks to Chase-San :)), and there wasn't really a problem. I'm not sure what Darkcanuck is running, but my test server is running on a quaint 128MB RAM VPS even (fitting mysql on that, while having some headroom, requires some performance compromises)
--Rednaxela 00:27, 6 July 2011 (UTC)

I think the bigger issue in that case was bandwidth rather then server load, them having used up something around 40% or 60% of its pipe (I forget). In case your wondering, I ran around 16 high end i7s, each with 4 clients, all at once. — Chase-san 01:12, 6 July 2011 (UTC)

The bottleneck on my 1.7 test server wasn't bandwidth. Note, my VPS has successfully pulled from kernel.org at over 600Mbit before, and reliably gets over 100Mbit. So... bandwidth is not an issue. I believe the bottleneck was to do with the MySQL server. The main ways to fix it would involve it eating more memory really. --Rednaxela 05:19, 6 July 2011 (UTC)

Re: server load, I'll keep an eye on it. The bottleneck is the huge size of the database: I suppose if a lot of old pairings were pruned out that would probably help (indexes would stand a better chance of not getting swapped out to disk). Or if I had a bit more memory I'd put the entire pairings table into Redis and the rumble server would be screaming fast. Right now there are just too many bots! --Darkcanuck 02:10, 6 July 2011 (UTC)

I'm going to shut down the server in an hour or two, backup the database and then bring it back online with 1.7.3.0 uploads enabled. Then we'll need someone to test it... --Darkcanuck 02:10, 6 July 2011 (UTC)

It's done. Any volunteers to test this? --Darkcanuck 03:59, 6 July 2011 (UTC)

YAHOOOOO!!!!!!:) I run 1.7.3 client soon --Jdev 05:09, 6 July 2011 (UTC)

Done. --Jdev 05:17, 6 July 2011 (UTC)

And NDH.Guessfactor 1.0 gets its first real score ... --Darkcanuck 05:29, 6 July 2011 (UTC)

Starting a 1.7.3.0 client here --Rednaxela 05:19, 6 July 2011 (UTC)

Started a client here, just one though. Might setup a deticated box at some point. Also in a month or two we can probably flush all the older 1.6.1.4 pairings. — Chase-san 12:52, 6 July 2011 (UTC)

I'll start a client tonight. About flushing the 1.6.1.4 pairings, why should that be done. That just means that a lot of valid information and info of older botversions is lost. Removing older invalid results (210x-000x scores) is usefull, but that should be an automated task. A point of discussion could be whether versions that are retired for more than x years (f.e 3 years), should be moved to another (inactive) database. In that case the 'running' database will not grow that fast. --GrubbmGait 13:39, 6 July 2011 (UTC)

Don't worry, I'm not planning on flushing anything. But it might be helpful to re-release some of the bots which used to crash under 1.6.1.4 so that they get a valid ranking (and give predictable results to their opponents) if their authors are still around or someone is willing to update the packages. Purging old pairing data (for retired bots only) might be nice for performance reasons, but the downside is that you lose comparison information so I'm not keen on that either. People have donated *years* of cpu time to build up the current database! --Darkcanuck 13:51, 6 July 2011 (UTC)

Maybe a good "flushing old data" strategy, would when calculating pairings, don't count battles from old versions if there are at least 3 battles of the pairing with the new version? It seems to me this would: 1) not be too hard to implement, 2) would phase out results that were bad with the old version without needing re-release of bots, and 3) be rather seamless in that it wouldn't immediately be tossing old version results out. --Rednaxela 14:11, 6 July 2011 (UTC)

Good points all around, what was I thinking? — Chase-san 14:13, 6 July 2011 (UTC)

It's an interesting idea but I have two concerns: 1) only a handful of bots have different results between versions, it seems wasteful to throw out perfectly good 1.6.1.4 battles (considering some pairings have a high APS variance) when we could just re-release the problem bots; 2) the pairing update is done incrementally so it currently doesn't query battle data, which could be fairly expensive to add. --Darkcanuck 14:34, 6 July 2011 (UTC)

I'm running some battles locally and noticed scoring 80% vs YersiniaPestis. This is actually with 1.7.2.2. I checked recent rumble results vs other top bots and found a 24% score vs DrussGT, which seems pretty unlikely: [3]. I'll look into it sometime, but in case anyone else gets a chance first... --Voidious 02:24, 18 July 2011 (UTC)

No problems with YersiniaPestis for me, well, GresSuffurd still loses. Could it be an OS/Java version problem? --GrubbmGait 08:08, 18 July 2011 (UTC)

I've always seen wild scores with YersiniaPestis during testing (probably due to my gun's affinity for YP's movement) but I don't think that battle is too unusual. There's a similar score vs Pris: [4] (using 1.6.1.4). Checking its other close matchups, there's a lot of variability, often > 20% APS. --Darkcanuck 16:32, 18 July 2011 (UTC)

New version of robocode is out, apparently with things to speed up rumble running as well. Shouldn't we update the rumble to allow 1.7.3.2? — Chase-san 01:32, 24 August 2011 (UTC)

I don't see any major core changes listed since 1.7.3.0, should be safe to try. If you want to run a test client and are willing to double-check the results, I can update the server to allow 1.7.3.2. Also glad to see my patch get released so quickly! --Darkcanuck 04:13, 24 August 2011 (UTC)

I suppose I could. Battles I have run in roboresearch seem to be highly similar to their rumble counterparts. I'll run it under the name Chase1732, so that they can be easily removed if issues occur. — Chase-san 04:40, 24 August 2011 (UTC)

It's ready. No need to change your name: internally you get a unique id based on your username+ip+version combination. --Darkcanuck 04:55, 24 August 2011 (UTC)

Client on Google Apps Engine

I wonder, since the latest release of Google Apps Engine (1.5.0), Google add support for Backend, which allow process to run as long as you like. I think it is possible to port the RoboRumble@Home client to run on these environment; that would speed up the process. But I think we need to check if this is applicable with Google Apps Engine TOS and throttle the client enough so it doesn't use more than its free quota limit ;-) Just an idea! --Nat Pavasant 01:42, 11 May 2011 (UTC)

Well, I'm pretty sure that even if you can run a process as long as you like, they don't guarantee a constant amount of available CPU, which is important for robocode. Of course, if in the future, robocode switches to using the less granular APIs that track actual cpu time used by given threads, then this would probably work. It's not really the same, but as a note, you can already run robocode on Amazon's EC2, which does guarantee a level of CPU allocation. Chase-san briefly tried this once in the past.--Rednaxela 02:51, 11 May 2011 (UTC)

But, of course, unless you already host something on EC2, the EC2 isn't "free" ;-) --Nat Pavasant 12:19, 11 May 2011 (UTC)

I've been running two instances of the client on the cheapest server offered by linode ($20/mo). I'd run more, as it's quad core, but it only has 500MB of RAM and is thus memory bound. I keep the box around in case I need to pretend my traffic is coming from the US, but for a dedicated RoboRumble box would EC2 end up being cheaper? Ncj 16:52, 17 May 2011 (UTC)

As an aside, I'd only recommend running one client with 500 megs of RAM, as I think other people use and test with 512. I remember the default was 512 in robocode.sh but still 256 in roborumble.sh at one point - not sure if that's been fixed. Pretty cool you do that, though! --Voidious 21:44, 17 May 2011 (UTC)

Aside from agreeing with Voidious about wanting 500mb per client, I'd question whether the CPU allocation on linode is stable. Those are virtual machines shared with other instances, and while there are "four cores" that it has access to, it's not as if it's exclusive access. I'd be very concerned that your clients are causing bots to skip turns whenever other instances on the machine get busy. --Rednaxela 00:29, 18 May 2011 (UTC)

If Linode CPU's allocation isn't stable, then isn't the EC2. They are based on the same virtualization technology, Xen. I'd be more concerned if it is KVM or OpenVZ virtualization system. --Nat Pavasant 14:29, 18 May 2011 (UTC)

It would all be a matter of how they configure it (i.e. cpu caps). EC2 is marketed for high performance computing purposes. I'm pretty sure caps cpu usage of instances so people never get more than they pay for, and also so it's possible for all instances to hit the cap without fighting for CPU. In contrast, I'm pretty sure Linode is markets their instances more for hosting purposes, and so I'd expect them to manage their caps differently such that when there are free cpu cycles an instance may use more than it would be able to if all instances were busy. Basically, the underlying technology (Xen) is the same, but as I understand, the type of service is fairly different. That said, I've personally not used either service, but from what I've read, this is my understanding of the two. --Rednaxela 23:22, 19 May 2011 (UTC)

Is there a way for me to check this? Somehow compare the % of skipped turns on my client to someone else's? Ncj 15:36, 18 May 2011 (UTC)

Unfortunately no (at least not without modification to robocode). Actually... I kind of wish that Robocode would report "percent of turns skipped" to the roborumble server.... --Rednaxela 23:22, 19 May 2011 (UTC)

Frequency of Submissions

I've been submitting a lot of updates to my robot lately. Is there any etiquette on how often is too often? I just want to make sure I'm not annoying anyone. I do expect my frequency of updates to slow dramatically soon. Thanks. Skotty 19:17, 13 June 2011 (UTC)

My view's pretty simple: as long as you're not delaying other bots from reaching a stable rating, release as often as you like! A bot without full pairings takes precedence over a bot under 2k battles, but a bot's rating isn't really stable until around 2k battles. So if my bot's at 800 and you keep releasing new versions, I'll never get to 2k. Personally, if this happened to me, I'd just temporarily exclude you on my clients, which seems fair to both of us. Pulling my weight in RoboRumble clients tends to alleviate any potential guilt, too. And FWIW, I've certainly done daily updates for long stretches (eg, Diamond/Version History and Komarious/Version History). --Voidious 19:42, 13 June 2011 (UTC)

Robocode Repository Package

Hello everyone. Robocode Repository is still down for longer time again. Is there a possibility adding a packge with all of its actual robots from the rumble? The roborumble-superpack-20110123 package is great stuff, but does not contain all of the actual Robocode Repository robots. Thanks! --FromHell 14:48, 20 June 2011 (UTC)

I zipped up all the JARs in my RoboRumble dir pretty recently, should have most of what you need: roborumble_bots.zip (69 MB). It also has lots of versions of many bots, so you might want to just grab what you need... It would indeed be good to update the superpack sometime. --Voidious 14:56, 20 June 2011 (UTC)

Great! Thank you very much. Yes, updating the superpack would be good, because sometimes the stabilization of the rankings needs some time, because not every contributor has all bots, especially the ones missing from repository. Maybe I will update my local rumbleback the next days, after finishing my actual development on CHCl3. Normally I would publish the new superpack, but the only problem is, that my webspace is from a friend of mine and is very limited and he wants to change the provider in the next few months. So it's no good idea publishing it on "my" server. But it would work for a while. --FromHell 18:50, 20 June 2011 (UTC)

I addad a package to my webspace with all missing Robocode Repository bots (for every category). roborumble_missing_bots_20110621.zip (275 KB). It would be great if someone would update the superpack with these bots and making it available for the whole community. Or should I add my link to the Starting With RoboRumble page at this wiki? --FromHell 09:54, 21 June 2011 (UTC)

ImWithStupidTeam

There seems to be a problem with ImWithStupidTeam. Executing the rumble will be canceled with the following message: "Aborting battle, could not find robot: pedersen.ImWithStupid 1.3". I had a closer look to the bot and there was still a jar file in the jar file. Taking the inner jar, adding the file ImWithStupidTeam.team to the jar, renaming the new jar to pedersen.ImWithStupidTeam_1.3.jar should just do the trick. Should this team be removed from the team rumble participants list? Found an entry to 1v1 list that there was also removed a bot, because it was wrong packaged. What is the right way? Thanks for your answers. --FromHell 10:30, 21 June 2011 (UTC)

Thanks to MN for taking action at this point. --FromHell 21:00, 3 July 2011 (UTC)

Running the rumble

I apologize but it is unlikely i'll be able to run the rumble this week. Forecast is all very high heat and high humidity. I personally do not want to run my system in the jungle. In fact so much so I cannot even use it, as it is off. — Chase-san 19:50, 18 July 2011 (UTC)

I was following a policy of running clients non-stop until the rankings stabilize whenever I mess with the participants list myself. --MN 02:08, 22 July 2011 (UTC)

I will be running the rumble almost all day Monday, Tuesday, Wednesday and Thursday at the current rate, also at night (almost every day). So feel free to release more often or use rumble for more developmental builds. Please out my extra cpu time to good use. — Chase-san 17:49, 8 September 2011 (UTC)

Increase BATTLESPERBOT roborumble parameter

I think, that it is time to increase BATTLESPERBOT, beacuse current value gives ~2.4 battles against every but and this amount is too small to stabilise ratings
I increase BATTLESPERBOT to 4400 battles (~ 5.3 battles against each bot) and suggest to all do the same thing. Or counter arguments:) --Jdev 05:54, 11 August 2011 (UTC)

I don't think it's necessary. The latest updates to the server cause it to send out priority battles for any low matchups 50% of the time (which overrides the client's battles-per-bot processing). That should ensure pairings fill up fairly evenly. Extra priority is also given to pairings with < 2 battles, those are requested 100% of the time. I would be inclined to increase the 50% instead, if we all agree that even pairings are most important (I think they are). --Darkcanuck 06:05, 11 August 2011 (UTC)

I'm Sorry, but because my english i can not understand following statements:

* "send out priority battles for any low matchups 50% of the time"?

* "Extra priority is also given to pairings with < 2 battles, those are requested 100% of the time."? Anyway, 2 battels is still too low. May be increase this value?

* "that even pairings are most important"

--Jdev 07:14, 11 August 2011 (UTC)

I briefly described the new system here: Darkcanuck/RRServer/Updates. Every time you upload a result, the server decides whether or not to send your client a priority battle request (a single pairing that needs another battle). These priority battles get run first, then your client worries about the bots with battles < BATTLESPERBOT. Right now the server always sends a priority battle request if it sees a pairing with < 2 battles. Otherwise, 50% of the time it will send a request for a pairing that has a low battle count. The other 50% of the time, your client will choose what to run next. We could either increase the percentage or increase the < 2.

"that even pairings are most important" = trying to get all pairings to an equal number of battles is most important (in my opinion). --Darkcanuck 07:41, 11 August 2011 (UTC)

Thank you, Darkcanuck! Now all things is clear for me. --Jdev 08:06, 11 August 2011 (UTC)

There was a discussion on Talk:Darkcanuck/RRServer/Query. The only disadvantage I see with making the priority system too deterministic is with the ELO and Glicko-2 rating systems. They are sensitive to battle ordering and work better with random pairings. Right now they are both stabilizing slower than the APS rating system. --MN 13:52, 11 August 2011 (UTC)

This kind of thing is why in the past I've argued in favor of having a rating system which is essentially APS, except uses Glicko-2 to estimate the score of missing pairings. I say this because it seems to me the only advantage of Glicko-2 over APS is in the incomplete pairing scenario, and one should be able to get the best of both worlds by just using Glicko-2 for estimation of missing pairings. --Rednaxela 14:18, 11 August 2011 (UTC)

I noticed that JollyNinja is getting unusually bad results in the latest battles it has run (it currently votes for Quantum, which it really shouldn't be!)

JollyNinja's results on LiteRumble

When I run battles locally I get the following warnings:

SYSTEM: Warning: sgp.JollyNinja uses static reference to a robot with the following field(s):
sgp.JollyNinja.instance, which points to a sgp.JollyNinja
sgp.Environment.robot, which points to a robocode.AdvancedRobot
SYSTEM: Static references to robots can cause unwanted behaviour with the robot using these.
SYSTEM: Please change static robot references to non-static references and recompile the robot.

When I run battles on a 1.9.4.2 client I see the poor performance seen in the rumble but with 1.9.5.2 the performance looks to be okay.

Hey good catch. I guess we should upgrade the rumble to 1.9.5.2?

If it helps I'd be happy to point a 1.9.5.2 client at a fresh rumble to generate enough results to compare to the current rankings. I figure it'd be much easier to spot any bots that get broken that way.

I'm using a shared computer (MacOS) to run battles and have set the USER variable in roborumble/meleerumble.txt to David414 however when the results are uploaded that username isn't used. This wasn't a problem when I mistakenly tried to use the 1.9.5.2 client. Does anybody know what I need to patch to fix this?

Easiest fix is to add USER = YOUR_NAME to meleerumble.sh

I decide to write robocode bot on scala to learn scala.
But there're a little problem - to run battles with them, you need download scala and add some libraries to rc classpath.
It's ok for me, if only my clients will run my bot. But will whole community agree, if i publish bot, which is not runnable in usual environment?

We shouldn't have bots in the rumble that can only be run on some clients. It's not really fair, and it makes us dependent on a few (or one) clients to get complete pairings for new bots.

There have been discussions about Scala in Robocode before and I think the current state is that we can't officially support it because it requires some insecure stuff disallowed by Robocode sandbox (like Reflection). See Talk:Other JVM Languages and this robocode-developers thread. Maybe we can revisit this discussion, but we'd need input from Pavel or Fnl, and possibly some Scala guru.

I'm also interested in Scala, and it might help us attract the edgy young functional programmers of the world if Robocode supported it. So it would be cool if we could. But I don't really know the details of how to do it right.

Edgy young functional programmers, eh? I must admit I am pretty interested in Scala too and that was one of the main things keeping me from giving it a real try.

It's a pity... But i write robot on scala anyway. I will return to this question when take crown in my local tests:)

I'm also planning to write scala robot now ;) Since I write scala daily, and I was maintaining a fork of robocode featuring OpenGL, I think there must exist a solution to run scala robot without sacrificing robocode sandbox.

Would like to add India's flag and link it to the code IND in the RoboRumble/Country Flagslist. I don't have a GIF. Help appreciated.

Welcome! I've added the flag, you should be good to go!

Thank you. Much appreciated

For unknown reason, the RoboRumble ranking has lost a lot of pairings. MiniRumble and smaller seem not effected. So it will take a while for it to stabelize as there are lots of bots that are missing 1-40 pairings.

That may be caused by a design flaw of the rumble client, which I didn't verify though. If the rumble cannot read robowiki's participants list, it will load a local cache instead. However, if that cache is outdated, it may cause the rumble to loose pairings, and recovering takes much longer. But this seems not to be the case losing 40 pairings.

Another possibility may be that the rumble client got a truncated participant list due to network issues, for this case, I may modify the client to check some flag to make sure the loaded participants list is full.

Hi all, has anybody had the same issue? When I start roborumble.sh, it says "Could not load properties file: ./roborumble/roborumble.txt", and the execution stops right after initiating Iteration 0. In 1.9.3.4, everything seems to work.

I never ever experienced the same thing. And the code change from 1.9.3.4 is kept minimal that I couldn’t come up with whatever change could cause this to happen.

Anyway have you ever tried to have a clean install? Or maybe the path containing robocode contains some weird char that prevents robocode from processing (e.g. space, this bug is known)

Thanks, that actually worked. I had to run the installation instead of simply unpacking the jar.

Hi all

I've been thinking of upgrading the accepted client version. What are your thoughts on the matter? Have any of you tested extensively with the latest releases locally? Are there any changes in scores (or any changes that might affect scores) that we should do more extensive testing of first?

Finally 1.9.3.3 released, with RoboRumble battle duplicating fix, and with shorter participants list check period from 1.9.3.1 as well. It’s time to do a test and discuss to upgrade.

Question, what kind of tests should be done in local? Should we run a literumble locally and see whether it yields the same score as the main rumble? (which gives the best result but takes monthes). Or just using roborunner with a few robots (both 1v1 and melee certainly), and see their score is unaffected.

Just roborunner and a few bots should be fine. At some point it would be good to reset the meleerumble as well, since old bots get biased downwards by excessive battles against new (good) bots.

I've been always thinking about the pairing systems of meleerumble.

Once every combination of 10 bots had a run, the score is unbiased, which takes N = n! / (10! * (n - 10)!) ≈ 10^19 battles in current settings (n is the total of participants).

However we should get approximate score with feasible battles via monte carlo method. In current settings, ~10000 battles already gives a somewhat stable score (for the new participant).

Let each bot gets m battles, randomly selected from all (N / n) 10-bot combinations containing that bot, then the probability of meeting another specific bot in a battle is (N / n / (n - 1)) / (N / n) = 1 / (n - 1).

Assume that when a new bot is released, every battle contains that bot, then the probability of meeting that bot is 1 instead of 1 / (n - 1), which is highly biased.

To fix this, we have two options — mutate our current pairing systems to get unbiased score online, or to reset the entire meleerumble periodically.

Since the score of new bots are unbiased, all we need to do for an unbiased score is to ignore (n - 2) / (n - 1) biased battles randomly when calculating the score of an old bot. However this approach takes much more battles.

A more practical way is is, when bot A is added, for each battle, select another bot B randomly, and run melee battles containing those two bots as usual. A battle containing A, B and other 8 bots should yield 45 pairings, but only those matching (A, *) or (B, *) is taken into account. This produces 17 parings.

This scheme does not affect the pairings of the new bot itself at all, which is already unbiased; And for an old bot, the probability of being chosen as B is 1 / (n - 1), therefore the probability of a battle with A present being taken into account for old bots is 1 / (n - 1), the same as the unbiased one.

Your second approach seems good, it will need patches on the client side so that if a priority pairing needs to happen it only uploads the battles which contain one of the priority bots. This filter will work fine for the 1v1 rumble as well.

Why don't we wait to update the client until this can be fixed too?

The only reason for upgrading earlier is that those two bugs are very annoying when running rumble client 7/24.

And it generally takes monthes for fnl to release a new version in normal cycle ;(

Anyway, since those two fixes are unrelated to robocode engine, one should expect no performance difference if we cherry pick the fix back to 1.9.2.5.

Maybe we could release a special version of 1.9.2.5 for those running rumble 7/24, before the melee pairing fix is released.

Or, we may just ask fnl whether he could please release 1.9.3.4 soon after the meleerumble patch is applied.

In literumble stats I see that one of my rumble client has stopped working for a few days — and once I had a look, it shows

929073875 Jul 2 21:40 resultsmelee.txt

the resultsmelee.txt grows so large that even the JVM gets killed when processing the file (887M)

and the content of the file is just one line which gets duplicated all the time (which grows exponentially).

Not sure whether this bug is fixed in the newest version, or how can I send pull request to robocode base? the github code seems to be mirror only.

I would suggest making a bug on Sourceforge and attaching a patch if you have a fix.

Thanks ;)

The patch is submitted:

https://sourceforge.net/p/robocode/bugs/395/

Btw, is literumble affected by duplicated uploads? Will it remove duplicated battles automatically?

Literumble will reject battles older than 24 hours, so any broken battles have a limited window of problems.

Thousands of duplicated battles could be generated within only a few minutes due to the fact of exponential growth. Thankfully this only happens to bots with multiple weight classes. If literumble is not removing duplicates, then this could answer why some bots get 2x or 5x more battles than other bots. And for those bots, their battle result is mainly determined by those duplicated record which causes inaccurate score ;(

Hope fnl should react sooner this time (instead of half a year)

Only that pairing will have lots of battles - it won't affect the score that much, since it doesn't affect all the other battles. Also, pairings are weighted with a rolling average so roughly only the last 40 battles actually contribute. So once some more battles happen it won't matter.

This isn't a crucial problem but when I have two computers running the client at the same time bots that should be retired aren't removed.

I usually restart robocode client to get updated list from the wiki. Otherwise it takes several hours to stop running battles with retired bots. I think it improved in the latest version of robocode, but littlerumble server does not accept this version yet.

I’m running roborumble on 3 computers/servers, and restarting them manually all the time is already annoying. Once we migrate to the newest version of roborumble, running roborumbe as a service may be eaiser, and I could run roborumble on even more servers (50+ roborumbe clients in total!).

I decided to put a bit more info about the ThreadDeath problem. The offending log entry would look like

Round 4 of 10
=========================
java.lang.ThreadDeath
	at java.lang.Thread.stop(Thread.java:853)
	at net.sf.robocode.host.security.RobotThreadManager.stop(RobotThreadManager.java:190)
	at net.sf.robocode.host.security.RobotThreadManager.stopSteps(RobotThreadManager.java:172)
	at net.sf.robocode.host.security.RobotThreadManager.forceStop(RobotThreadManager.java:143)
	at net.sf.robocode.host.proxies.HostingRobotProxy.forceStopThread(HostingRobotProxy.java:144)
	at net.sf.robocode.host.proxies.BasicRobotProxy.forceStopThread(BasicRobotProxy.java:44)
	at net.sf.robocode.battle.peer.RobotPeer.checkSkippedTurn(RobotPeer.java:649)
	at net.sf.robocode.battle.peer.RobotPeer.executeImpl(RobotPeer.java:492)
	at net.sf.robocode.host.proxies.BasicRobotProxy.executeImpl(BasicRobotProxy.java:384)
	at net.sf.robocode.host.proxies.BasicRobotProxy.execute(BasicRobotProxy.java:122)
	at robocode.AdvancedRobot.execute(AdvancedRobot.java:552)
	at eem.frame.gameInfo.gameInfo.run(gameInfo.java:95)
	at eem.frame.core.CoreBot.run(CoreBot.java:206)
	at net.sf.robocode.host.proxies.HostingRobotProxy.callUserCode(HostingRobotProxy.java:274)
	at net.sf.robocode.host.proxies.HostingRobotProxy.run(HostingRobotProxy.java:221)
	at net.sf.robocode.host.proxies.BasicRobotProxy.run(BasicRobotProxy.java:44)
	at java.lang.Thread.run(Thread.java:748)

Note that something was very wrong. My bot did not received even SYSTEM onDeath event as can be seen in the more complete log below. Though, my bot was counted as a looser for the first 3 rounds by the other bot. Also, my bot outputted some log during rounds 1 to 4, so the error happens somewhere during the round and steal control from the bot. Also note some time profiling at the end, many methods report max as a factor of 100 times more than an average time. I.e. some catastrophic event happend. One issue that the number of operation is different in every method execution, but I bet not by factor of 100.

=========================
Round 1 of 10
=========================
=========== Round #1=============
100007 best target penguin.Joker .611wr
SYSTEM: EvBotNG vtest skipped turn 19
Skipped turn 19 reported at 100020
SYSTEM: EvBotNG vtest skipped turn 32
Skipped turn 32 reported at 100033
100221: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.6450138864756005 with real bullet
100314: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.2827484567498845 with real bullet
100387: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.20989274379107656 with real bullet
100431: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.19347401753112997 with real bullet
=========================
Round 2 of 10
=========================
=========== Round #2=============
Probing new bullet energy 1.95
SYSTEM: EvBotNG vtest skipped turn 8
Skipped turn 8 reported at 200009
200055: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.3557362360118722 with real bullet
200307: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.08198800256947705 with real bullet
200335: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.06521832333874987 with real bullet
penguin.Joker .611wr hit enemy: eem.EvBotNG vtest with gun: circularGun fired at dist: 566.5311086790286
200354: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.10610623841145142 with real bullet
SYSTEM: EvBotNG vtest skipped turn 396
Skipped turn 396 reported at 200397
=========================
Round 3 of 10
=========================
java.lang.ThreadDeath
	at java.lang.Thread.stop(Thread.java:853)
	at net.sf.robocode.host.security.RobotThreadManager.stop(RobotThreadManager.java:190)
	at net.sf.robocode.host.security.RobotThreadManager.stopSteps(RobotThreadManager.java:172)
	at net.sf.robocode.host.security.RobotThreadManager.forceStop(RobotThreadManager.java:143)
	at net.sf.robocode.host.proxies.HostingRobotProxy.forceStopThread(HostingRobotProxy.java:144)
	at net.sf.robocode.host.proxies.BasicRobotProxy.forceStopThread(BasicRobotProxy.java:44)
	at net.sf.robocode.battle.peer.RobotPeer.checkSkippedTurn(RobotPeer.java:649)
	at net.sf.robocode.battle.peer.RobotPeer.executeImpl(RobotPeer.java:492)
	at net.sf.robocode.host.proxies.BasicRobotProxy.executeImpl(BasicRobotProxy.java:384)
	at net.sf.robocode.host.proxies.BasicRobotProxy.execute(BasicRobotProxy.java:122)
	at robocode.AdvancedRobot.execute(AdvancedRobot.java:552)
	at eem.frame.gameInfo.gameInfo.run(gameInfo.java:95)
	at eem.frame.core.CoreBot.run(CoreBot.java:206)
	at net.sf.robocode.host.proxies.HostingRobotProxy.callUserCode(HostingRobotProxy.java:274)
	at net.sf.robocode.host.proxies.HostingRobotProxy.run(HostingRobotProxy.java:221)
	at net.sf.robocode.host.proxies.BasicRobotProxy.run(BasicRobotProxy.java:44)
	at java.lang.Thread.run(Thread.java:748)
=========== Round #3=============
Probing new bullet energy 1.95
300093: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.37068349323008726 with real bullet
SYSTEM: EvBotNG vtest skipped turn 156
Skipped turn 156 reported at 300157
SYSTEM: EvBotNG vtest skipped turn 191
Skipped turn 191 reported at 300192
300301: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.2802401527715257 with real bullet
300493: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.1975865759018777 with real bullet
SYSTEM: EvBotNG vtest skipped turn 559
Skipped turn 559 reported at 300560
=========================
Round 4 of 10
=========================
java.lang.ThreadDeath
	at java.lang.Thread.stop(Thread.java:853)
	at net.sf.robocode.host.security.RobotThreadManager.stop(RobotThreadManager.java:190)
	at net.sf.robocode.host.security.RobotThreadManager.stopSteps(RobotThreadManager.java:172)
	at net.sf.robocode.host.security.RobotThreadManager.forceStop(RobotThreadManager.java:143)
	at net.sf.robocode.host.proxies.HostingRobotProxy.forceStopThread(HostingRobotProxy.java:144)
	at net.sf.robocode.host.proxies.BasicRobotProxy.forceStopThread(BasicRobotProxy.java:44)
	at net.sf.robocode.battle.peer.RobotPeer.checkSkippedTurn(RobotPeer.java:649)
	at net.sf.robocode.battle.peer.RobotPeer.executeImpl(RobotPeer.java:492)
	at net.sf.robocode.host.proxies.BasicRobotProxy.executeImpl(BasicRobotProxy.java:384)
	at net.sf.robocode.host.proxies.BasicRobotProxy.execute(BasicRobotProxy.java:122)
	at robocode.AdvancedRobot.execute(AdvancedRobot.java:552)
	at eem.frame.gameInfo.gameInfo.run(gameInfo.java:95)
	at eem.frame.core.CoreBot.run(CoreBot.java:206)
	at net.sf.robocode.host.proxies.HostingRobotProxy.callUserCode(HostingRobotProxy.java:274)
	at net.sf.robocode.host.proxies.HostingRobotProxy.run(HostingRobotProxy.java:221)
	at net.sf.robocode.host.proxies.BasicRobotProxy.run(BasicRobotProxy.java:44)
	at java.lang.Thread.run(Thread.java:748)
=========== Round #4=============
Probing new bullet energy 1.95
400161: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.6168884721887381 with real bullet
400292: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.09859694511664721 with real bullet
400317: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.47485553157064525 with real bullet
400345: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.2798221445512617 with real bullet
400476: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.2817195309815388 with real bullet
400492: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = 0.34782608695652234 with real bullet
=========================
Round 5 of 10
=========================
=========== Round #5=============
Probing new bullet energy 1.95
SYSTEM: Bonus for killing penguin.Joker .611wr: 11
SYSTEM: eem.EvBotNG vtest wins the round.
Hit by bullet: [5, 4, 3, 6, 0, 0, 0, 0, 0, 0]
Wall hits stats: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Skipped turns stats: [2, 2, 3, 0, 0, 0, 0, 0, 0, 0]
Hit rate stats:   16/158  =   10.13%
Bullet hit bullet stats::   10/158  =    6.33%
Rounds ratio of win/lose = 1/2
Finishing places stats: [1, 2]
myWinLosePlace = 0
My score in this round = 113.4 enemy score = 0.0
My total score = 176.89999999999998 enemy score = 246.76000000000022
Round APS stats: [25.01444251877526, 0.0, 0.0, 14.727325750947783, 100.0, 0.0, 0.0, 0.0, 0.0, 0.0]
Accumulated APS = 41.76%
--- bot penguin.Joker .611wr stats:
hit rate for the following bot(s) out of 172 shots
 eem.EvBotNG vtest:   18/172  =   10.47%
  My virtual gun hit rate stats stats
                 enemy name              circularGun                headOnGun              realHitsGun               unknownGun
          eem.EvBotNG vtest        1/172  =    0.58%        0/172  =    0.00%       18/172  =   10.47%       17/172  =    9.88%
--- bot eem.EvBotNG vtest stats:
wrong path prediction count: 7 <------------------------------ improve me!
Hit me count by the following bot(s)
 penguin.Joker .611wr:   18/172  =   10.47%
  Enemies virtual gun stats
    circularGun of bot penguin.Joker .611wr hit me   12/172  =    6.98%
    headOnGun of bot penguin.Joker .611wr hit me   13/172  =    7.56%
    realHitsGun of bot penguin.Joker .611wr hit me    1/172  =    0.58%
hit rate for the following bot(s) out of 158 shots
 penguin.Joker .611wr:   16/158  =   10.13%
  My virtual gun hit rate stats stats
                 enemy name              circularGun         circularAccelGun                headOnGun                  kdtGF50                 kdtGF100                 kdtGF200                 kdtGF400                 kdtGF800                kdtGF1600           guessFactorGun                randomGun            assistedGFGun   decayingGuessFactorGun   flipLastGuessFactorGun
       penguin.Joker .611wr       11/147  =    7.48%       13/147  =    8.84%       17/147  =   11.56%       23/147  =   15.65%       14/147  =    9.52%       12/147  =    8.16%       19/147  =   12.93%       14/147  =    9.52%       18/147  =   12.24%       11/147  =    7.48%       17/147  =   11.56%       13/147  =    8.84%        7/147  =    4.76%       17/147  =   11.56%
bot penguin.Joker .611wr intercepted my bullet   10/172  =    5.81%
Profiler stats---------------------------
  getOverlap was executed 22026 execution times: min 67 nS, average 118 nS, max 58 uS
  getJoin was executed 5 execution times: min 2 uS, average 2 uS, max 3 uS
  choseNewPath was executed 2529 execution times: min 95 uS, average 321 uS, max 14 mS
  rankAimAtAllSolutions was executed 2358 execution times: min 243 nS, average 4 uS, max 2 mS
  waveWithBullets.getDanger was executed 312940 execution times: min 74 nS, average 331 nS, max 2 mS
  calculateDanger was executed 10899 execution times: min 801 nS, average 43 uS, max 13 mS
  waveWithBullets.getWaveDanger was executed 26899 execution times: min 450 nS, average 2 uS, max 2 mS
  gunManagerManage was executed 2529 execution times: min 3 uS, average 586 uS, max 12 mS
---------------------------
500353: penguin.Joker .611wr hit eem.EvBotNG vtest at GF = -0.31909710498646854 with real bullet
=========================

Would you try modifing the source of robocode to make it ouput the result of checkSkippedTurn? I think the bug may be whether the skipped turns are counted incorrectly or some skipped turns are not logged to console.

Skipped turns are logged (and SkippedTurnEvents happens) only when the Robocode regains control over the execution of the thread. Since there is an unhandled exception being thrown right during the skipped turn checking, it makes sense that the skipped turns are not logged. I'm pretty sure you are skipping too many turns, Thread.stop() is being called as it is supposed to be (by looking at Robocode source), the exception is being thrown (because Thread.stop() is deprecated) and for some reason it's not being handled.

So, the error message is pretty much "you have skipped too many turns, I tried to stop your thread but for this I called a deprecated function which throws an error". The bot punishment for skipping too many turns is correct. The correct questions are: this should really happen? not the error, but the "too many skipped turns" thing. Does it happen when locking to 1000 FPS? If it was a "fair" turn skipping, it should happen while locked to 1000 FPS as well? If yes, why it's behaving differently when on full speed? Can others reproduce the same issue? (pick Roborio vs Neuromancer, for example, and go full speed). Why it's more likely to happen when a slow bot is against a fast bot? And so on.

Does you guys have any other interesting observations on that?

Ok. Roborio also fall into ThreadDeath in the battle:

rsalesc.roborio.Roborio 1.2.7  vs penguin.Joker .611wr

It does not happens at 1000 FPS, only if I push the slider to max.

I also see DrussGT falling into ThreadDeath in the battle:

jk.mega.DrussGT 3.2.1 vs penguin.Joker .611wr

It seems that in a pair of bots the most CPU demanding gets the exception.

Yeah, here is the heart of the issue in my opinion. Weird things going under the hood when going full speed. I still have not fully understood Robocode skipped turn source so I'm not sure what's happening. I'll do more tests tomorrow.

I looked at the internals. The difference between desired 1000 TPS and max is that in the later case the Thread.sleep is called (actually if you have more than 0.5 ms to spare). I am guessing that probabilistically Thread.Sleep is called couple times per round.

I do not know what java does when thread is asleep, but I would imagine that the garbage collector and other gizmos kick in during the sleep. While at max TPS the java chooses as it wishes when to run GC and if you are the unlucky one, the GC time will be counted against your bot. This would explain sporadic super long executions in my bot time profiling.

I would gladly try. But how do I call it within the AdvancedBot?

What I mean is that you hack in to the robocode to make it output some useful information about these bugs. There is no need for your bot to call that, as checkSkippedTurn is called by the game every turn.

I must be very distracted, the skipped turns should be logged, right?

They are logged before the piece of code which calls the thread stopping procedure. It's logged if the bot is still alive. That means that the bots which are getting the ThreadError are not alive at all?

Yes, that's very strange. And that's why I think hack into robocode source code and make it output some useful information in checkSkippedTurn would help.

This would help us find out 1. why skipped turns are getting greater than 30 eventually. 2. why there is no output before at all (is it still alive? )

I'm also thinking about the possibility that the main thread of robocode is also skipping turns itself ;p

I cannot remember how I get this knowledge but I recall that the logic is following. Robocode let you consume as much time as you want per tic (see the exception below), than if you exceed time quota, it will force you to skip as many turns as you excess time over permited time per tic. That is why you often see skipped turns in succession (though, not in my log above).

However, if a bot have a glitch and never returns control back to the robocode (let's say there is an infinite loop), then robocode have a way to force stop such bot. I would not be surprised that it first kill the bot and then executes checkSkippedTurn. In this case a bot will see nothing in console.

For your questions:

1. I/O robots (bots that read/write from the data directory) get 240 skipped turns. Apparently a robot can get marked as an I/O robot just by calling getDataDirectory().
2. This is where things stop making sense. The stacktrace shows RobotPeer.checkSkippedTurn() calling BasicRobotProxy.forceStopThread(), but the code shows that it can't happen without going through println("SYSTEM: ..."), there literally is no other code path. Are println() calls getting silently dropped?
3. The Robocode main thread can't "skip turns" because it controls the turn counter.

Relevant code:

public void checkSkippedTurn() {
    // Store last and current execution time for detecting skipped turns
    lastExecutionTime = currentExecutionTime;
    currentExecutionTime = battle.getTime();

    int numSkippedTurns = (currentExecutionTime - lastExecutionTime) - 1;
    if (numSkippedTurns >= 1) {
        events.get().clear(false);

        if (isAlive()) {
            for (int skippedTurn = lastExecutionTime + 1; skippedTurn < currentExecutionTime; skippedTurn++) {
                addEvent(new SkippedTurnEvent(skippedTurn));
                println("SYSTEM: " + getShortName() + " skipped turn " + skippedTurn);
            }
        }

        if ((!isIORobot && (numSkippedTurns > MAX_SKIPPED_TURNS))
                || (isIORobot && (numSkippedTurns > MAX_SKIPPED_TURNS_WITH_IO))) {
            println("SYSTEM: " + getShortName() + " has not performed any actions in a reasonable amount of time.");
            println("SYSTEM: No score will be generated.");
            setHalt(true);
            waitWakeupNoWait();
            punishBadBehavior(BadBehavior.SKIPPED_TOO_MANY_TURNS);
            robotProxy.forceStopThread();
        }
    }
}

Here is my current best guess.

Note that Beaming's stacktrace includes:

...
at net.sf.robocode.host.proxies.BasicRobotProxy.forceStopThread(BasicRobotProxy.java:44)
at net.sf.robocode.battle.peer.RobotPeer.checkSkippedTurn(RobotPeer.java:649)
...

Therefore, RobotPeer.checkSkippedTurn() called BasicRobotProxy.forceStopThread()

The source code of RobotPeer.checkSkippedTurn() shows one and only one possible call to BasicRobotProxy.forceStopThread():

public void checkSkippedTurn() {
    // ...
    if (/* snip */) {
        println("SYSTEM: " + getShortName() + " has not performed any actions in a reasonable amount of time.");
        println("SYSTEM: No score will be generated.");
        /* snip */
        robotProxy.forceStopThread();
    }
}

Therefore, control flow must have passed through this path.

Note that this code sequence includes a println("SYSTEM: <Bot> has not performed any actions...") call, which must have been executed, yet no such SYSTEM message is present in Beaming's log.

The source code of the println() method:

public void println(String s) {
    synchronized (proxyText) {
        battleText.append(s);
        battleText.append("\n");
    }
}

Note the following:

1. Robocode is multithreaded. Heavy multithreading causes race conditions.
2. The variable battleText is a StringBuilder, which is not thread-safe (unlike a StringBuffer), which is.
3. The code modifies battleText, but only synchronizes against proxyText.

Therefore, EvBotNG is skipping turns, but no log messages (from either Robocode or the bot) are printed, because they are silently dropped due to race conditions in the println() method. The only thing you ultimately see is the ThreadDeath exception caused by Thread.stop() forcibly terminating the thread.

Presumably, this occurs because of unlucky interaction between RobotPeer.println() and RobotPeer.readOutText().

readOutText()                                 | println()
============================================= | ===============================
final String robotText =                      |
battleText.toString() + proxyText.toString(); |
                                              | battleText.append(s);
                                              | battleText.append("\n");
battleText.setLength(0);                      |
proxyText.setLength(0);                       |
return robotText;                             |

Therefore, the solution is to add synchronized(battleText) { guards around readOutText() and println().

Or maybe I'm way off track.

Just looked at those functions showing in error stack, in checkSkippedTurn(), it says: SYSTEM: No score will be generated. before the thread is killed. Therefore the good news is that these errors should not affect your scores.

And oracle says An instance of ThreadDeath is thrown in the victim thread when the Thread.stop() method is invoked. and The top-level error handler does not print out a message if ThreadDeath is never caught.

therefore the error message you see in the console could simply because robocode caught that error to make some clean-ups.

actually robocode kills your thread when you are skipping 30 turns in a row (or if you have file access, this will be increased to 240).

It somehow affects your score if you performed very well in this round :P Ok, the impact should be really small, and sometimes it may happen when you are doing bad, so it should balance, but you know... still a strange behavior.

If the bug happens randomly, your final score shouldn't be affected at all — just getting stable slower.

I think "no score will be generated" means that affected bot will get no points. The opponent still gets points, the winner bonus is assigned as the very least.

Searching on my system and old backups I was able to find Robocode versions for 1.7.4.2, 1.8.1.0. I was also able to download 1.8.0.0 and 1.9.0.0. So I ran some experiments using Neuromaner vs RaikoMicro. Note, dev version of Neuromancer I'm using here prints out each time it gets a SkippedTurnEvent.

• I can't reproduce it in at all 1.7.4.2. All output looks perfect - every round has printed SYSTEM lines either saying win or death, and Neuromancer correctly gets win/death events. Neuromancer doesn't skip any turns.

• I can't reproduce it at all in 1.8.0.0 - not even "SYSTEM: Neuromancer 5.4 has not performed any actions in a reasonable amount of time." However there are some rounds where nothing is printed, which is very suspicious. Still no skipped turn events.

• In 1.8.1.0 I can sometimes get a "SYSTEM: Neuromancer 5.4 has not performed any actions in a reasonable amount of time.". I saw this 3 times out of 10+ battles. There are also the occasional suspicious blank rounds where Neuromancer prints nothing, and SYSTEM prints nothing. Still no skipped turn events.

• In 1.9.0.0 I can reproduce ThreadDeath exceptions. On average 1 per battle, but sometimes 0 and max I saw was 4. Average of 3 skipped turn events per battle.

To note: all of them had similar CPU constants (between 5.3ms and 5.4ms).

Other things I tried:

• Changing the GC algorithm doesn't affect the number of ThreadDeaths in 1.9.0.0

• Doing a single getDataDirectory() at the beginning of each round doesn't affect the number of ThreadDeaths in 1.9.0.0

This makes me think it is a Robocode bug - possibly multiple bugs, since we have very different behaviors here over the different versions. It also greatly worries me that bots which were fine in 1.7.4.2 have problems in new versions.

Hi Skilgannon,

Isolating robocode issues from jdk version. Would it be correct to assume that you ran everything with openjdk-8?

Yes, all OpenJDK 8

openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

Here is the old installs I used to do these tests, I'd appreciate if someone could try them on Windows as well.

Tying into what Beaming said about the sleep in the internals not happening when set to max, perhaps this has been changed since earlier versions of Robocode. However there are more things that may be an issue as well, I don't think that is the total of what is buggy here. The missing prints in a round particularly concerns me (and yes, this still happens in recent versions).

If this don't happen when running the rumble, I suggest you use -Ddebug=true command line flag for robocode, which disables skipped turns & painting limit, to temporarily "solve" this problem.

After my Roborumble@Home experienced some network error, and when the network finally recovered —

OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 9ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 20ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 25ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 13ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 37ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 41ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 28ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 12ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 18ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 27ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 10ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 43ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 16ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 24ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 13ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 72ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 81ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 44ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 19ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 7ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 37ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 47ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 79ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 84ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 5ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 6ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 11ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms
OK. MyFirstJuniorRobot vs PingPong added to queue in 4ms

there are thousands of similar logs, but when I searched the history, there are only one battle of "MyFirstJuniorRobot vs PingPong", which failed to upload and got doubled each time it failed again.

I think this must be some bug in Roborumble@Home, since the network is broken. And I see similar things quite often, although not that huge. It seems that each time a battle fails to upload, it doubles, and then two battles of the same fails to upload, it doubled again, and it grows like crazy.

Since such battles are timestamped, it would not be a problem for the sever to remove duplicates with same timestamp, uploader and pairings before adding this to queue. But what I see is that the queue got full after thousands of uploads and the battles are logged, e.g. in BottomUp's page, SuperCrazy has 160 battles, which is significantly more than anything else.

But the most important thing imo is to fix that in the client...

This has happened to me too. I fixed it when I changed my computer.=)

Do you mean by using another computer, it won't submit duplicated battles after network error? Are you still using mac on the new computer?

Yes,I still use a mac. It happened when I stopped a client before it finishes the whole iteration and then change the version.

change the version?

Sorry for not being clear. I was meaning the robocode version but I'm not sure.

I cooked up a script to fix rotten link FixingParticipantLinks please use it from time to time

This continuation of problem investigation mentioned at Thread:Talk:RoboRumble/Client java version and Thread:Talk:RoboRumble/ThreadDeath problem.

After Skilgannon patch, I can see some useful debugging info. In particular, I added output for the number of skipped turns which triggers ThreadDeath call.

I see that as many as 100 or even more skips are detected. This is when TPS slider at max. Move it to 1000 and everything is handy dandy. Note that 1000 TPS is unrealistic with my CPU constant of 6 ms. I.e. per second I can get 1/0.006 about 170 tics. So the system have no time to go to the idle state in either case. On top of it, 160 skipped turns (times 6ms), i.e. about 1 seconds of inactivity, would be noticeable with a naked eye watching the battle. I see no freeze there. So something does not add up.

Here I need the experts help. I look at the source, and the only timing mechanism I see is that within allocated time the thread must report isSleeping. But I see no time checks anywhere, i.e. no one calls for nanoTime. So how the robocode decides that the timeout is exceeded?

Could it be that java calls to robocode waitSleeping are not done correctly.

Here is one more strange thing. I switched debug=true, than I have about 300*cpuConstant to finish a tic, and I time profiled everything. My time per tic is consistently shorter with debug=true, then with debug=false (default). I know it probabilistic but ... Also, in either case my inner methods never report times exceeding 25mS, which is 5 skipped ticks at most. So how do I end up with 100 skipped tics penalty.

Also, I cannot get to ThreadDeath when I play against HawkOnFire. This is very simple and fast bot, but how does it help my bot to avoid the skipped turn penalty?

It's interesting, I actually see considerable speed difference between running at 1000TPS and max, even though my CPU constant is 5.3ms. I think this is because many ticks have much less than 1ms of calculations, and these cause a sleep in 1000TPS mode. Also, just to confirm, I also only see the ThreadDeath issues when running at max, and never at 1000TPS.

From what I remember the engine works something like this:

1. Engine triggers condition variable to release bot thread
2. Engine goes to sleep for up to CPU_CONSTANT milliseconds
3. Bot thread runs
4. Bot thread finishes, triggers interrupts to wake up engine thread early
5. Engine thread wakes up, and checks time. If time exceeded, divide time taken by CPU_CONSTANT milliseconds, subtract 1, say bot skipped this many turns, if exceeds 30 kill bot. Otherwise continue as normal.

So I'm wondering if maybe there is another thread that is delaying the engine thread from waking up, perhaps to do some maintenance (garbage collection, JIT compiler swapping out methods with optimized versions, etc). There are probably heuristics that say it is a good time to do maintenance, when switching between threads, if nothing else is available. When in 1000TPS mode these actions would happen when the sleep happens (ie. nicely scheduled, not interfering with bot timing etc), since the heuristics say it is better to work in a sleep than to not switch between threads quickly.

In my mind, the easiest way to fix this would be by also doing timing in the bot thread, and only checking the timing in the engine thread if the bot thread hasn't finished yet.

Thoughts? Does anybody see issues with my thinking here?

It does not look that item 5 is performed the way which would be reasonable (i.e. how you describe).

Have a look checkSkippedTurn() where decision about penalty is done (I believe it is actually your code :). It does not check CPU time, it makes comparison based on the internal robocode Ticks.

 int numSkippedTurns = (currentExecutionTime - lastExecutionTime) - 1;

Robocode should call something to increase time (tic) inside of robot peer. If it does not do so for a bot, that bot will be punished. I still cannot find the part of the code where time++ logic is executed. These threads drive me nuts.

So, I like your proposal to time the bot inside its thread.

Hmm, there is still a problem with my idea, robocode will still kill the thread if it doesn't respond in time.

I see two different ways to combat this:

1. Put a turnState enum with states {START, RUNNING, FINISHED} which can be polled to know if the bot thread is finished, combine this with timing in the bot thread, and then if it is finished we know it is not the bot causing the delay, so we don't kill the thread.
2. Put some small sleeps every ~100 ticks to give the JVM time to perform optimizations and cleanup without interfering with the bot threads.

These could be combined, since they attack the problem from different sides.

Can we have a quick survey about java version with which you run your litumble clients?

I see that performance of my bots dropped since I switched to java-8-openjdk for bot compilations. Plus I see ridiculosly low scores for my bot against some very simple bots at the literumble. On my machine I beat them with much bigger margin. So I suspect that there is something strange with one of the clients.

For the record, I compile everything with java-8-openjdk and run my literumble clients with java provided within this jdk.

I'm using Java 8 for my rumbles. However, it seems that some bot stopped working on Java 8? etc. MoxieBot.

I'm also using Java 8 and its features for bot development. However, I compile my bot with Java 8, then transpile the bytecode to Java 6 compatible using retrolambda, as Java 8 compiled code will generally refuse to run on lower platform.

Cross porting from Java 8 seems to be excessive, if the rest of us are running Java 8. But let's see what others are running.

But why risk getting low scores when there are someone using Java6? I think anyone who participant in rumble should make the bot compatible with Java 6 until it is not officially supported by the literumble.

Maybe what we really need is a vote for moving the minimum requirement of running rumble from Java 6 to Java 8?

> what we really need is a vote

The problem with the Robocode community is that everyone talks making changes, but no one actually does anything.

Please don't be so harsh.

Our problem that we don't have large enough community. We can count active users in two hands. You cannot expect everyone to jump on the issues right away.

At least we can make reasonably complete bug reports and see if they can be addressed.

By the way, ncj.MoxieBot 1.0 is running OK on my machine. It sometimes freezes but it seems to be the fault of the internal logic.

But all my bots are getting 100% against MoxieBot on my computer, whereas there seems to be some 50% on the rumble, which makes me think that it doesn't work as expected on Java 8.

MoxieBot is completely not working on my older machine (not the one I use to run RoboRumble). Output of MyFirstRobot vs. MoxieBot:

=========================
Round 1 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 60
SYSTEM: MoxieBot 1.0 skipped turn 61
SYSTEM: MoxieBot 1.0 skipped turn 62
SYSTEM: MoxieBot 1.0 skipped turn 132
Skipped firing solution at turn: 149
Skipped firing solution at turn: 171
Skipped firing solution at turn: 210
Skipped firing solution at turn: 211
SYSTEM: MoxieBot 1.0 skipped turn 249
Skipped firing solution at turn: 287
Skipped firing solution at turn: 469
SYSTEM: MoxieBot 1.0 skipped turn 546
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 1.1000000000000025
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 2 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 64
SYSTEM: MoxieBot 1.0 skipped turn 105
SYSTEM: MoxieBot 1.0 skipped turn 144
SYSTEM: MoxieBot 1.0 skipped turn 145
SYSTEM: MoxieBot 1.0 skipped turn 182
SYSTEM: MoxieBot 1.0 skipped turn 220
SYSTEM: MoxieBot 1.0 skipped turn 221
SYSTEM: MoxieBot 1.0 skipped turn 256
SYSTEM: MoxieBot 1.0 skipped turn 292
SYSTEM: MoxieBot 1.0 skipped turn 293
SYSTEM: MoxieBot 1.0 skipped turn 330
SYSTEM: MoxieBot 1.0 skipped turn 369
SYSTEM: MoxieBot 1.0 skipped turn 406
SYSTEM: MoxieBot 1.0 skipped turn 442
SYSTEM: MoxieBot 1.0 skipped turn 477
SYSTEM: MoxieBot 1.0 skipped turn 515
SYSTEM: MoxieBot 1.0 skipped turn 553
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.0
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 3 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
Skipped firing solution at turn: 64
SYSTEM: MoxieBot 1.0 skipped turn 104
SYSTEM: MoxieBot 1.0 skipped turn 138
SYSTEM: MoxieBot 1.0 skipped turn 212
SYSTEM: MoxieBot 1.0 skipped turn 249
SYSTEM: MoxieBot 1.0 skipped turn 283
SYSTEM: MoxieBot 1.0 skipped turn 319
SYSTEM: MoxieBot 1.0 skipped turn 320
SYSTEM: MoxieBot 1.0 skipped turn 321
SYSTEM: MoxieBot 1.0 skipped turn 356
SYSTEM: MoxieBot 1.0 skipped turn 357
SYSTEM: MoxieBot 1.0 skipped turn 393
SYSTEM: MoxieBot 1.0 skipped turn 431
SYSTEM: MoxieBot 1.0 skipped turn 468
SYSTEM: MoxieBot 1.0 skipped turn 503
SYSTEM: MoxieBot 1.0 skipped turn 504
SYSTEM: MoxieBot 1.0 skipped turn 577
SYSTEM: MoxieBot 1.0 skipped turn 616
SYSTEM: MoxieBot 1.0 skipped turn 653
SYSTEM: MoxieBot 1.0 skipped turn 688
SYSTEM: MoxieBot 1.0 skipped turn 726
SYSTEM: MoxieBot 1.0 skipped turn 727
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.3000000000000007
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 4 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 36
SYSTEM: MoxieBot 1.0 skipped turn 75
SYSTEM: MoxieBot 1.0 skipped turn 148
SYSTEM: MoxieBot 1.0 skipped turn 222
SYSTEM: MoxieBot 1.0 skipped turn 281
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.20000000000000284
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 5 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 66
SYSTEM: MoxieBot 1.0 skipped turn 102
Skipped firing solution at turn: 140
Skipped firing solution at turn: 141
SYSTEM: MoxieBot 1.0 skipped turn 178
SYSTEM: MoxieBot 1.0 skipped turn 179
SYSTEM: MoxieBot 1.0 skipped turn 214
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.10000000000000024
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 6 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 58
SYSTEM: MoxieBot 1.0 skipped turn 59
SYSTEM: MoxieBot 1.0 skipped turn 96
SYSTEM: MoxieBot 1.0 skipped turn 97
SYSTEM: MoxieBot 1.0 skipped turn 131
SYSTEM: MoxieBot 1.0 skipped turn 169
SYSTEM: MoxieBot 1.0 skipped turn 170
SYSTEM: MoxieBot 1.0 skipped turn 207
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.0
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 7 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
Skipped firing solution at turn: 102
SYSTEM: MoxieBot 1.0 skipped turn 120
Skipped firing solution at turn: 153
Skipped firing solution at turn: 154
SYSTEM: MoxieBot 1.0 skipped turn 257
SYSTEM: MoxieBot 1.0 skipped turn 333
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 92.0
Energy Fired: 0.6000000000000002
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 8 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
SYSTEM: MoxieBot 1.0 skipped turn 68
SYSTEM: MoxieBot 1.0 skipped turn 106
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.0
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 9 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
Skipped firing solution at turn: 100
Skipped firing solution at turn: 101
Skipped firing solution at turn: 102
SYSTEM: MoxieBot 1.0 skipped turn 138
SYSTEM: MoxieBot 1.0 skipped turn 177
SYSTEM: MoxieBot 1.0 skipped turn 215
SYSTEM: MoxieBot 1.0 skipped turn 254
SYSTEM: MoxieBot 1.0 skipped turn 293
Skipped firing solution at turn: 373
SYSTEM: MoxieBot 1.0 skipped turn 407
SYSTEM: MoxieBot 1.0 skipped turn 479
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.4999999999999976
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died
=========================
Round 10 of 10
=========================
C:\robocode\robots\.data\ncj\MoxieBot.data
Skipped firing solution at turn: 155
SYSTEM: MoxieBot 1.0 skipped turn 307
SYSTEM: MoxieBot 1.0 skipped turn 367
SYSTEM: MoxieBot 1.0 skipped turn 399
SYSTEM: MoxieBot 1.0 skipped turn 419
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Hit by a wave that was not being correctly tracked. Fix this!
Damage Taken: 96.0
Energy Fired: 0.8000000000000018
Hit by a wave that was not being correctly tracked. Fix this!
SYSTEM: ncj.MoxieBot 1.0 has died

I do not think that above report indicates that MoxieBot is broken. Actually, the log indicates that the bot was working and was reporting sensible things. The part about

SYSTEM: ncj.MoxieBot 1.0 has died

is due to its logic: MoxieBot does not fire when there are no bullets in the air. If the other bot runs out of energy, then they both wait and robocode gives an energy penalty kick after certain "no fire" timeout. Eventually they both killed by penalty energy drain, which is reported as "has died".

I played MoxieBot in the GUI it gives similar log entry while it is moving and firing.

In the log above, there are 25 lines of "Hit by a wave that was not being correctly tracked", indicating MoxieBot losing energy. That would be consistent with MoxieBot stalling and MyFirstRobot getting a 100% hitrate on it. MyFirstRobot fires 1.0 power bullets, which cause 4.0 damage, and 100 / 4 = 25 hits to kill = 25 log messages.

I also made a video of MoxieBot vs. TrackFire on that computer. It stalls for 2 rounds, but works on the other 8. It doesn't seem so bad when not minimized.

I wonder if the bug is that MoxieBot loses its radar lock and cannot regain it, which wouldn't be that hard of a fix...

openjdk8 here, on Linux.

java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

JDK 9 on Mac. Having the same problems with you.

java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

on Windows 10.

Java 1.7, as I just use an older unused computer for it. Some bots don't run in the rumble, but those battles are not even fought, so no pollution of the stats. I plan to update to Java 1.8 later this week.

openjdk8

Ok. Among recent literumble clients uploads we mostly have java8. The only exceptions are Dsekercioglu and GrubbmGait, we also have uncertainty on Anonymous uploads. GrubbmGait did not make uploads more recent than 4 days old, while I have score glitches on more recent releases. It could be abnormality in Java9.

One more thing. If I run GUI client at full speed with debug graphics toggle off, from time to time I see a error message in console from robocode 1.9.2.5 about java Threads dying. In such battles my score drops a lot, strange thing that it is not directly related to skipped turns counts. It could be a bug in robocode itself.

Does anyone see such phenomenon?

@ Dsekercioglu, would you mind switching off you liteclient for a while? Let's see if we can pinpoint the issue to java9 glitches.

@ all, if you are not running java8, please do not run liteclient for a week, starting from 2017/09/04.

Okay I'm closing it.

Or you can just use two versions in parallel ;) For me I develop my bot and run the rumble on Java 8, but I always test it on Java 6 before every release to make sure it works.

Just install them in different directories, and call java executable with the correct directories when starting robocode/roborumble.

Would adding a bot written with JDK9 and compiled with robocode would create a problem if there was an error with JDK9?

If there is an error in JDK, than sure it will be a problem.

But there might be a problem with JDK9 compilation, even if jdk9 itself is good, if the rest of us run literumble with java8. You bot might even not start in our clients.

Couple years ago when java transitioned from java 6 to java 7, we had this issue in rumble. People who made their bots with more recent java were in disadvantage and their bots showed a lower score.

I would suggest to cross compile your bot to java8 version, since according to the poll the rest of us run java8. Or go to extremes and make it compatible with java7 via retrolambda, as User:Xor does.

Java 7 compatible is a very good idea, I am on 1.7_051 (but intend to go to JDK 8 in the near future) and can't run battles for a handful of bots. Just look at the missing pairings of GrubbmThree 0.9a. Btw, other clients should do those, why don't they. But it seems that there are also a few bots that can't handle a Java 8 client, like tcf.Drifter and sm.Devil (see comparison between GrubbmThree and MaxRisk)

Yeah, I have exactly the same issue, but since I never saw anyone complain about this, I just ignored it. I can reproduce the issue with 1.9.2.6 as well.

I spent a lot of time reading Robocode's source trying to find a connection between that and skipped turns with no real success. Perhaps Skilgannon, which seems to be strongly related to how Robocode evaluate skipped turns as it is today, could share his thoughts about this.

When testing it with Roborio, there were a few times I fixed the running speed at 1000 TPS and could see skipped turn messages instead of these Thread errors, but this only happened when using my old GoTo code, which was really slow. I can't see skipped turn messages with Roborio 1.2.4, for example.

Then I tried to run Neuromancer with the same setup and could see a lot of these Thread dying errors as well, despite seeing no skipped turn messages when locking at 1000 TPS.

What is weird is not that the crashes are occurring at all. Maybe they really make sense. But the thrown exception instead of a helpful message is somewhat weird.

I sometimes see the ThreadDeath things as well, it seems completely sporadic. I can't reproduce it at all with the current dev version.

A possible issue is the platform it is run on. Windows has a system timer with a very coarse tick (30ms IIRC). We had to use the nanosecond timer in chunks of 0.999999ms to emulate the larger timer. Maybe this nanosecond timer is broken in later releases of Oracle JDK.

So I'm curious: the people who are seeing Moxiebot broken, are you running Windows? Are you using Oracle JDK or OpenJDK?

So, I was little distracted when I read the source for the first time. Now I've read it again.

This error is thrown when the bot must be stopped because it skipped too many turns in a row, since Thread.stop() is deprecated. Is that right? I can safely assume that if this error appears, then the bot has skipped too many turns in a row?

My only doubt is (it's more like a curiosity than anything else): what may cause the robot to skip this amount of turns when going full speed and not to skip any turns when going 1000 TPS?

I'm on OpenJDK 8 and Ubuntu, by the way.

Perhaps we should all give more details about how we run the rumble client.

I run RoboRumble intermittently, not continuously (only when I see interesting new bots added to the participants list). So far, I've only run roborumble (not meleerumble or others), but that may change soon. (Edit: As of September 5, 2017 8:49 PM CET, I have started running meleerumble). It's running on my everyday-use computer, and not a dedicated machine. Sometimes I run Robocode battles or browse to CPU-intensive webpages, and that may cut into the amount of CPU the client gets. My CPU constant is 6500859 ns (6.5 ms) per turn. I have a 4-core machine, and RoboRumble tends to take up 30-60% CPU constantly. It takes about 15 minutes to execute 50 battles.

Seriously though, if your robot is incompatible with certain setups, the fault lies in your robot. Perhaps you should respond to SkippedTurnEvents by reducing the amount of computation your robot performs.

Running the rumble client on an ultrabook when I'm not using it and it is plugged into power. Often it uses 2 cores even with a single client. CPU constant is about 5.3ms in openjdk8 using Linux.

About the skipped turn thing, I agree. A big part of Robocode is how long you have to do your processing in. It is a massive tradeoff and I know some of my bots occasionally step over the edge. However, I also don't want to change the rules of the competition. If there is something in Oracle JDK8 that is killing certain bots we need to figure out what that is.

I am not arguing that heavy on skipping bots should not be punished, my complain that it is erratic and seemingly coming from Java itself. Looks like it shows when a heavy bot is matched against a low CPU demanding one.

By the way, sometimes it to my advantage. I see strange unexplainable APS gain in melee against 'sgp.JollyNinja 3.53' [1]

Note that my v7.4 is very mediocre when compared against v6.1, except one case JollyNinja.

Heavy vs light causing problems sounds to me like a race condition. And I think this might even be a separate issue from MoxieBot getting 0. This clearly needs further investigation.

I took a look at your results. Your bot is performing below expectations, most prominently with 37.71% survival against sample.Crazy (???), which I cannot reproduce on my own computer.

I do agree that bugs (particularly ones that produce unfair results) ought to be squashed ASAP. However, you cannot expect the amount of work-per-turn your bot is allowed to perform to remain constant between machines (and possibly not even between battles or rounds). Perhaps a CPU-intensive background process is running, or the user decides to play video games, or the OS starts throttling Java, or the CPU drops to 0.15 GHz for no good reason (I've actually seen that happen), or gamma rays hit your computer and flip a bit in the tick time counter, or whatever.

My point was that high-CPU bots must adapt to changing circumstances. Too many bots just ignore SkippedTurnEvent, when it's practically a blaring flashing-red-lights warning from Robocode. You could respond by reducing CPU load, e.g. disabling features, virtual guns, second wave surfing, etc. It's better for your bot to function suboptimally than to not function at all.

Agreed that the SkippedTurnEvent is mostly ignored, and that more could be done on this side. However, there is a reason that we have the CPU calibration, and that is because we want all environments to be similar. It is impossible to get consistent results if on one computer you can do second wave surfing with precise intersection and KNN gun with Gaussian kernel density estimation, and the other you have to fall back to single wave and a simple VCS gun. It would require all rumble battles to be contributed by a single machine, and then we are back to a standard environment.

Are we actually talking about time-per-turn problem? I supposed, given the age of Robocode and Roborumble, that this is a well discussed topic and that every possible decision to make the system work fair enough while providing the "contributing" feature was already made. It seems that what we are talking about here is a bug. I know every environment is not equal, but even with the very little time I have on Robocode I could conclude a robot should work under the assumption that at least a reasonable quota of its turn time will be respected (even if in reality it's not eventually). If that quota is not being respected even after like, 10 battles, in a machine that is OK, and the results are absurd like the results Beaming reported, there must be a bug somewhere, even if it's on Beaming's side, and IMO it's worth it to discuss it and, maybe, to find it, since it may explain some other weird behavior in the future.

Here is my setup,

I run literumble clients on two machines almost non stop. Each runs one rumble and one melee client at the same time. Since one has 4 cores and the other 6, this should not be a problem with CPU calculations under normal circumstances. Also, there is plenty of RAM so no swapping. If I expect high CPU demanding tasks, I stop clients so they not affected by CPU fight with other programs.

All my machines are 64 bit linux with openjdk-8-jdk-headless.

But I think at some point robocode became multi-threaded, so CPU constant (6.5 ms in my case) is not so relevant anymore. In top, I can see that rumble client often eats more than 100%, i.e. it spans between cores. Also, load on a machine seems to be high, i.e. it is often in the range of 3 for the 6 cores machine.

Plus there is CPU throttling which kicks in when ever it wants, thanks to modern hardware design.

I don't think Robocode actually runs more than 1 thread at a time. I think the extra CPU is from the JVM JIT optimizer running in parallel.

I meant the whole robocode machinery. I recall that couple years ago the robocode client (and its java) was confined to one CPU, today it is not the case. See the attached screenshot.

I have a hunch that I would like to test. Never mind. That idea was almost definitely wrong.

My server is running CentOS, is that supported? If I'm running roborumble client on server, is there anything to be special cared?

Is that ok to use Java 8 sdk to run roborumble?

It seems that robocode-1.9.2.5-setup.jar doesn't not support platform without X11?

How to install robocode without X11?

The installer is a JAR file, which is just a renamed ZIP file.

Use a standard unarchiver to extract libs/, roborumble/, robots/, and [roborumble/meleerumble/teamrumble/twinduel].sh into a folder.

Thanks! Done!

Hi mates,

Did anyone noticed problems with rumble clients downloading github hosted bots? For example

https://github.com/realr2d2/Bots/blob/gh-pages/pbg.NinjaX_1.2.jar

I can download this bot via browser or wget, but the rumble client is failing on it. I get the following error

Could not connect to https://github.com/realr2d2/Bots/blob/gh-pages/pbg.NinjaX_1.2.jar
Could not download pbg.NinjaX_1.2.jar

I find the problem. Looks like github changed the raw download url. Now we have to add to the file name the following suffix

?raw=true

I.e. old github jar urls need to be converted from something like

https://github.com/realr2d2/Bots/blob/gh-pages/pbg.NinjaX_1.2.jar

to

https://github.com/realr2d2/Bots/blob/gh-pages/pbg.NinjaX_1.2.jar?raw=true

Weird part that some github links works as before. For example

https://github.com/aleksey-zhidkov/rc-repo-mirror/raw/master/agrach.Dalek_1.0.jar

What is wrong with github?

Hey, I've been trying to archive the RoboRumble rankings for a few days now, and the RoboRumble (General 1v1) and all four MeleeRumbles are still unstable. I haven't seen any new entrants. Is it common these days to go this long without having a stable ranking? And is it just a matter of people running clients? I tried to fix the problems I saw in the participants lists (based on the auto-tweeter's activity). I don't have a real client setup right now, or I'd run it myself.

Would you mind elaborating on "unstable ranking" definition?

I think there is only one new bot AgentSmith which is probably unsettled in ranking, but the were no new bots for months, so it should be ok otherwise.

Unfortunately, no one actively/constantly running rumbles. May be I should restart my clients...

Oh, I specifically mean that not all bots have faced each other. The LiteRumble rankings pages say so right at the top. (I think they're using the same definition as my archiving script...)

I see. the jcs.Decepticon 2.5.3 missing one battle in the rumble.

I was browsing LiteRumble and noticed the survival scores between Combat and LifelongObsession, FloodSonnet, HariSeldon, Prophet, RCBot are abnormally low.

If you look the opposite scores in the 5 opponent profiles, they are also low.

Ran the battles locally and the scores don't match.

Most likely the version of Robocode the server allows is out of date

The server doesn't use Robocode. It simply processes battle results sent by clients. Numbers from 0 to 35 in the case of survival scores.

I know the server throws results away sometimes. It records results on one side of the pairing, but not the other. In an attempt to decrease the number of database accesses and cloud service fees.

But it only reduces the amount of battles. Would explain a low number of battles, but not low scores on all battles.

Ran the battles locally using 1.9.2.3. Still the scores don't match.

Combat can work with much older versions too.

But why wrong scores with only a few pairings? Version issues usually affect the whole ranking.

There is a possibility that battle submitted client has different result when compared to your machine. For example less available memory or different java version. So if your algorithm is CPU intensive it might be forced into the "skip turn" regime and then score will be very low.

For the last year my machines were major battle submitters and I use to run them with old Java, so if yours was compiled with newer Java it would automatically lose, since it would not be able to fight.

I do not think that it is robocode version issue, but I recall that there we some glitches with reporting when we moved from 1.8 to 1.9. I think the only fix in 1.9.1 to 1.9.2 was in the score submission.

I just want to say thanks to everybody who has been contributing battles - the rumble has been *extremely* quick to stabilise over the last few days, and I've been making the most of it =)

I've also finally gotten around to banning 1.7.4.2 clients, so only 1.8.1.0 for the foreseeable future. Although from the looks of it, the meleerumble might need a reset, since Neuromancer 3.4 isn't stabilising anywhere near where it was before.

I can't promise that machine will always be available for RoboRumble clients, but it has been lately and I'm certainly happy to contribute. :-)

Hi Skilgannon, I am newbe with Robocode. I tried to run a client with Robocode 1.9.1.0, it succesfully take 50 battles, but when trying to upload results, it receive the message: "OK. CLIENT NOT SUPPORTED. Use one of: [1.8.1.0, 1.8.2.0]

not 1.9.1.0. What am I doing wrong?. Thanks in advance for your help.

Yarhoslavme, for now, the only way to contribute is to comply with a message and use robocode version either 1.8.1.0 or 1.8.2.0

But where do you get 1.8.2.0 or 1.8.1.0

Dan Lynn posted on a G+ post that the repository is coming back up: [1]

For me it did. It's running fine after a bad crash for months.