View source for User talk:Beaming

From Robowiki
Jump to navigation Jump to search

Contents

Thread titleRepliesLast modified
what to do with about printing to much?1410:17, 21 November 2013
EvBot705:51, 16 November 2013
First page
First page
Next page
Next page
Last page
Last page

what to do with about printing to much?

I am trying to print quite a lot while I am debugging my bot. But I see

SYSTEM: This robot is printing too much between actions.  Output stopped until next action.

I would like to see the whole output. Is there a way to force robocode to print everything, something analogous to debug mode where all graphics events are plotted.

Beaming (talk)15:55, 19 November 2013

One option would be to write to a file instead of printing debug output, particularly if you adjust the per-bot disk quota in the config file.

Rednaxela (talk)16:26, 19 November 2013

Do we have a code sniplet anywhere for writing into a file?

Beaming (talk)16:57, 19 November 2013

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

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:User talk:Beaming/what to do with about printing to much?/reply (6).

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
 
 
 
 

Not sure if it's useful, but a secondary suggestion is to try debugging graphics. Some info that takes a lot of text is very simple and clear in graphical form.

Voidious (talk)16:37, 19 November 2013

I am slowly drifting in the direction of graphics debug. But it certainly harder to do right compared to simple text output.

Beaming (talk)16:56, 19 November 2013
 
 

Hey, a quick request with EvBot, could you only have one version in the rumble at a time? If you want to compare their scores you can do that in the details page.

Also, just a suggestion, you will get stable rumble results quicker if you make EvBot execute faster. Right now it runs quite slowly, and while that *is* allowed, it makes testing quite a bit more painful ;-)

Skilgannon (talk)11:54, 14 October 2013

I removed the second entry and apologize for such misbehavior.

Can you suggest a tool to test my bot offline? I use RoboRunner, but I see its result different from robocode graphical interface, and even then it is different for paint on/off cases. I am guessing it is doe to the fact that my bot is super slow, and has more skipped turns in no gui environment.

Beaming (talk)13:45, 14 October 2013

Don't worry about the second one, lots of people do that when they're starting out. It's just better to have one so the rankings don't get as full, and "top 100" actually means "top 100" etc...

Yeah, that sounds like you're dealing with skipped turns problems. RoboRunner should give you similar results to the main RoboRumble (at least, in pair-on-pair scores). If you minimise the graphical interface do the results look similar to what you're getting with RoboRunner? Also, make sure you aren't running too many simultaneous threads in RoboRunner, if you're running more threads than cores it can impact skipped turns pretty heavily.

Why don't you make a page for EvBot where you explain what your general strategy is, we might be able to help you with getting it to run faster and avoiding the skipped turn problems.

Skilgannon (talk)17:34, 14 October 2013
 

It's also worth noting you can always revert back to a previous version in the rumble and it retains all its battles. And you can compare to previous versions forever. So you don't lose much by having only 1 version at a time on the participants list.

Nice to hear you use RoboRunner! :-) +1 to what Skilgannon said about those issues. But it's also true that there's almost no replacement for entering your bot in the rumble, so don't stress too much about posting versions frequently. Unless you've got quite a few cores to throw at Robocode, you'll get more battles in the rumble, and you may get slightly different scores on different machines / JVMs too.

Voidious (talk)21:10, 15 October 2013

Guys, thanks for your suggestions. My windows manager does not has a minimize button so I am unable to see the difference with minimized robocode. But I remove my slow code and everything seems to be way more predictable. The slow code is a pif gun with which I step in all beginners pitfalls myself.

Voidious, I have a suggestion for RoboRunner installer. Do not copy robots folder, just link to it if you think it is a must. At first I was shocked how long the initialization was performed and then I saw 500MB directory for each thread.

Beaming (talk)01:16, 16 October 2013

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:

  1. Modify the robocode engine to separate the "robot.database" and ".data" directories from
  2. 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)

Rednaxela (talk)01:48, 16 October 2013

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.

Voidious (talk)01:57, 16 October 2013
 
 
 
 
 
First page
First page
Next page
Next page
Last page
Last page