Thread history
Viewing a history listing
| Time | User | Activity | Comment |
|---|---|---|---|
| 00:29, 5 August 2012 | MN (talk | contribs) | New thread created | |
| 01:17, 5 August 2012 | Voidious (talk | contribs) | New reply created | (Reply to Buggy debug mode) |
| 02:06, 5 August 2012 | Voidious (talk | contribs) | New reply created | (Reply to Buggy debug mode) |
| 19:06, 5 August 2012 | MN (talk | contribs) | New reply created | (Reply to Buggy debug mode) |
| 19:08, 5 August 2012 | Voidious (talk | contribs) | New reply created | (Reply to Buggy debug mode) |
RoboResearch is not starting JVMs in debug mode. It passes "-Ddebug" as parameter, but it should be "-Ddebug=true".
So that's just an argument to the JVM, right? Custom JVM args is near the top of my list for RoboRunner, so I'm working on it now. But there are some things like "-nodisplay" that are arguments to Robocode itself, which wouldn't work because I don't launch Robocode (just use the control API from my own program). So I'd have to add arguments myself if I wanted to let you configure it to actually display battles, for instance.
Nevermind, did some testing. =)
The bug is in RoboResearch, not RoboRunner. Currently I'm using a custom BattleRunner class which passes the correct argument. It's makes a 2% APS difference in some challenges when using all cores.
I'll try RoboRunner someday.
Yeah, I know, it just reminded me of the related issue in RoboRunner. It's funny with RoboResearch, I feel like everyone has their own set of hacks in their local instance. =)
Wow, 2% difference in debug mode? That's crazy.
