User talk:Krabb

Hi Krabb,

I bug report has been created for Robocode 1.7.2.0 Beta 2 regarding your robot Krabb.sliNk.Garm 0.9u here.

I should like you to assist us in finding out why your robot is skipping turns and eventually is stopped in the game in MeleeRumble (1000x1000, 10 robots). Perhaps you could try out your robot with the same setup and and tell us what causes the problem for your robot? Please follow up on the bug tracker on the link above. --Fnl 23:35, 22 March 2010 (UTC)

I found Krabb's email on the old wiki's contact information page, and set him an email notifying him of this. No clue if the email address is up to date or not. --Rednaxela 01:47, 23 March 2010 (UTC)

Well, we can ask Voidious to check this wiki's email address =) --Nat Pavasant 02:23, 23 March 2010 (UTC)

No need for that - he has the wiki e-mail feature enabled. I just clicked "E-mail this user" in the toolbox and dropped him a note to check his Talk page. ;) --Voidious 02:58, 23 March 2010 (UTC)

Hi! 6 new mails ;) Thanks for the info! I don't have the source code of 0.9u anymore, however I haven't changed the drawing stuff in the last versions(as far as i remember). I'll check if something is wrong there. I remember having a test whether drawing is enabled or not, but maybe its broken. But first of all I need to install robocode, I'm currently on vacation at my parents home... Hmm, I would like to do some robocoding again ;( I really need to get that bachelor thesis finished! --Krabb

Yes seems like the debug graphics are causing the error, enabling them stops the skipped turns. Oh, 0.9z does some devision by 0 :/ But I don't have any sources here, no ssh server at my PC... we need to wait till monday. --Krabb

Er, do you mean disabling them stops the skipped turns? Also, any guesses why exactly it's affecting 1.7 and not 1.6? Is this using onPaint() or is it using getGraphics()? :) --Rednaxela 12:16, 23 March 2010 (UTC)

When I disable the robot paintings in Robocode, and remove all the painting queues and stuff, 0.9u still skips turns?! In addition, getGraphics() is never called, but the onPaint() handler is. I am not sure, but it seems that sometimes the robots builds up some statistical data, that uses too much CPU power in some battles (at random), but not all battles. If I set up the CPU constant time to e.g. 3-5 times the amount, it still skips turns. I am not sure what causes the problem, but it could be some timing differences (some methods are faster, and others are slower) in Robocode 1.6 vs 1.7 that triggers the problem for the robot. I believe the problem lies within the robot somehow, and the robots has been "lucky" that the problem was not triggered in 1.6.1.4. I have used JAD for decompiling the robot, and fixed the stuff JAD could not figure out. I have put the sources here, if you guys want to see what might cause the trouble. I hope you don't mind Krabb? I am not sure if I got all sources correct, but it will be a good pointer to where the issue might be. My question is. Does this issue need to be fixed before we can release the final version of Robocode 1.7.2.0? --Fnl 21:56, 23 March 2010 (UTC)

How it sounds to me, is that the problem is a few issues combined:

• Robocode 1.7 appears to always be calling onPaint, whereas 1.6 only called it when necessary
• Robocode 1.7 appears to penalize bots for onPaint time whereas 1.6 did not, some bots bot need to do a substantial amount of extra processing to compute what to paint. This makes it impossible to debug with debugging graphics and at the same time run the robot's core code under ordinary CPU constraints.
• Garm's painting overhead in melee that is unreasonably slow for practical use even in 1.6, though it does run.

IMO, at very least resolving the first would be important for a Robocode 1.7.2.0 release. The second also seems important to me. The third of course is a Garm-specific concern but shouldn't matter more in 1.7 than 1.6 if the above is addressed. --Rednaxela 01:41, 24 March 2010 (UTC)

Hang on. I wasn't aware of the fact that the onPaint() is still called in 1.7 even when not painting. This seems like a major deviation from previous versions, as previously the only way to know if painting was enabled was to check if onPaint() was being called. Now it seems that old bots will be executing all their painting code even if painting is not enabled. DrussGT tries to be backwards compatible by setting a global varial painting to true if the onPaint() is called, but it seems that this isn't correct anymore? Could somebody verify this? --Skilgannon 15:33, 24 March 2010 (UTC)

Same concerns here... onPaint() being called is how I determine that painting is enabled, which triggers a lot of extra processing. --Voidious 15:40, 24 March 2010 (UTC)

Same here. When the event is triggered, I set flags in parts of the code to start calculating things it otherwise would not in order to produce the graphics, so definitely a hit to performance. And keep in mind onPaint is supposed to be outside the bot's processing time allotment, so this could be a serious overall performance hit to the Rumble. There is absolutely no reason to count debugging graphics against the allowed processing time of a bot. Bottom line, this change is an oversight that should be rolled back.

On a side note, I can give an example of a reason that enabling and then disabling graphics could cause a crash: Let's say when you enable graphics you set a flag to start putting Shape objects in a list to be rendered. The list is fed to the graphics console each turn and emptied. Then you disable drawing. The list is still being filled, but now no longer being emptied. Crash imminent. --Martin 15:51, 24 March 2010 (UTC)