MicroBot champ!

Congrats dude! From someone who knows how tough it is to dethrone Skilgannon... =)

Thanks!

I tried for a long time to improve the gun, but that didn't work so I ended up just copying Toorkild's new mode selection and improving anti-ram.

Now it's only a matter of waiting for Toorkild 0.4.6. :(

Wow, impressed that you managed to squeeze that in. Of course, Toorkild is now functionally equivalent at 711 bytes, the real issue is thinking of something to add =) And half of your score margin is from not being in LittleBlackBook's books... perhaps it is time for Waylander to make a comeback?

I wouldn't mind seeing Decado, Waylander, Toorkild, and Connavar back in the rumble. The rule is to not have multiple versions of the same bot in the rumble, not to not have multiple similar bots in the rumble.

Mwa Ha Ha!

I just did something absolutely brilliant which squeezed 14 bytes from the GFT system itself, and I now have 18 bytes free, plus ~9 bytes if I get desperate. Any ideas about what I should do with that space?

Huh, it seems it wasn't so brilliant after all. Version 1.9.0 is ~0.5 APS lower than 1.8.0.

The main change was to the way the wave system gathers bearing offsets. Version 1.8.0 used the traditional, coordinate-based method, whereas version 1.9.0 sums angular velocities. I made sure to keep it as precise as I could, I even adjusted the distance by which I divide the lateral velocity to calculate angular velocities with advancing velocities (actually negative advancing velocities, you might call them "retreating velocities") to account for the opponent moving toward or away from the source location of the wave.

Is there some obscure element of Robocode physics that makes sums of angular velocities inaccurate? Or is there a bug in my code?

Don't think anything about Robocode itself should lead to an inaccuracy. Could it be a normalization bug? When normalizing angles, an individual angle is equivalent no matter how it gets normalized, but if you're summing or averaging them it can screw things up. E.g., average of {2.9, 3.0, 3.1, -3.1, -3.0, -2.9} is 0, but you'd want the result to be something more like pi.

Normalization should be irrelevant because everything is already relative.

I might be on to something though. I'm wondering if the inaccuracy is coming from the original absoluteBearing being used to calculate LV and AV. Should it be updated with angular velocities?

You'd need to keep a list of the positions you were in and backtrace the enemy movement until the wave could originate at your location - a sort of backwards wave, as it were, otherwise you are getting the angular velocities from your current location, not from where you were when you wanted to fire. Also, are the indexes for the VCS calculated using the values from when you were firing, or when you are having the wave hit?

All segmentation is calculated when the wave is fired.

Why do you think I'm getting the angular velocities relative to EM's current location? I store the absoluteBearing from the tick in which the wave was fired, and both e.getVelocity() and e.getHeadingRadians() are absolute and shouldn't be relative to anything.

Thanks

Ah, OK, looking at the source I see that you've still kept the wave structure, I thought you had completely gotten rid of it and then each tick look back to see what wave would hit now over the last N ticks of bullet flight time and retro-actively construct the wave from the conditions as they were then. What you've done isn't quite that drastic =)

As for what is different, have you tried projecting the point back into the cartesian plane and printing it to see if it is the same as the actual enemy location? How about using both types of tracking at once and seeing if they are giving the same results at wave-hit time?