User talk:Beaming

Just noticed, that my article hit it's goal:) Nice to see it:)

Yes, your article have changed me. I am not sure should I thank your or not :), since robocoding ate large chunk of my time.

I understand what you're talking about:) But practice shows, that after few years robovirus will be suppressed most of time and you will return to normal life, except rare relapses:)

I'm sorry, I seem to be missing some context. To what article are you referring?

See User:Beaming's background. I can post link to this article, but it's on russian. It's story of Tomcat's climbing to PL first place

Please do. I don't know Russian, but using Google Translate should work well enough.

Here it is

Hi everyone.

I see strange regression in performance of my bot when it compiled with different version of robocode.

Specifically if I take EvBot v4.6.4 and compile it with robocode v1.8.2 I am getting about 20% higher score against let's say sqTank.waveSurfing.LionWWSVMvoid 0.01, However, when I compile with robocode v1.9.2 I see drastically worse performance. In both cases I run the battles with robocode v1.9.2.

Does anyone see similar behavior?

When I compare the stats of my more recent bot vs older v4.6.4 for example [4.6.12 vs 4.6.4], I see drop in a score against some bots which my bot use to be good against. There were quite a lot of changes and I originally thought it was due to experimental code, but now I am quite convinced that the major APS drop is due the change of version of robocode, since from v 4.6.5 and up I used robocode 1.9.2.

Any ideas?

Sorry for the noise. Above seems to be not true. Looks like I accidentally used wrong version of my code affecting the performance during the comparison. The robocode seems to be fine.

gertjan1996 need help using multiple java files in a robot for his School

My rumble client contaminated with a few bad bots: cb.mega.Remedy 0.2 uji.SiberianKhatru 1.0

They produce the following error message: Can't load 'uji.SiberianKhatru 1.0' because it is an invalid robot or team. May be we should comment them out from the participants wiki page? Alternatively, may be something wrong on my side?

Hey, I just want to start by thanking you for running a rumble client. However, for some reason the results from your client for DrussGT are very different from what I'm getting with my local tests. I'm just curious what your setup is and what might be causing this.

Thanks

Hi Skilgannon,

There is nothing special. Rumble clients runs with a stock config, where only user name is set and I exclude Lo_Ian.Gandalf_V4*, since it seems to halt on my side. This 6 CPU machine, but only 2 are heavily used for roborumble and meleerumble clients, though last week I left It unattended and firefox start to consume a lot of load, so may be it somehow skewed CPU constant of the client.

If you have some ideas what could it be, I will be happy to investigate.

Things often brought up in rumble client discrepancy cases are which OS is in use, and what exact version of Java is in use.

Also, other possible relevant factors are:

1. If CPU frequency scaling is enabled, as it is by default on most newer machines (this can cause problems for robocode's CPU time limiting being fair)
2. If the system in question has high memory usage such that it goes into swap space.

I am not sure about CPU scaling. This is what ever Debian does to relatively modern AMD CPU. As for the swap, I am 99.99% sure it is not used. This machine has 16GB out of which only about 6 is used. If I look at memory usage, I seen only 3MB of swap used which is way to small for JAVA. May be the problem with linux scheduler, which constantly move application from one CPU to another.

There is one strange thing though, I notice that my meleerumble client usually crash within couple days, but roborumble is not. But this is true for another computer of mine as well.

FWIW I don't think anybody's measured the effect of dynamic clock speed on skipped turns, only speculated that it should have an effect. For all I know, the timings coming from Java on modern CPUs could have so much variance that the dynamic clock speed doesn't increase the number of skipped turns that much.

Here I run a single client with blank config for a while so it calculates CPU speed alone, before dynamic clock kicks in. Then I copy config to all clients and run them in parallel.

The effect is they assume a worst case in CPU speed and skipped turns occurs less often than it should. Which I think is better than occurring more often than it should.

Thanks for the offer. Could you test DrussGT 3.2.1 vs. Garm, Shadow, Hydra and Gilgalad? Functionally, 3.2.1 should be almost equivalent to 2.8.16 (3.2 has 3-series bullet shielding disabled), but as this comparison shows they are getting very different scores.

There are also a few bots DrussGT now gets 100% against - this worries me, as it points to them crashing.

What should be the setting on a client to perform such test? Or should I use RoboRunner?

Also my observation showed that sometimes short test set shows drastically (1% APS) higher scores. I was fulled by it couple times thinking that my older bot is more superior to a new version. They end up to have the same score or even reversed as I keep waiting for stats accumulation.

I compared DrussGT Version 2.8.16 to DrussGT 3.2.1 And 2.8.16 was way better http://www.2shared.com/photo/bKABJFb4/2816_vs_321.html

Looks like meleerumble is not updated anymore. If one goes to http://literumble.appspot.com/Rankings?game=meleerumble she would see that the most recent update was done on 2013-11-07 while today is 2013-11-16.

That's because nobody is running a client for it. You're welcome to run it yourself, unfortunately I had to stop the client I was running when I moved out of my old lab.

I find it impossible to run a client for meleerumble, robocode just crushes on attempt to submit results. I have no such problem for roborumble, which continues to happily accept my CPU cycles :)

But someting is broken in meleerumble robocode. Here is the relevant part of the console log for ./meleerumble.sh v1.8.2.0 run

RESULT = mld.Wisdom 1.0 wins, bayen.UbaMicro 1.4 is second.
Fighting battle 2 ... dq.Finity 0.2,jangs.ns51 1.0,simonton.micro.Sprout 1.1.3,baal.nano.N 1.42,ap.Frederick 1.1,amk.jointstrike.JointStrike 0.2,cs.sheldor.Talon 1.1,bvh.mini.Fenrir 0.39,arthord.NanoSatanMelee Beta,fullsail.TimbotNoPrediction 1.0
Can't load 'dq.Finity 0.2' because it is an invalid robot or team.
RESULT = simonton.micro.Sprout 1.1.3 wins, bvh.mini.Fenrir 0.39 is second.
Uploading results ...
OK. Portia vs Improved added to queue in 5ms
Exception in thread "Application Thread" java.lang.ArrayIndexOutOfBoundsException: 2
        at net.sf.robocode.roborumble.netengine.ResultsUpload.uploadResults(ResultsUpload.java:176)    
        at roborumble.RoboRumbleAtHome.main(RoboRumbleAtHome.java:137)

I just tried a client and it is working fine, so it seems like a problem with your install. Delete the /robocode/roborumble/files and /robocode/roborumble/temp directories and try again.

Thanks Skilgannon. Above recipe fixed the issue.

But I find it strange, I am quite sure that I was trying to run it from the fresh install.

There was an entry in meleerumble without link, Skilgannon repaired that. But to be sure that no old pieces are left behind, cleaning those directories is good practice.

Something is wrong with meleerumble. My client fails with

Uploading results ...
Exception in thread "Application Thread" java.lang.ArrayIndexOutOfBoundsException: 1
        at net.sf.robocode.roborumble.netengine.ResultsUpload.senddata(ResultsUpload.java:293)
        at net.sf.robocode.roborumble.netengine.ResultsUpload.uploadResults(ResultsUpload.java:184)
        at roborumble.RoboRumbleAtHome.main(RoboRumbleAtHome.java:137)

On top of it the last upload was 11 hours ago and it was from me, but I think it start to misbehave by this time already.

I think it's your client again, same fix procedure as last time. You aren't running two clients out of the same folder, are you? It can corrupt the results file, which causes the client to crash.

I am quite convinced that it is on my side, but I was suspecting that others had the same problem, due to lack of uploads.

Same procedure did not fix it, but today I started it again after 8 hours and it works now.

I do run roborumble and meleerumble in the same folder, strangely roborumble is stable as a rock, while meleerumble gives me hick ups. Do you suspect some race condition and advise to use separate folders?

Never mind, looks like it works now.

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.

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.

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

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]

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.

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.)

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.

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

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 ;-)

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.

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.

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.

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.

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)

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.