Talk:PencilRain

getHeight(), getWidth() and hitting things...

I've seen references to people saying that a robot is 36 pixels by 36 pixels, and I took their word for it... but I assumed that meant that getHeight() and getWidth() would be returning 36... but they return 40... Is either of these perspectives better?

a)  My bot is really 36x36, regardless of what getHeight() and getWidth() say.
b)  The battlefield actually has origin 2,2, and is 796x596

I imagine these two pixels can have an affect on ramming, and for bullets hitting too, that's why I ask. Is there a known reason for this difference? --BenHorner 03:25, 10 June 2009 (UTC)

• "a" is correct. The image of the robot is 40x40, but the hitbox is 36x36 always. --Rednaxela 04:21, 10 June 2009 (UTC)

When to update data to paint...?

I just made some changes to pull a bit of processing out of my event handlers, to put it directly in my run() method's while(true) loop, but ran into a snag. I'm updating what I want to paint this turn after the onPaint() handler has been called for the turn, so now my debugging graphics are a turn behind. It seems like this forces me to put the processing of what to paint inside the event handlers. Do people have standard ways of dealing with this kind of thing? --BenHorner 02:13, 4 June 2009 (UTC)

One thing that has just come to mind is to update the painting data lazily... I can write methods that check if the data is up-to-date before returning it, and update it if necessary. If I use these methods in the onPaint() handler, then the data will be recalculated within the onPaint() handler, and be up-to-date when it's needed. If I'm not painting, and I use the same methods inside my while(true) loop, the processing won't have to happen inside the event handlers. It would just happen on demand... I guess I'll pursue this option, but I'd still like to hear input from people who've been dealing with this for years. :) --BenHorner 02:26, 4 June 2009 (UTC)

What I do in RougeDC is running all main bot code in onPaint whenever there is a tick in which onPaint is called. --Rednaxela 02:33, 4 June 2009 (UTC)

Ironically, I read this while taking a break from trying to figure out why my waves were off by one tick. Apparently I've been painting 1-tick-old data for years! Just moved my painting code out of onPaint() to just before the call to execute() in the main run loop. By using getGraphics() (1.6.1+ and later) I can paint the right data at the right time without any major code changes. Just need to comment it out when compiling for the rumble since 1.5.4 doesn't have this method. --Darkcanuck 05:02, 4 June 2009 (UTC)

I have a similar approach than Darkcanuck, but since I don't want to forget to remove anything, I have a field in my robot Graphics2D g_; on the onPaint method I just store the argument in g_, then just before the call to execute() I paint and set g_ to null(this so I know at every turn whether painting is enabled or not). --zyx 17:34, 4 June 2009 (UTC)

Cool -- I was wondering if that would work... --Darkcanuck 18:37, 4 June 2009 (UTC)

Me too. =) Thanks zyx. --Voidious 18:41, 4 June 2009 (UTC)

That makes me really glad I asked! --BenHorner 00:55, 5 June 2009 (UTC)

Displaying Waves / What is Surfing?

Halle-friggin'-luja, I finally got the circles! I've finally collected enough information, and got me events sorted out enough, and I can draw the circles when the enemy fires! I've been waiting a year for this, and I worked on it for... way too much time this weekend. I'm actually currently drawing them any time a bot loses energy (enemy or me), it's a real mess when Crazy is pinned between me and the wall ramming back and forth and shooting me. I guess the next step will be filtering out the non-bullets based on bot location (for running into walls, or me), and eventually for melee I would need to consider bots getting hit by bullets that are not my own.

Holy crap, I've been running it and watching the circles while I've been typing, I think it just hit a time limit where bots just start losing energy until they die, my screen went crazy with circles from both robots, that was awesome. --BenHorner 03:40, 26 May 2009 (UTC)

To filter out the other energy losses remember you know if he crashed with you with the onHitRobot and for wall hits extends AdvancedRobot bots take damage only if their speed at collision was higher that 2, extends Robot bots don't take wall damage. And yes, there is an inactivity timer that makes both bots loose energy if there hasn't been damage in a while, rarely happens on a real battle unless both bots a low on energy and saving it without firing. --zyx 06:06, 26 May 2009 (UTC)

I didn't even consider that non-AdvancedRobots wouldn't take wall damage, though I don't think that will mess me up. Thanks for the reminder on the speed 2 thing, I will have to look up that formula, and the one for bots hitting each other too, to make sure that the energy drops are exactly accounted for. I was thinking that I might be able to incorporate enemy gun heat into it too, if it's impossible that they fired... then they probably didn't fire. :) --BenHorner 22:57, 26 May 2009 (UTC)

If you are try to create Wave Surfer, you probably doesn't need to consider wall hit or inactive timers. About melee detecting, that's the reason why there is no wave surfing melee bots around here today. I've been recently working on my own BattlePredictor library (not finished yet) which will simulate normal melee robots behavior base on scan, which include guessed target (which other robot might aimed to), guessed firing angle (base on some past bullet hit info) and so on. But trust me, this is really complicate and might eat all your turns. OK, back to inactive timer and wall hit. If you are creating wave surfing (which I think you are since you are drawing an enemy wave), the wall hit thing is not need to be considered since top robots don't hit wall (99.999% of the time) and the mid robot that sometimes hit wall will not affect your surfing (much, but it usually has no effect) and with low nanobot that hit wall often, your movement will be good enough to get rid of them. And inactive timer, since, as zyx mentioned, this will happen only if two robots cease fire for save their energy, but both of them will have energy less than 5 (usually between 0.0 and 1.5) and will die both before any bullets will reach each other. This is proved by DrussGT, which doesn't have any detection for wall and inactive timer. » Nat | Talk » 12:32, 26 May 2009 (UTC)

I'm not really sure what wave surfing is... it sounds like you would be running away from the bullets, like riding a wave, but you can't go fast enough to do that, even for the slowest bullets, so I've never been sure what it was. For both my gun, and to keep track of what the enemy gun is doing, I've planned on keeping track of bearings. If you draw a line between the two bots, I would use the bearing off of that line, and keep track of how often I hit the enemy at a certain bearing, and how often I get hit at a certain bearing, throw in some kind of smoothing function to make it look like a probability distribution, and use that data accordingly. Is that what wave surfing is about? --BenHorner 22:57, 26 May 2009 (UTC)

Yep, you're on the right track. When you are keeping track of these bearing offsets, you can imagine a wave ("ripple" might evoke a more accurate image) with the center being where the bot shot the bullet, and the radius being the distance the bullet has traveled. The circle represents all places that bullet could possibly be. When this ripple crosses over the enemy, you can use that spot to calculate the bearing offset (assuming you remember where he was when the wave was created). If you turn on the debugging graphics in Phoenix or Diamond in 1v1, it shows the enemy waves and the dangers it projects along that wave. --Voidious 23:23, 26 May 2009 (UTC)

Ok, I've seen the circles either in documentation, or in robot debug graphics. I've thought of them as the set of possible locations of a bullet, like electrons in an electron shell, they only exist probabilistically (until you get shot of course). So is a bot called a wave surfer if it takes this kind of information into account, or is it something more specific than that? I also always wondered if it was offensive or defensive, I intend to use the information both ways, is that typical of wave surfers as well? --BenHorner 01:54, 27 May 2009 (UTC)

Yeah, pretty much a "wave surfer" is any bot that uses waves (based on enemy shots) in its movement. To really leverage the power of wave surfing, though, you need to use precise prediction, get many little details right, collect data when you get hit, and project danger along waves to go to the safest spots. So "wave surfing" is generally interpreted as including all of those things, too, even though it doesn't have to. Wave Surfing is just movement, so it's defensive, but yeah, lots of advanced targeting strategies use waves, too. If you're interested, there's a Wave Surfing Tutorial that attempts to teach you most of these little details and get started doing surfing. But it sounds like you're well on the way already. --Voidious 02:17, 27 May 2009 (UTC)

Whoah, I just looked at the debug graphics on Phoenix... that is insane. Diamond's look crazy too from the wiki page, but I couldn't find it for download here: http://darkcanuck.net/rumble/robots/, where can it be got? How long has it been since someone came up with a new idea in Robocode? :) --BenHorner 02:50, 27 May 2009 (UTC)

Nearly constantly in Nano land where every byte counts and all source is open :) --Miked0801 20:30, 4 June 2009 (UTC)

There's a download link in the infobox on the right of the Diamond page, latest version is here. They're a lot like Phoenix in 1v1, though, that's where I got the idea. And, well, with eight years of smart people slaving away at robots and building on what's come before, it shouldn't be too surprising that a lot of great ideas have already been done. But there's definitely still a lot of room for new ideas and new takes on old ideas. --Voidious 03:06, 27 May 2009 (UTC)

For even more debug graphics, try Watermelon. annotated screenshot. -- Synapse 07:39, 4 June 2009 (UTC)

Your debug graphics look very nice too, I like the gradient lines. Unfortunately I'm on a Mac and don't have Java 6, so I can't watch it in action. --BenHorner 01:46, 7 June 2009 (UTC)

Hm? You can get java 6 for Mac OS X. Also, it's possible to do a java 7 build if you want. --Rednaxela 02:05, 7 June 2009 (UTC)

I didn't say that well... lazy I guess. I have problems with Java 6 on my Mac (though I've seen a little bit about the Soy Latte thing... which might solve my problems), some applications GUIs freak out and don't work at all... so I had to turn my system default back down to 5.0. I had hoped that Eclipse would let me select 6.0 anyway, since it _is_ installed on my system, but it doesn't seem to recognize it, even when Java 6.0 is set as the default JVM. I almost always run Robocode through Eclipse, so that was what I meant when I said I didn't have Java 6... If you know how to get Eclipse to use Java 6, I would love to know how! (Oh yeah, and I didn't even know that Java 7 had been released, how long has that been out?) --BenHorner 02:57, 7 June 2009 (UTC)

I guess I just needed a little motivation... I just figured out how to tell Eclipse where Java 6 is, and now I can run Robocode through Eclipse and Watermelon works. (Those graphics _are_ cool. :) ) --BenHorner 04:04, 7 June 2009 (UTC)

Glad you like them. I've posted the code I used to draw the waves at Watermelon/Code. -- Synapse 05:38, 10 June 2009 (UTC)