The whole separate "robots" directory thing is not for no reason: In order to avoid conflicts between the running instances, I'm pretty sure one needs a separate "robot.database" file, and separate ".data" directory inside it. Unless I'm missing something, without modifying the robocode engine a little there's probably no way to do that with (sym)links, except by creating a link for each and every jar file, which would be a touch silly in some ways.
To improve that without symlink-spam I see one of two possible approaches:
- Modify the robocode engine to separate the "robot.database" and ".data" directories from
- Modify the robocode engine so it'll read jar files nested in a folder in the "robots" directory (thus allowing a simple symlink to a central robots directory)
For this purpose, personally I'd lean toward the first option simply because symlink APIs/commands are slightly less cross-platform (though I'd personally also not mind #2 supported for other reasons)
Doh! Sorry about that Beaming. The script is a little quick and dirty compared to what it could be. I haven't touched RoboRunner in a while, but I'll take a look when I get a chance.
@Rednaxela - It's true you need separate robots directories for each install, but I can indeed fix the issue Beaming describes with a more sophisticated shell script. The RoboRunner setup script just uses "cp -r" to clone X copies of whatever Robocode install you point it at, which means it makes X copies of the robots dir. But when using RoboRunner, it copies bots as needed from the "bots" directory into the Robocode installs, so it would be fine to leave them empty during setup.
I think it is sufficient to make an empty robots dir for each thread to be run and add the robots directory location from the master copy to botsDirs variable in the roborunner.properties file. It is hinted in one of the readme, but took me a while to understand that this is sufficient.
On first run engine will recreate robot.database for each of the threads.