Client java version
The highlighted comment was created in this revision.
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?
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.
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)
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.
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.
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.
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. 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.