MicroBot champ!
The highlighted comment was created in this revision.
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?
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.
