Talk:RoboRunner

Quoted from APS:

The server calculates APS for each bot by:

1. taking the average percentage score of all battles against each opponent separately to get an APS for each pairing,
2. then averaging all pairing scores to obtain the final average.

Formally, it's

mean(challenger_score / total_score)

for each pairing.

LiteRumble seems to follow this algorithm.

However, RoboRunner is using:

sum(challenger_score) / sum(total_score)

instead for each pairing.

This causes scores calculated by RoboRunner to be different from LiteRumble.

Here is a Python script that calculates APS correctly. Use this script when you want to align with LiteRumble.

import os
import gzip
import xml.etree.ElementTree as ET

from statistics import mean
from collections import defaultdict


roborunner_dir = os.path.expanduser('~/roborunner')  # replace with your roborunner directory


def get_aps_dict(bot):
  scores = ET.parse(gzip.open(f'{roborunner_dir}/data/{bot}.xml.gz', 'r')).getroot()

  aps_raw = defaultdict(list)

  for bot_list in scores:
    for battle in bot_list:
      battle_scores = {}
      total_score = 0

      for robot_score in battle.findall('robot_score'):
        name = robot_score.find('name').text
        score = int(robot_score.find('score').text)
        battle_scores[name] = score
        total_score += score

      aps = 100 * battle_scores[bot] / total_score

      for name, _ in battle_scores.items():
        if name != bot:
          aps_raw[name].append(aps)

  return dict((name, mean(aps)) for name, aps in aps_raw.items())

Update: The APS fix is now included in the newest release of my fork. A PR is also made to Voidious’s version.

Did this fix also apply to melee score calculation? I've been having difficulty getting my offline results with roborunner to align with literumble for the nano melee rumble.

Yes, the definition of APS applies to all of the rumbles.

I think I've solved this now, it looks like the problem was with the way I was generating battles.

I wrote a custom GUI for RoboRunner, it directly interfaces with a modified RoboRunner. It is in early early alpha. The feature set is nowhere near complete. Please let me know of any bugs.

Robots are not automatically copied to robocode directories. Nothing is saved. Paths cannot (at the moment) be altered. Results do no update automatically, they need to be closed and reopened to update them (I plan to fix this). Thread count cannot be changed after starting (for now, changing this would be involved).

https://github.com/Chase-san/RoboRunner-GUI/releases

I guess I should mention its advantages over RoboJogger, the other GUI for RoboRunner, also over RoboRunner itself.

It has a queue that runs challenges in whatever order they happen to be in the queue. This means once you start it, you can run multiple challenges without robocode needing to restart, and you can also reorder the queue after starting the battle threads.

It is better to consider it's limitations compared to RoboResearch. Aside from the first post, you cannot start and stop threads individually. I may support this eventually, but at the moment it would require rewriting RoboRunner's BattleRunner class. Which also means once you start the threads, you cannot alter the number of threads running.

Congrats on the first release! I'll try to have a look tonight or tomorrow.

Do we need any setup instructions? Or are the roborunner.properties and empty Robocode installs already in the zip?

I am working on automating the runner creation and robot jar copying process today. As well as adding an options dialog to configure the paths and jvm arguments.

The GUI won't use the properties as the standard roborunner. But the current version doesn't use any at all.

But for the current version, you need to create the robocodes/r[0-9]+ directories yourself (or use the script you wrote). You can pick the thread count in the program itself (but only up to the number of runners you created). Make sure to copy the robots into robocodes/r[0-9]+/robots directories as well.

v0.9.2-Alpha

Adding options (that save), automatic robocode runner creation (based on threads), and automatic robot jar copying.

I'm curious what kind of speed improvements people have seen, if anyone keeps track. Today, in the midst of developing my own UI for RoboRunner, I decided to do a test run to compare RoboRunner vs RoboResearch. I ran MC2K7 Fast Learning challenge against XanderCat 11.6. All data was cleared from the robots directory in both tests. 2 Threads in both cases. RoboResearch ran in 5:30. RoboRunner ran in 3:50. That's about a 30% speed improvement -- pretty dramatic. With dirty data directories where there is a lot of past data, I bet the speed difference would be an order of magnitude more significant. RoboResearch can get pretty slow starting up battles when you haven't cleared out the data for awhile. Results will vary based on the data directories and what kind of robots are being run, but regardless, I think anyone using RoboRunner will see a noticeable speed boost. Very nice.

RoboResearch has an annoying problem when bots print something in the console. The clients crash and the threads become stuck in paused mode. You have to recreate the clients manually. So, RoboResearch is a lot more than 30% slower.

I actually hopefully just fixed the problem about the threads pausing. I still use RoboResearch since getting RoboJogger/RoboRunner to cooperate is difficult at times.

If possible I wouldn't mind hammering RoboRunner into RoboResearch, since aside from a few bugs it works rather well.

How should we be computing the number of completed seasons with smart battles?

When scores are loaded from the ScoreLog, the bullet damage score (which the BULLET_DAMAGE score type relies on) is always 0 for the opponent. Is this a bug in RoboRunner -- either the scores not getting saved correctly or loaded correctly by the ScoreLog? I also noticed that the energy conserved values were also 0 for both the challenger and opponent, so may be a related bug there too.

Okay, this wasn't a bug. It was because it was an opponent who wasn't firing bullets.

Please provide a simple UI for this. All attempts I have made to run this on windows have met with extreme aversion and then failure.

I got it setup, installed, and finally detecting the correct classes (multiple reasons why this was failing). But then it constantly complained I was not defining the robot to run, the challenge or so forth. I was do all of those, in the exact same format presented in the help examples. I made sure. In the meantime I have switched back to RoboResearch, which works.

It doesn't have to be a comprehensive UI. A simple program that runs the console command for (to remove human error) would be perfectly acceptable. Probably two file browse boxes and a number spinner for seasons.

That way we know its a problem with the program if it doesn't work.

I could probably build a Java UI to launch it. Skotty

I'm now working on a Java user interface for RoboRunner that I call the RoboJogger UI for RoboRunner (or just RoboJogger). I have past experience writing Java Swing applications and also prefer having a UI rather than just a command line tool, so this is a good project for me. I don't have nearly as much free time as I would like, so it may be a few weeks before I have it up and running, but I can keep anyone who is interested up to date on my progress. Skotty

Would be very cool to see a nice UI, please do keep us up to date. :-) I think the main thing I'd want to make sure a UI could do is to queue up multiple runs at a time, which is easy to overlook and comes for free (with shell scripts) with the command line version.

When I was considering a UI, my main idea was to make it a web interface. In part because that seems simple, portable, and like something I know how to do, and also because it would offer remote monitoring and access for free. I know I like to check on/alter long running tests while I'm out sometimes. But others may not be as OCD as me and prefer a more native UI.

A WebUI doesn't actually seem like that bad of idea actually.

Just peeked at RoboRunner distribution package a while ago. It would be nice if initial setup was made inside java code instead of a shell script. So Windows users don't have to port the scripts.

Argh, sorry about that. When I wrote the setup, it made a lot of sense to use a shell script instead of spending 10x the time to write it in Java, since I wasn't even sure anyone else would ever use it. But at this point Windows setup support is probably the most glaring omission. A batch file might work, but I don't have Windows to test on so I guess I should go with Java.

I have Windows, but wasn´t willing to port de scripts. :P

Laziness combined with a working RoboResearch setup makes everything harder.

Does RoboRunner support team battles (1200x1200 battlefield)? Or does it support custom battlefield sizes?

Trying RoboResearch I noticed battlefield sizes are hard-coded at 800x600 or 1000x1000, and there is no place to configure battlefield sizes in .rrc files.

Yep, both work fine. To modify battle field size, just add width and height on their own lines after the "num rounds" line in the challenge file. And if your team JARs are in the bots/ dir, just specify them like you would a bot in the challenge file. So e.g.:

My Teams Test Bed
PERCENT_SCORE
35
1200
1200

abc.ShadowTeam 3.83
gimp.GimpTeam 0.1

Ouch, I may have spoken too soon. I'm seeing an exception when I try to run a team battle right now. I'll try and see if I can figure that out, I don't think I needed to do anything special originally to support teams.

Ok, figured it out. Turns out Robocode is a bit confused between getRobotNameAndVersion() vs getTeamLeaderName() in results of a team battle. So I need to use getTeamLeaderName() instead (and for non-teams they return the same). I'll post a fix now.

Ok, posted 1.2.3 with a fix.

Hi mate. I'm not sure if i can bother you to have a look at the roborunner changes i made. Maybe the development state is a little to early, but i would like to know what you think.

What is new:

• configuration - included, no need for external scripts and Windows should be supported as well
  • just type CONFIG and go through the options
  • this will make all internal robocode directories (depended how many installations you want)
  • it should be quite fail prof and checks the input for validity
  • you also can re configure it if you want to switch to another robocode version or something
• challenges - can be switch on the run
  • type CHAL to go through the options
  • the challenge file format should be the same as it where before
  • all missing bots will be copied to the instances (well not new but it works like before)
• the processes stay initialized
  • that means if you have once started the instances they are ready to take more battles after the challenge is over
  • or you can switch to another challenge and run it on these instances as well
• you can stop running challenges
  • if you type STOP while the challenge is running all processes stop the current battles and can be restarted (they stay initialized)
• with DEBUG you get additional informations (about the messages and some standard output from the processes) - i plan to make this configurable so you can see what you want
• with AUTORUN the next time you start the program it takes the last configuration and challenge and runs it automatically
• with STATUS you get the configuration and running state of all processes
• HELP shows some help (not much yet)

What is not ready yet:

• everything with result output is not finished yet
• the results are coming back from the processes (and will be printed to the console) but there is no processing on these informations right now
• i plan to take your code and then it will be possible to print results with whatever output you prefer (also offline results)
• basically this means - you can say: show me result bla (avgDmg,score,cats,dogs - whatever) and it will be extracted from the current available results

I would be interested if it runs with all the cpu you have and has no concurrency issues. And if the usability is ok.

I had to change quite a lot but it has still the spirit of your RoboRunner and should work as same as yours. It is based on a very basic communication protocol to make it extendable for later needs.

You can find it here: roborunner_wompi.zip. To start it just run the ./rr.sh (same as yours)

If you don't trust the class files, the sources are included or available from GitHub as well.

You don't have to play much with it, just a quick start and configuration and one of the example challenges would be great. This should only take a couple of minutes.

Take Care

Cool, I'd be happy to take a look! I particularly like the idea of having a Windows-compatible setup. I think my main concerns from your changes are:

• If RoboRunner stays running after finishing a challenge, that would screw up how I often use it, which is having multiple dev versions queued up in separate runs via shell script. So I'd either need to make that configurable, or also add support for running batches (which I guess would also be necessary if ever we have a GUI).
• The interactive commands sound really powerful and I would definitely use them :-), like when a dev version is tanking and I want to just kill it and move onto the next one I have ready to go. But I also like simplicity and not having a big learning curve to using RoboRunner, so I just want to make sure it doesn't feel like "you have to learn a bunch of commands" in order to use it. So I'd like to make sure you can get by without knowing them, and/or that they're really easy to find and learn about. A lot of how I use RoboRunner is queueing up a few runs and leaving it for hours, so I definitely want to keep full support for non-interactive batch runs too.

Thanks man! Very cool to have someone else using and contributing to this. :-)

And I promise I have not forgotten about the custom scoring, I just haven't gotten to trying out some of my ideas with it. I was curious if you're still using that in your development? And if so, what kind of stuff do you collect and how do you like it?

Yes i rewrote most of the original stuff to be highly configurable. I'm a little unhappy with all the changes right now but i hope in the end it will pay off to have something really nice to run test beds. It's fairly easy to provide batch runnings with multiple dev versions. I just have to make the challenger input ',' separated and then it runs all challengers against the current challenge. Or maybe a input file where all challengers are included (linked to whatever challenge).

I guess i use RoboRunner in a sightly different manner right now. While writing on my bot i make a quick dev jar and let the runner make a couple of battles against my test bets. Therefor i can still make changes - and in the background the first results can show me if i was wrong or if i'm on the right track with my changes. That's why i wanted the processes alive. What i had in mind was having RoboRunner running infinitely and if a new version arrives he just grab it and runs the challenge against the new bot version . I also can switch the challenge on the run so if i think i need another view of my development state its just one switch to the console. I'm defiantly on your side of having RoboRunner making its stuff without maintainance. The console is just to have a tool to make changes if you think you have to. And beside of the config stuff its just a run command now.

The main reason because i switched to a communication protocol, is having the possibility to improve later versions with more fancy stuff like diagrams on certain battle states and such stuff. I don't know if you run some melee tests as well but for me its better to have just a couple of precise test beds rather than just let the challenger run against everyone above a certain level. I guess this will be more important if i go for an appropriate 1v1 strategy (someday :)).

About the custom scoring, its more custom battle field statistics for me. It's still one of my main targets for RoboRunner. Some of my statistics gave me a quite nice view of whats going on on the battle field and for what i should watch out. Like average field population (where are the most crowded spots and how was my survival at this spots) or bullets fired far away from me with more as 6 opponents on the field (how much did i catch a hit of these bullets and where would be a better place to stay). Yes its quite a bunch of other stuff to and most of it is just not worth it but, you know, sometimes you have to think strange.

Oh no - real tabs, braces on their own lines, lines over 80 chars?! :-) It's funny, at my last job, almost every file had its own different code style, so I was very flexible. My current job is much more rigid on code style, and now I realize I've also become more rigid... Might have to reformat some stuff, at least in the main package. :-) I just took a quick look for now, though. I'll look more and test out your stuff when I get home later. Btw, should I hold off playing with the code much if you're still making major changes?

The first thing I wanted to do with custom scoring was to track start positions for Diamond in 1v1, to see if there was any pattern to which rounds he lost. Like, when he loses 1 random round out of 35 to Raiko, is it because we started near each other? Or I started in a corner? Or I didn't start in a corner? Or is it just always the first round before we have much data? Seems like there could be a lot to gain just shoring up some of the "unlucky" stuff that can happen in a battle. But yeah, I realized most of the useful stuff you'd do with it would be custom stats like that, not traditional "scores" like with percent score or bullet damage. Passing values back from RoboRunner and storing them in the XML should be no problem, I just want to come up with a nice/simple/flexible API for the listener to log the values and RoboRunner to format them. I might want to peek at some of your code for the dynamic class loading, since I haven't done much of that before.

If you're wondering about Raiko (or any other multi-mode random movement bot), what I find is that I win the first round because of their Musashi trick / stop-n-go / anti-simple movement, and then whether I win the next two rounds is a matter of luck, until I can unlearn their anti-simple movement and learn their actual movement. Simultaneously, these rounds are the ones where their non-rolling-average VCS guns are still adapting quickly, so they get a decent hitrate against the surfing still.

Ah, very good points. The Musashi trick shouldn't last long (stops as soon as they're hit once), but certainly the 1+ rounds of stop and go would screw up my guns. Maybe it's worth special casing that and clearing gun data once you detect the switch.

And the relative fast-learning of their guns in early rounds isn't something I'd thought about much. Maybe there's a place for some light flattening early on as soon as you know they're using something besides simple targeting.

I've just been thinking a lot about all these bots that take 1-2 rounds off of Diamond (and DrussGT). If you're winning 95% of rounds vs a given bot, maybe you’re just a little consistency away from 99%. And it could be from simple stuff, like starting a round cornered or too close. But it might take some real research to figure out some causes (or just give up and accept "randomness" =)).

Hehe the formatting style discussion i know all to well :). I have no problem if you reformat it to whatever you think is appropriate, i'm used to read all kind of code style (working on it is another discussion :) ). I don't know if you develop with eclipse but if so, just give me your formatting file and we will see how it works :). I started programming when all these formatting rules made sense (80x40 terminals). You wouldn't come far with braces at there own line and lines over 80 chars but these days are long long gone :) and with todays monitor resolutions i don't see why i shouldn't use it. I'm surprised that you still have discussions on code style at work. We had some check in format at work and every one had to use it before checking in files to cvs. If you check out the files, just format it to whatever you like and thats it. Maybe i can convince you to give up the 80 char per line rule, because with all these method().method().method() calls it is quite hard to maintain a readable code line. Well, like said format to whatever you think is good :).

If it comes to changes, don't hold you back do whatever you want (in your branch or in mine no matter). This Git stuff is way more fail resistant to merges than cvs/subversion and i have no doubt that i can handle the changes. The code right now is still draft status and i haven't looked where i could bring some things together or should more open and bring it apart. I just wanted to bring it to life and start the improvements from there. I'm thinking of changing the communication anyway to RMI or TCP but for now i'm fine with the process in/out like you did. It's also ready to take a GUI (but thats not really something i'm thinking of right now). I'm not sure if i have the dynamic stuff included right now i guess it is still in another project but i think i will bring it over within the next couple of updates.

Reading about Diamonds start positions made me think if it would be rewarding to use the start position feature of the RoboCodeEngine. This would give you the opportunity to set all kind of interesting start positions and just rumble it out.

I basically use the default Oracle/Sun format and style guide, just with 2-space tabs (no real tabs). 2-space tabs makes 80 char lines a lot more reasonable, too. I generally don't auto-format because some stuff is still a judgement call, like breaking lines in the clearest way.

I certainly learned a long time ago that code style is just something you have to compromise on to get anything done in a collaborative setting. =) I didn't quite realize I’d become so accustomed to one Java code style until browsing your code. And yeah, I was also surprised at first that code style was so enforced at my current job. It was an adjustment after having the exact opposite situation at my previous job (just stay consistent within a given file). But now I like it, and/or am brainwashed. At a large enough company with a lot of code sharing, it kind of makes sense to just settle on something. Deep down I’m not actually a psycho about code style, but maybe keeping it consistent within each package makes sense, and wouldn't be too painful for either of us.

Ok, gave it a shot and everything seems to be working fine with 8 threads on my Linux box. Actually I like the feel of this environment more than I expected to, it's very cool. And I like the extra stuff you save in roborunner.properties now. Looks like some of the output is just incomplete for now (I didn't see overall scores at all?), and there's definitely plenty of room to polish up the usability side of things, but that stuff's a pleasure to work on once you have all the core stuff working. =)

I'd be happy to take a pass at improving some of the usability stuff, or just writing up a list of ideas, but maybe I'll wait a bit if you've still got some stuff in progress with this. Nice work man!

Thanks man. Sure thing, your improvements and ideas are very welcome. The current design is open for quite a lot of directions.

Like said, everything that relates to score processing (collect,save,average,overall score,smart battles) is not implemented yet. The results you can see, are the results of every battle and contain all available data field of onCompleted() BattleResults. They just have to be parsed and processed now. I just wanted to have the config, chal and messaging stuff to be ready because i know myself to well. Once implemented i probably don't touch it ever again because i don't like writing code around path, file and input checks. After thats finished now i can spend all time in doing the result/statistics stuff smooth and fluffy. Thats why i wanted to have your opinion about it, to make the related changes now.

Heya Voidious,

I think I may have found a bug.

I finished a run of deBroglie rev0130 last night on the test bed you made for me. Score was in the lower 80s.

Just now, I manually made a .rrc testbed with some high performing bots. Started running it, and here's the output. Looks like RoboRunner is carrying over the score from the other challenge file?

~/roborunner $ ./rr.sh -bot tjk.deBroglie rev0130 -c debroglie_mega.rrc -seasons 20

Copying missing bots... 0 JAR copies done!

Initializing engine: ./robocodes/r1... done!

Initializing engine: ./robocodes/r3... done!

Initializing engine: ./robocodes/r2... done!

Challenger: tjk.deBroglie rev0130

Challenge: deBroglie Megabot test

Seasons: 20

Threads: 3

 tjk.deBroglie rev0130 vs lxx.Tomcat 3.67c: 39.79, took 57.6s, avg: 39.79

Overall score: 81.16, 170.42 seasons

 tjk.deBroglie rev0130 vs voidious.Diamond 1.8.1: 31.91, took 72.3s, avg: 31.91

Overall score: 80.83, 170.5 seasons

 tjk.deBroglie rev0130 vs jk.mega.DrussGT 2.7.3: 37.2, took 82.0s, avg: 37.2

Overall score: 80.54, 170.58 seasons

Yep, it seems I'm printing the overall score for every bot you've faced, not just the ones in the current challenge file that's loaded. I'll see about fixing that later today. You can just delete (or rename for now) the file from the data directory if you want to start fresh. Thanks!

Or you could keep/copy just the lines for those bots in the data file, if you feel like mucking with it.

Ok, posted the fix in 1.0.1: [1] Only things to update are the RoboRunner JAR and rr.sh which points to it. It was just a problem with the output, so things should work fine with your old data file, if you still have it.

Hi mate. I got a little Exception :)

java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.lang.ArithmeticException: / by zero
	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
	at java.util.concurrent.FutureTask.get(FutureTask.java:83)
	at robowiki.runner.BattleRunner.getAllFutures(BattleRunner.java:95)
	at robowiki.runner.BattleRunner.runBattles(BattleRunner.java:80)
	at robowiki.runner.RoboRunner.runBattles(RoboRunner.java:338)
	at robowiki.runner.RoboRunner.main(RoboRunner.java:89)
        ...
Caused by: java.lang.ArithmeticException: / by zero
	at robowiki.runner.RoboRunner.printOverallScores(RoboRunner.java:485)
	at robowiki.runner.RoboRunner.access$4(RoboRunner.java:466)
	at robowiki.runner.RoboRunner$3.processResults(RoboRunner.java:734)
	at robowiki.runner.BattleRunner$BattleCallable$2.run(BattleRunner.java:197)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

One question. If i fork RoboRunner to my GitHub repositories and make changes, does it mean i have a new project or is it more like a separate branch and we could merge some changes i made?

Take care

edit: stupid me, i posted just the head

Seems like this would only happen when printing the overall score for 0 battles? Is it possible that was the situation? If so I'm not as worried about it being a bug, but we should check for it and print something nicer. If it shouldn't have had 0 total battles, then it's a deeper problem with the score tallying I guess.

This is my first experience with GitHub, so I don't know for sure, but I'm pretty sure the main idea behind forking is for you to make changes and then I can pull them back in. I think you issue a "pull request" once you've made your changes. I also think it can function fine as a new project if you don't ever intend to merge back.

Yep the problem is deeper. It looks like, if i had no battles before everything is fine (not 100% sure). Then, if i restart the test run this Exception comes up. I run it with 20 seasons (melee).

I made just a quick fix for me, so i can still use it. The only thing i lost was the 'Overall' score output - but i'm fine with the 'Average' output.

I have forked your repository and made a new brunch from the main branch, not sure if you can see it on your side to. The only thing i changed so far is the output of the melee score (just formatting). Yes, i guess i will use it mainly as new project and tweak it to my needs, but i thought for little bug fixes it would be easier to just merge the branches.

So you can see the latest and average score for each battle, but overall score throws that exception? How strange. Could you post your data file somewhere so I can try to reproduce? That would be super helpful. (roborunner/data/package.BotName version.xml.gz)

I'd certainly like to pull back any bug fixes or awesome new features. =) What's your melee score output look like? I've used it for Melee a little but mostly 1v1, and even for Melee I tend to focus on overall score, so I'm open to suggestion. I've also considered a -verbose option (or something) for printing extra scoring details, like survival/bullet damage even when you specify APS as the scoring style.

Yep give me a second i rollback the fix and give you the output file ....

Ok there it is RoboRunner-bugtrace.zip. Looks like i was wrong it happens straight from the start. I deleted all xml files and the output of the first run is shown in the zip file. Maybe it helps :). Let me know if you need more. i broke the run after the second season with 'CTRL-C'.

Well, i just made the melee output a little more 'eye' friendly :) but i guess i will enhance the output to something that i use in my other outputs in the next days (nothing serious just a little more info on bullet hit ratio of all bots,some movement stats, sorted output of APS and a table of all bot score to each other). Based on an early RoboRunner version i rewrote it to a console like application. So basically you start the program and use console commands to configure,run.output some stuff. Unfortunately does it not use multiple threads and i'm now back to the latest RoboRunner and maybe i can merge the two somehow.

I think if you look in GitHub at Network you should see the forks that go of of your main branch.

Great, thanks! I was able to duplicate it here and figured out the problem. RoboRunner gets confused by having 2 of the same bot in a battle (mld.DustBunny 3.8 in this case). It looks like BattleListener eats the result right away when it builds a map of scores by bot name/version. (Edit: So RoboRunner has zero scores for the actual bot list when it tries to calculate overall score.) I have to head out in a few minutes, but I'll try to get a fix out later tonight or tomorrow.

Ok, I think it's all set. Tested it with the challenge you provided, dropped it into my currently running melee test a half hour ago and that still looks right, and did my usual round of manual setup and tests. The fix was mostly pretty easy thanks to Guava's Multimap stuff, but it also led to some minor refactoring so that nothing is based on looking up a score only by bot name, besides the challenger bot. I think it should work fine even if the challenger is also a reference bot, even though that seems silly - the first score for that bot in each battle would be considered the challenger score.

Hopefully it won't be too painful of a merge for you. ;)

Yep works fine. Thanks. It wasn't supposed to have two of the same bots within the challenge :) - i realized that i just took an old challenge file while switching to the new RoboRunner version. But i guess in this case it was luck to detect the bug.

I tried yesterday to make the challenger a development bot. I changed the copy bot function to let bot names with ..* through but somewhere it lost the name. Can you give me a hint where the bot name comes back from the process? The RobocodeEngine can work with development bots if the properties contain the right path. What it does, if you give it, lets say wompi.Wallaby* , it changes it to wompi.Wallaby* 4.7 for the result output (this works so far). Now i thought i just change the name back to my original (wompi.Wallaby*) within the BattleResultHandler (i guess this is where the results are coming back from the process) and could work with development bots. It was just a quick try and i will try it today more seriously, but maybe you have a quick solution. I guess you are more used to your code and could say where it stores references between name and score. The sad thing is even if i'm giving it the complete name (wompi.Wallaby* 4.7) it doesn't work :(. I guess somewhere the "*" is a limiter or gets lost. Please don't put any time in this, it just would be nice if you have a quick hint.

I have to admit that this GitHub stuff is very neat. It's so easy to work with - thanks for pointing me at this by releasing RoboRunner over GitHub. I'm a little more used to it now and figured out how the forking works.

It's basically: fork your origin -> my origin clone to local (optional) make branches add your origin as remote (this keeps me up with changes at your side) merge remote -> my branch push my branch -> my origin (optional) make a pull request to you

It's pretty straight forward and with GitX you have a nice graphic view about the branches to :)

Take Care

I don't think the name should be interpreted as a regex anywhere or anything like that. I think that whatever comes back from robotResults.getRobot().getNameAndVersion() in BattleListener should be handled by the rest of the code OK. The other points of concern that come to mind are:

• Copying the dev bot into the Robocode install directories means copying your package dir and classes into the robots dirs of each Robocode install, which is not as simple as copying one file. (Unless you have them all configured to look at some other directory?)
• Assuming Robocode can find it, checking whether the dev bot you specify is actually running in the battles.

For the second point, you could try:

• Modifying BattleProcess to do _engine.setVisible(true), so you could see the battles that get run.
• Run robowiki.runner.BattleProcess (with -path to Robocode, -rounds, -width, -height) and try running battles with your dev bot. BattleProcess is a command line application where you can type in a comma delimited list of bots (like "jam.mini.Raiko 0.43,voidious.Diamond 1.8.1") and it runs the battle and spits out the result.

And yeah, I'm liking GitHub too! I know PEZ is a big fan, though he's not doing Robocode stuff. I didn't know about GitX, I'll have to give that a shot. Maybe it will encourage me to make better use of branches. ;)