Talk:RoboRumble

From RoboWiki
Jump to: navigation, search

Sub-pages: /Archive20130317

RoboRumble history

April 27 2005 - The RoboRumble@Home server is now moved to Pulsar's machine. See /TemporaryServerUp for the RR@H settings files to use and some more details. The only difference you should note is that the flag-less bots no longer have the Jolly Roger flag. This is temporary and will be fixed soon. Huge thanks to Pulsar for carrying the burden (reponsibility-wise) a while with this. I'll sleep tighter now when I don't need to worry if my WinXP Home PC (yes, it was hosted in such an environment before!) is awake and responsive. -- PEZ

October 28 2005 - The RoboRumble@Home server will be down for several hours for upgrades tomorrow (Saturday Octber 29). As a side effect this will solve the issues some people have with port 8080. --Pulsar

October 29 2005 - The RoboRumble@Home server is going down shortly and will be up and running again within 12hours hopefully. -- Pulsar

October 29 2005 - The RoboRumble@Home server is up and running. Updates are needed for RoboRumble@Home clients. -- Pulsar

February 18 2006 - The RoboRumble@Home server connection might experience some downtime the following hours as I will reorganize the firewall setup. --Pulsar

March 7 2006 - The firewall switch over has now finally been done, and everything seems to be working. Some people might experience a short delay until DNS records have been updated around the world (though they were and are set to a very short "time to live" to minimize this). RoboRumble@Home clients need to be restarted as Java by default caches DNS lookups. --Pulsar

Contents

Thread titleRepliesLast modified
Script to fixup rotten participant jar file links003:01, 8 September 2017
ThreadDeath problem and large amount of skipped turns321:20, 7 September 2017
Client java version4918:44, 6 September 2017
ThreadDeath problem2801:28, 6 September 2017
How can I deploy roborumble client on a server?302:00, 21 August 2017
Troubles with github hosted bot215:17, 19 August 2017
rankings not stable300:38, 1 August 2015
Wrong survival scores for some pairings416:00, 23 May 2015
Contributors503:23, 18 April 2014
RobocodeRepository coming back123:23, 2 October 2013
Superpack112:56, 2 June 2013
Robot Count1014:54, 16 April 2013
RoboRumble Rules1219:34, 14 April 2013
Darkcanuck's server down522:52, 16 March 2013
Uploads for retired robots214:24, 16 February 2013
30 day battle records4914:13, 14 February 2013
Darkcanuck.net down?323:37, 13 February 2013
Version 1.7.3.6?614:05, 15 October 2012
Rumble Client 1.7.3.2 vs 1.7.3.0415:45, 26 June 2012
1.7.3.6110:43, 1 May 2012
First page
First page
Previous page
Previous page
Last page
Last page

Script to fixup rotten participant jar file links

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

Beaming (talk)03:01, 8 September 2017

ThreadDeath problem and large amount of skipped turns

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?

Beaming (talk)18:38, 7 September 2017

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?

Skilgannon (talk)19:54, 7 September 2017

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.

Beaming (talk)20:45, 7 September 2017

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.

Skilgannon (talk)21:20, 7 September 2017
 
 
 

Client java version

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.

Beaming (talk)02:03, 4 September 2017

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.

Xor (talk)03:45, 4 September 2017

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.

Beaming (talk)04:20, 4 September 2017

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?

Xor (talk)09:18, 4 September 2017

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

MultiplyByZer0 (talk)09:58, 4 September 2017

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.

Beaming (talk)14:25, 4 September 2017
 
 
 

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.

Beaming (talk)04:24, 4 September 2017

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.

Xor (talk)04:57, 4 September 2017
 

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
MultiplyByZer0 (talk)19:24, 4 September 2017

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.

Beaming (talk)00:31, 5 September 2017

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

MultiplyByZer0 (talk)01:37, 5 September 2017
 
 
 
 

openjdk8 here, on Linux.

Skilgannon (talk)06:26, 4 September 2017
 

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)

Cb (talk)08:14, 4 September 2017
 

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

Dsekercioglu (talk)08:33, 4 September 2017
 
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.

MultiplyByZer0 (talk)09:36, 4 September 2017
 

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.

GrubbmGait (talk)10:11, 4 September 2017
 

openjdk8

Rsalesc (talk)10:47, 4 September 2017
 

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?

Beaming (talk)14:20, 4 September 2017

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

Beaming (talk)14:27, 4 September 2017

Okay I'm closing it.

Dsekercioglu (talk)14:28, 4 September 2017

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.

Xor (talk)14:42, 4 September 2017
 

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

Dsekercioglu (talk)11:27, 6 September 2017

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.

Beaming (talk)14:19, 6 September 2017

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)

GrubbmGait (talk)15:43, 6 September 2017
 
 
 

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.

Rsalesc (talk)14:34, 4 September 2017

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?

Skilgannon (talk)18:01, 4 September 2017

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.

Rsalesc (talk)00:38, 5 September 2017
 
 
 
Edited by author.
Last edit: 19:54, 5 September 2017

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.

MultiplyByZer0 (talk)15:33, 4 September 2017

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.

Skilgannon (talk)17:43, 4 September 2017

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.

Beaming (talk)18:09, 4 September 2017

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.

Skilgannon (talk)18:39, 4 September 2017
 

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.

MultiplyByZer0 (talk)19:18, 4 September 2017

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.

Skilgannon (talk)21:36, 4 September 2017
 

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.

Rsalesc (talk)00:13, 5 September 2017
 
 
 

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.

Beaming (talk)18:16, 4 September 2017

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.

Skilgannon (talk)18:41, 4 September 2017

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.

htop screenshot

Beaming (talk)01:14, 5 September 2017
 
 
 

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

MultiplyByZer0 (talk)23:39, 4 September 2017
 

ThreadDeath problem

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
=========================
Beaming (talk)01:41, 5 September 2017

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.

Xor (talk)02:21, 5 September 2017

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?

Rsalesc (talk)02:35, 5 September 2017

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.

Beaming (talk)03:33, 5 September 2017

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.

Rsalesc (talk)11:51, 5 September 2017
 

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.

Beaming (talk)18:45, 5 September 2017
 

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

Beaming (talk)03:24, 5 September 2017

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.

Xor (talk)04:17, 5 September 2017
 

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?

Rsalesc (talk)13:45, 5 September 2017

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

Xor (talk)14:14, 5 September 2017

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.

Beaming (talk)17:26, 5 September 2017
 

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();        }
    }
}
MultiplyByZer0 (talk)17:48, 5 September 2017

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.

MultiplyByZer0 (talk)19:46, 5 September 2017
 
 
 
 

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

Xor (talk)04:33, 5 September 2017

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.

Rsalesc (talk)11:48, 5 September 2017

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

Xor (talk)12:08, 5 September 2017
 

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.

Beaming (talk)13:32, 5 September 2017
 

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.

Skilgannon (talk)18:58, 5 September 2017

Hi Skilgannon,

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

Beaming (talk)19:14, 5 September 2017

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)
Skilgannon (talk)19:19, 5 September 2017
 

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

Skilgannon (talk)19:16, 5 September 2017
 
 

How can I deploy roborumble client on a server?

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?

Xor (talk)00:32, 21 August 2017

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

How to install robocode without X11?

Xor (talk)00:47, 21 August 2017

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.

MultiplyByZer0 (talk)01:07, 21 August 2017

Thanks! Done!

Xor (talk)02:00, 21 August 2017
 
 
 

Troubles with github hosted bot

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
Beaming (talk)14:33, 19 August 2017

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
Beaming (talk)14:52, 19 August 2017

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?

Beaming (talk)15:17, 19 August 2017
 
 

rankings not stable

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.

Voidious (talk)23:10, 31 July 2015

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

Beaming (talk)23:45, 31 July 2015

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

Voidious (talk)23:58, 31 July 2015

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

Beaming (talk)00:38, 1 August 2015
 
 
 

Wrong survival scores for some pairings

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.

MN (talk)01:18, 17 May 2015
Edited by author.
Last edit: 01:33, 23 May 2015

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

Tmservo (talk)20:56, 22 May 2015

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.

MN (talk)01:12, 23 May 2015
 

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.

MN (talk)13:40, 23 May 2015

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.

Beaming (talk)16:00, 23 May 2015
 
 
 

Contributors

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.

Skilgannon21:18, 5 May 2013

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

Voidious21:49, 5 May 2013
 

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]

Yarhoslavme (talk)20:20, 28 March 2014

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

Yarhoslavme (talk)20:22, 28 March 2014

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

Beaming (talk)01:31, 29 March 2014

But where do you get 1.8.2.0 or 1.8.1.0

Tmservo (talk)03:23, 18 April 2014
 
 
 
 

RobocodeRepository coming back

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

Voidious (talk)14:57, 13 September 2013

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

BeastBots (talk)23:23, 2 October 2013
 

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

MAESchortens (talk)12:44, 2 June 2013

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

Skilgannon (talk)12:56, 2 June 2013
 

Robot Count

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

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

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

Chase07:00, 13 April 2013

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

GrubbmGait13:09, 14 April 2013

It could use the honor system, like the twinduelrumble.

Sheldor19:08, 14 April 2013
 

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

Voidious19:11, 14 April 2013

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

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

Sheldor15:55, 15 April 2013
 
 

I noticed this a while ago.

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

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

Sheldor19:07, 14 April 2013
 

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

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

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

Chase09:05, 15 April 2013
 

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

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

Voidious14:25, 15 April 2013

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

Sheldor16:00, 15 April 2013
 

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

Chase01:21, 16 April 2013
 

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

Voidious14:54, 16 April 2013
 

RoboRumble Rules

Where can i find the rules for roborumble?

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

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

Letscode133712:45, 27 March 2013

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

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

Voidious13:21, 27 March 2013
 

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

Chase14:52, 27 March 2013
 

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

Voidious15:23, 27 March 2013
 

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

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

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

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

MN16:38, 27 March 2013

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

Sheldor19:34, 14 April 2013
 

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

Chase03:48, 28 March 2013
 

thanks for your replys! :)

what works in robocode will work in roborumble right?

Letscode133710:19, 28 March 2013
 

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

Skilgannon10:51, 28 March 2013
 

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

Letscode133713:26, 28 March 2013
 

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

Skilgannon13:37, 28 March 2013
 

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

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

Voidious13:49, 28 March 2013
 

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

Letscode133713:56, 28 March 2013
 

Darkcanuck's server down

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

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

Voidious14:23, 16 March 2013

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

MN20:05, 16 March 2013
 

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

Voidious20:22, 16 March 2013

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

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

MN22:46, 16 March 2013
 

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

Voidious22:52, 16 March 2013
 

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

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

Skilgannon20:24, 16 March 2013
 

Uploads for retired robots

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

Skotty13:24, 16 February 2013

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

Chase14:12, 16 February 2013
 

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

Voidious14:24, 16 February 2013
 

30 day battle records

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

Voidious18:53, 26 January 2013

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

Skilgannon06:53, 27 January 2013

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


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

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

MN13:12, 30 January 2013
 

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

Chase13:45, 30 January 2013

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

MN14:50, 30 January 2013
 

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

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

Voidious14:53, 30 January 2013

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

MN16:07, 31 January 2013
 

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

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

Chase00:16, 31 January 2013

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

MN16:14, 31 January 2013
 

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

Chase04:46, 1 February 2013

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

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

MN16:56, 1 February 2013
 

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

Skilgannon17:22, 1 February 2013
 
 

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

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

Voidious03:20, 31 January 2013
 

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

Skilgannon13:52, 31 January 2013

Finally a supporter!

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

Chase04:49, 1 February 2013

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

MN16:50, 1 February 2013
 

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

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

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

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

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

Chase04:13, 2 February 2013

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

How I think a good rumble protocol would work:

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

- Client uploads participants list to rating server.

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

- Client downloads missing participants.

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

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

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

MN14:46, 2 February 2013
 
 
 

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

Sheldor18:23, 31 January 2013
 

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

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

Tkiesel19:40, 31 January 2013

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

Sheldor20:11, 31 January 2013
 

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

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

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

MN20:20, 31 January 2013
 

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

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

Chase04:44, 1 February 2013

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

MN16:46, 1 February 2013
 

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

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

Voidious16:51, 1 February 2013
 

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

Chase02:06, 2 February 2013
 

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

Voidious02:24, 2 February 2013

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

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

Sheldor02:44, 2 February 2013
 

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

Voidious02:46, 2 February 2013
 

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

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

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

Skotty14:54, 2 February 2013
 

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

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

Voidious16:48, 13 February 2013

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

Skilgannon20:23, 13 February 2013
 

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

Voidious20:26, 13 February 2013
 

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

Voidious20:51, 13 February 2013
 

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

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

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

Voidious21:33, 13 February 2013
 
 

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

Chase02:33, 2 February 2013
 
 

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

GrubbmGait13:33, 27 January 2013
 

Darkcanuck.net down?

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

Skilgannon21:41, 13 February 2013

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

Voidious21:43, 13 February 2013
 

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

GrubbmGait21:54, 13 February 2013
 

It's back up.

Voidious23:37, 13 February 2013
 

Version 1.7.3.6?

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

Rednaxela18:28, 14 May 2012

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

Skilgannon19:00, 14 May 2012
 

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

Skotty03:21, 14 October 2012
 

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

Voidious03:24, 14 October 2012

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

MN13:55, 15 October 2012
 

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

Skilgannon14:05, 15 October 2012
 

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

Skotty05:57, 14 October 2012
 

Rumble Client 1.7.3.2 vs 1.7.3.0

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

Take Care

Wompi08:59, 26 June 2012

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

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

MN13:35, 26 June 2012
 

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

Wompi15:27, 26 June 2012
 

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

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

Voidious15:30, 26 June 2012
 

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

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

Wompi15:45, 26 June 2012
 

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

Thank you!

Skilgannon10:16, 1 May 2012

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

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

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

Wompi10:36, 1 May 2012
 
First page
First page
Previous page
Previous page
Last page
Last page
Personal tools