what to do with about printing to much?

Fragment of a discussion from User talk:Beaming
Jump to navigation Jump to search

Kind of a weird link, but PEZ recently posted all his bots to a GitHub repo so that's fresh in my mind. See the robot.getDataFile() stuff: [1]

Voidious (talk)17:06, 19 November 2013

Thanks, I will look at it.

Is there a way to see if bot run with GUI or through a rumble client? So one can disable all of the debugs during rumbling matches to save on CPU and quotas.

One more questions, why rumble client needs a display under x11 environment? It does not use gui so it should run just fine.

Beaming (talk)19:48, 19 November 2013

I don't think Robocode exposes anything about the environment (app vs control API, graphics or not). You can tell if graphical debugging is enabled, though, because onPaint() will be called. You could use that as your debug switch. I mainly use graphical debugging and log severe stuff to file.

As for X11, I don't know, I would guess it's due to using some java.awt code internally or something. I have run RoboRumble over a terminal quite a bit, but maybe my terminal has the X stuff setup. (Mac OS X Terminal connecting to Ubuntu.)

Voidious (talk)20:13, 19 November 2013

Unfortunately, RoboRunner seems to suffer from the same issue.

Set DISPLAY variable to something crazy and run RoboRunner you will see it crush as well.

Beaming (talk)05:13, 20 November 2013

I think it's Robocode itself causing the issue, not RoboRumble or RoboRunner.

Voidious (talk)18:42, 20 November 2013
 

Try adding the "-Djava.awt.headless=true" parameter to how you invoke Java. I believe that does the trick. I seem to recall once trying this in the past.

Rednaxela (talk)21:01, 20 November 2013

This helps with rumble clients, so it probably good idea to ping developers about this switch to be on by default.

However, it does not help with RoboRunner.

Beaming (talk)03:54, 21 November 2013

You can update the JVM arguments passed to the Robocode process by modifying "jvmArgs" in roborunner.properties. Each thread starts in its own process with its own JVM because the Robocode engine isn't thread-safe.

Edit: And I'll put it on my RoboRunner to-do list. :-) I didn't have any other plans for a next version but it could probably use a few touchups...

Voidious (talk)04:02, 21 November 2013

This does the trick. Thanks.

Now my tools are sharpened, and all is left is to beat you all in the game :)

Beaming (talk)04:34, 21 November 2013

Good luck.

Chase10:17, 21 November 2013