Difference between revisions of "User talk:Krabb"
Jump to navigation
Jump to search
m |
m |
||
| Line 18: | Line 18: | ||
::: 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()? :) --[[User:Rednaxela|Rednaxela]] 12:16, 23 March 2010 (UTC) | ::: 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()? :) --[[User:Rednaxela|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 | + | ::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 [http://robocode.sf.net/files/Krabb.sliNk.Garm_0.9u-sources.zip 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? --[[User:FlemmingLarsen|Fnl]] 21:56, 23 March 2010 (UTC) |
Revision as of 23:00, 23 March 2010
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)
- 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)
