DrussGT/Version History

2.4.5 Some anti-Diamond tuning

2.4.4 APS: 89.02 Survival: 97.07 PL: 2 losses

• Back to 2.4.0
• Use a better target function for the genetic optimization of gun weights

2.4.2 APS: 88.91 Survival: 97.3 PL: 1 losses

• Add just a smidgeon of bullet power

2.4.1 APS: 88.75 Survival: 97.53 PL: 0 losses

• Make the bullet power a function of the difference between energy as well as bot energy and enemy energy

2.4.0 APS: 89.01 Survival: 97.04 PL: 0 losses

• Back to 2.3.7
• Weight the DC gun attributes with the results of a genetic optimisation...

2.3.8 APS: 88.84 Survival: 97.02 PL: 1 losses

• Don't make the direction reverse if the enemy is decelerating...

2.3.7 APS: 88.81 Survival: 97.01 PL: 0 losses

• Revert a change I forgot about to the anti-mirror attribute...

2.3.6 APS: 88.72 Survival: 96.98 PL: 0 losses

• Make gun direction reverse when enemy is decelerating
• Make GF-0 where the enemy would be if they decelerate now

2.2.2 APS: 88.9 Survival: 97 PL: 1 losses

• Narrow the adaptive weighting

2.2.1 APS: 88.75 Survival: 96.89 PL: 0 losses

• Widen the adaptive weighting

2.2.0 APS: 88.87 Survival: 97.03 PL: 0 losses

• Use an adaptive Gaussian weighting of gun scans, rather than inverse distance

2.1.9 APS: 88.86 Survival: 97 PL: 0 losses

• Do forward prediction on where the bullet shadows will be, and clear the relevant ones when a BulletHitBullet happens.

2.1.8 APS: 88.35 Survival: 96.74 PL: 0 losses

• Up the number of bins from 101 to 171... see if this makes any difference. Also change the smoothing function to stay the same with more bins...

2.1.7 APS: 88.38 Survival: 96.77 PL: 0 losses

• Add some passive Bullet Shadows to my surfing...
  • Currently they only get logged as the bullet passes through the wave... future revisions may predict where the hits will be before they happen...

2.0.7 APS: 87.99 Survival: 96.38 PL: 1 losses

• Entertaining a hunch I've had about why Manhattan Distance works better for me than Euclidean Distance... so trying, as a distancer, sum of sqrt(abs(diff))
  • I think this is because once an attribute is far off, I don't want to penalize increasingly more if it gets further, rather penalize on a decreasing scale. So try sqrt, and if that works try cbrt as well.

2.0.6 APS: 88.06 Survival: 96.38 PL: 0 losses

• The distance-last-10 segment in the movement had slices that weren't normalized... fix that
• Add 15 buffers for tick-wave flattening.

2.0.5 APS: 87.66 Survival: 96.15 PL: 0 losses

• Squashed that nasty occasional freezing bug... had to hack robocode to print out stack traces to track it down. It was due to something I had added to the points generation (the Apollon predictor) to keep making points if the predicted position was less than 60 pixels away. It seems that sometimes it can't get more than 60 points away?!?! Anyways... it was generating around 500 points instead of the usual 30, which caused my O(n^2) (for 2 waves) movement to be very unhappy.
• The after-enemy-death surfing was using my previous location, not my current location, so project forward using current vel/heading.
• Switch the queues in the surfing to be circular rather than shifting elements every time a new datapoint is added. DrussGT is now faster than ever...
• The x/y predictor wasn't entering 'direct high speed' mode due to a sign error... besides the skipped turns shouldn't be any different functionally though.

2.0.4 APS: 87.45 Survival: 96.08 PL: 1 losses

• Less pruning helped, so re-enable the X/Y predictor

2.0.3 APS: 87.81 Survival: 96.22 PL: 0 losses

• Don't fast prune quite as much...

2.0.2 APS: 87.49 Survival: 96.12 PL: 3 losses

• Switch back to the linear predictor...

2.0.1 APS: 87.58 Survival: 96.09 PL: 2 losses

• Change my 'famous' linear goto predictor to one which uses X/Y coordinates, and add in some boundary checking.
• Use a much faster technique for pruning unreachable goto points.

2.0.0 APS: 87.86 Survival: 96.24 PL: 0 losses

• Limit the main (DC) gun to only shoot within the min/max MEAs
• Don't delete imaginary waves if the enemy died

1.9.9APS: 87.7 Survival: 96.07 PL: 1 losses

• Remove the PM gun as well as the DC antisurfer gun
  • this leaves the DC main gun and the VCS antisurfer gun
• Change the main gun to use BFT instead of distance

1.9.8 APS: 87.64 Survival: 96.24 PL: 1 losses

• Finally introduce precise max escape angles
• Make the DC-AS gun into a normal, bullet-wave only DC gun

1.9.7 APS: 87.47 Survival: 95.97 PL: 1 losses

• Due to a problem with compilation in 1.9.1, the pattern matcher shot GF 0 the entire time, and also somehow had the highest score to date. So disable the pattern matcher to see if that makes a difference.

1.9.6 APS: 87.38 Survival: 95.84 PL: 2 losses

• Back to 1.9.1, add changes which prepare for precise GFs

1.9.5 APS: 87.6 Survival: 96.12 PL: 2 losses

• Back to 1.9.3
• Revert the changes in the VCS AS gun back to 1.9.2

1.9.4 APS: 87.54 Survival: 96.09 PL: 1 losses

• Revert the DC anti-surfer gun changes

1.9.3 APS: 87.59 Survival: 96.16 PL: 2 losses

• Some gun tweaks:
  • Switch the DC anti-surfer gun to work more like the regular DC gun, but only use bullet-waves
  • Change the VCS AS gun to smooth more strongly across dimensions
  • Add some structure so that I'll easily be able to integrate the precise min/max GFs I have planned.

1.9.2 APS: 87.47 Survival: 95.96 PL: 2 losses

• Remove the more-hits = higher bins weighting for against regular bots, still enabled in the flattener.

1.9.1 APS: 87.69 Survival: 96.24 PL: 1 losses

• Until now the rolling depth has been influencing the weight of buffers. I tweaked the buffers so that all the rolled hits add to the same weight, no matter if the buffer is weak or shallow, deeply rolled or not. However, it weights the deeper, quickly rolled buffers a lot higher when using the flattener.
  • BUG: the new pattern matcher was accidentally disabled...

1.9.0b APS: 87.31 Survival: 95.99 PL: 2 losses

• revert to 1.8.6 and apply only those changes which were intentional...

1.9.0

• Change the pattern matcher from symbolic string-based into one based on numbers. This version matches on lateral velocity, rebuilds using velocity/delta-heading, and has a cool way of linking lateral velocity with actual velocity to make sure that the prediction is in the correct direction. The pattern-matcher also segments the first 'character' based on forward-wall proximity (a-la-GF-gun) as well as distance. (Future variants may also match on advancing velocity.) The 5 longest matches are put into a set of bins, weighted by match length, and the highest bin is fired at. A bit complicated for a PM gun, but it runs quickly enough and is very accurate so I don't really care =)
• it seems that other things may have changed as well... will re-release ASAP

1.8.16 APS: 87.51 Survival: 96.2 PL: 0 losses

• Fix a small bug which may corrupt movement data if the prediction goes straight towards the enemy

1.8.15

• Internal version - not released

1.8.14 APS: 87.33 Survival: 96.08 PL: 1 losses

• Aggressively reduce firepower as energy diminishes. Hoping to up my survival score without ruining my bullet damage too badly.

1.8.13 APS: 87.39 Survival: 94.9 PL: 1 losses

• Tune rolling to better mimic real rolling averages by rolling the data once even if it the most recent data

1.8.12 APS: 87.28 Survival: 94.69 PL: 2 losses

• Fix my pre-logged GF0 hit (buffer weight was not being initialized, existed since 1.7.0)
• Instead of logging hits to buffers, instead I keep a list of the buffer indexes of the last N hits, where N is (rollingDepth+1). When time comes to surf the hits they are each logged to their respective index in a buffer, weighted according to how old they are and their buffer's rolling average. The buffer is then smoothed. This gives me the advantage of being able to make the main buffer-logging CPU usage based on the number of bins I have, and how spread the data is, instead of the number of buffers I have. Buffer memory consumption just dropped by ~10x as well =) This gives me the possibility to add many more buffer combinations (including deeper buffers, which help against Locke and also Pattern Matchers) in a later release. A real advantage in terms of speed is that often different buffers are all pulling up examples of the same hit. These would all be logged to the same index, so would only have to be smoothed once, instead of having all their smoothed results added. Bins that don't have any hits logged to them don't need to be smoothed. Really hoping there are no bugs in this ... =)

1.8.11 APS: 87.36 Survival: 94.86 PL: 3 losses

• Shift all the internals of my movement over 1 tick. The painting doesn't look quite right now, but the code makes a bit more sense =) It is 'correct' now, not just tuned to 'what works', while being functionally equivalent.

1.8.10 APS: 87.38 Survival: 94.95 PL: 1 losses

• More conservative with bullet power in the endgame, and make sure that ALL bullets at all times follow the x.x5 pattern to exploit the bug in BasicSurfer.

1.8.9 APS: 87.25 Survival: 94.47 PL: 3 losses

• Use GF0 as their current position, not their next position (because that is how I define it when it gets saved, duh)

1.8.8 APS 87.01 Survival: 94.05 PL: 2 losses

• Change the gun waves 1 tick forward again

1.8.7 APS 86.8 or so...

• Fix a one-off bug in the virtual-guns system. This bug was also in the main gun (they use the same waves) so fixing one fixed the other. It also fixed this bug in the anti-surfer gun at the same time. The reason I didn't pick this up earlier was because I was marking the *current* wave as having the bullet, not the wave fired 1 tick ago (which was used for aiming the current bullet). Because of this the waves were 1 tick off so that they would line up graphically with the actual bullet. It seems that this may have been a bit of a performance enhancing bug, at least as far as the main (DC) gun goes. Hope not.
• Make a onBulletHitBullet() call prevent the virtual guns from logging that wave as a hit. This is to eliminate noise when choosing guns for surfers.
• Only wait for the gunTurnRemaining() == 0, and not for the last tick to line up with this tick when firing.

1.8.6 APS: 87.29 Survival: 94.64 PL: 2 losses

• Back to a default distance of 500
• Decide cleverly whether to wait until correctly aimed.

1.8.5 APS: 87.05 Survival: 94.17 PL: 2 losses

• Wait until gun has lined up with last aim again.
• Increase desired distance from 500 to 650

1.8.4 APS: 87.11 Survival: 94.5 PL: 2 losses

• Don't fire until there is data
• Don't wait until the gun has lined up with the last aim to fire.

1.8.3 APS: 87.13 Survival: 94.56 PL: 2 losses

• Back to 1.8.0
• Use linear targeting until there is data.

1.8.2b - about 0.7% below 1.8.0

• Only 5 scans were used for aiming, which I had hardcoded for the multi-tree experiment. It is now a dynamic number, so that a total of 100 scans are always pulled.
• There was a small bug which could occasionally trip up the tree-weighting algorithm when only one tree was present. Didn't affect much since it was caught. Fixed! (you can see the exception logged if you look in DrussGT 1.8.2's data directory after many battles have been run)
  • I suspect there is another bug here somewhere...

1.8.2 - about 1% below 1.8.0

• Keep the tree framework but only use the 1 big tree (more testing on this when I have time)
• Give linear interpolation of partially covered bins another shot. Last time it was a failure, but this time I have some addition checks.
  • some bugs, listed in 1.8.2b

1.8.1 APS: 86.8 Survival: 94.23 PL: 2 losses

• Try using lots of trees with lower dimension count for the gun, rather than one big gun. Weighting will come later. Local tests show that it's about the same scoring as the old gun. Currently using 20 trees with 4 dimensions each, rather than 1 tree with 11 dimensions. Dimensions are spread completely randomly over the trees.

1.8.0 APS: 87.26 Survival: 94.72 PL: 6 losses

• Back to 1.7.0 to avoid any bugs that may have crept in
• Keep some changes I made, so that DrussGT is no longer logging hits to the flattener or pulling the flattener buffers unless the flattener is enabled.
• Fix the bullet power x.x5 issue
• Set the bullet power to 1.95

1.7.8 - lower than 1.7.0

• Weight higher if the hits in the bin are more spread out, instead of lower (as previous attempts did)

1.7.7 APS: 86.84 Survival: 94.45 PL: 3 losses

• Comment out the attempts at weighting buffers based on entropy/clustering of hits...
• Change the default bullet power to 1.95
• Keep some changes I made, so that DrussGT is no longer logging hits to the flattener or pulling the flattener buffers unless the flattener is enabled. Should improve the speed somewhat.

1.7.6 APS: 86.73 Survival: 94.15 PL: 3 losses

• Sort the data before putting it through the below algorithm, as the algorithm was assuming it was sorted! Duh...

1.7.5 - pulled

• Some tweaks to my weighting system - previously would weight buffers with higher rolling averages higher, even though the main algorithm already accounts for this. Now dividing 'perfectly spread data' by max instead of max^2;

1.7.4 APS: 86.7 Survival: 94.15 PL: 1 losses

• Rather try weighting by my own system of calculating how unevenly the hits are spread over the bin.
• Also, rather than keeping n hits (as in 1.7.3) I keep (int)(rollingDepth + 1.5) hits. Saves memory, and accounts for a changing enemy gun better.

1.7.3 APS : 86.08 Survival: 93.60 PL: 5 losses

• Back to a max depth of 6 for the movement buffers
• Weight each individual set of bins by the inverse (variance of bin index + 1) of the last n hits recorded to that buffer. Where n is the square root of the weight of the buffer. And where the weight is the product of each (dimension size + 1) of that buffer. This is my first step towards implementing Boosting.

1.7.2 APS: 86.98 Survival: 94.22 PL: 6 losses

• Make the movement buffers have a max depth of 4 dimensions instead of 8 (1.7.1) or 6 (pre 1.7.1)

1.7.1 APS: 86.49 Survival: 94.05 PL: 4 losses

• Make the movement buffers have a max depth of 8 dimensions (instead of the previous 6)
• Increase the number of flattener buffers from 20 to 35

1.7.0 APS: 86.98 Survival: 94.26 PL: 1 losses

• Revert to 1.6.14
• Fix the acceleration segment in the AS gun
• Make the movement only allocate buffers for the VCS as it needs to write to them. This lowers the memory consumption considerably, and paves the way to adding 'deeper' buffers

1.6.17 APS: 86.87 Survival: 94.05 PL: 1 losses

• Revert the 1.6.15 changes (ie make those gun dimensions linear again)
• Add back the linear iteration of the mirror position removed in 1.6.14

1.6.16 APS: 86.94 Survival: 94.1 PL: 3 losses

• Fix a bug in the acceleration segment of my anti-surfer gun brought to my attention by Navajo

1.6.15 APS: 86.98 Survival: 94.26 PL: 0 losses

• Make some of the dimensions in the gun non-linear (following either cubic or sqrt instead of linear, as previous)

1.6.14 APS: 87.05 Survival: 94.29 PL: 3 losses

• Remove the linear iteration from 1.6.13
• Use the actual value of the anti-mirror dimension when storing the scan, rather than the predicted value

1.6.13 APS: 86.84 Survival: 94.08 PL: 3 losses

• Modify this new dimension (from 1.6.7) so that the position is iterated forward linearly from it's last known state until the currently fired wave passes over.

1.6.12APS: 86.97 Survival: 94.25 PL: 2 losses

• Fix some more...
  • and no more errors! hooray!

1.6.11APS: 86.94 Survival: 94.19 PL: 2 losses

• Fix some of the NPEs 1.6.10 made me aware of

1.6.10 APS: 86.77 Survival: 94.05 PL: 4 losses

• Add a try/catch around all the new code (since 1.6.6) to see if I can find where the score loss has crept in. It prints any errors to file, so once this is stable I would really appreciate if people who are running rumbles could check its data files and give me any stack traces it has written (I'll be checking mine as well, but this seems a very sporadic error). Thanks guys

1.6.9 APS: 86.75 Survival: 94.01 PL: 1 losses

• Keep all the code for the new dimensions, but don't add the value to the gun. This is to check if exceptions are still being thrown as compared to 1.6.6

1.6.8 APS: 86.87 Survival: 94.09 PL: 1 losses

• Reduce the weighting on the anti-mirror attribute

1.6.7 APS: 86.76 Survival: 93.98 PL: 3 losses

• Add a cool new dimension to the DC gun which should help a little against all bots, but mostly against mirror bots
  • had lots of bugs which threw exceptions, the a/b/c/d notations were bugfixes, with d being bug-free

1.6.6 APS: 86.96 Survival: 94.12 PL: 3 losses

• A bit of tuning

1.6.5 APS: 86.92 Survival: 94.08 PL: 1 losses

• The release 1.6.3 should have been. Did a lot of graphical debugging and finally discovered I needed to split the prediction to cover anti-clockwise orbiting and well as clockwise. From now the two predictions (which run in parallel) are checked at the end and any point which doesn't match up is ignored in the prediction, and painted red on the graphical debugging.

1.6.4 APS: 86.6 Survival: 93.91 PL: 4 losses

• Revert the first bugfix mentioned in 1.6.3, keep the second one

1.6.3 APS: 86.75 Survival: 93.96 PL: 4 losses

• Another stab at fixing that big bug mentioned in 1.6.0:

Fix a long-standing bug where predictions would take place until the waves hit the point fed to the goto-method, not the prediction point

• Fixed another bug, where the predictions for the second wave would be continued from when the wave hit the goto point, not the bot

Funnily enough, due to the strange structure of my goto-style, this can/needs to be fixed completely separately from the above bug

1.6.2 APS: 86.88 Survival: 94.05 PL: 1 losses

• Revert to 1.3.14
• Fix a smaller bug, but not the big bug yet (waiting for more time, exams now!)

1.6.1 APS: 84.51 Survival: 91.89 PL: 16 losses

• Hopefully completely squash that second-wave-not-being-updated bug. Did a bit of restructuring in the process, it makes the bot a little less voodoo-ish =) I now understand what some of the tuning variables did, and why they aren't needed anymore.
• Did a bunch of wave-suffering to get this right - went from ~97% against WSC BotA back up to 99.9, without tuning, just bug-fixing.
  • Obviously didn't get it :-/

1.6.0 APS: 85.53 Survival: 93.15 PL: 7 losses

• Fix a long-standing bug where predictions would take place until the waves hit the point fed to the goto-method, not the bot
• Remove some tweaks and do all the tuning to be 'by the book', ie. according to robocode physics
• Kept the anti-aliasing. It seems to hurt my score, so may release a version without afterwards
  • Found a huge bug, where the second wave would be surfed as if it hadn't advanced while the first wave was being surfed. I'm actually very surprised this version scored as well as it did, considering.

1.3.21 APS: 86.29 Survival: 93.38 PL: 3 losses

• Revert all the way back to 1.3.12
• Apply a few tweaks/fixes that have happened since then such as:
  • Updating to the latest (hacked) tree by Rednaxela
  • A tiny bit of anti-aliasing on the retrieval side
  • Fixed a bug in the getFactorIndex that would provide a cast int instead of a rounded int.
  • A small speedup in the logging of hits
  • Changed the bullet-power-prediction tree to be Rednaxela's one

1.3.20APS: 86.84 Survival: 93.99 PL: 3 losses

• Play with the anti-aliasing a bit...

1.3.19 APS: 86.6 Survival: 93.63 PL: 4 losses

• Re-applied heaptree fix from 1.3.15 that was reverted
• Scaled the movement GFs by 0.9 so GFs are now measured up to 1.11111... to take into account the botwidth
• A few small movement speedups

1.3.18 APS: 86.6 Survival: 93.75 PL: 4 losses

• Fixed off-by-1 bug in the anti-aliasing, which explains why it seemed to hurt my score...

Maybe not? Will investigate later...

1.3.17 APS: 86.6 Survival: 93.75 PL: 3 losses

• Revert to 1.3.14
• Add bin-antialiasing (ie. only to bins, not across segments) to the movement, I thought I was already doing this, I guess not.

1.3.16 APS: 86.62 Survival: 93.77 PL: 7 losses

• More aggressive with the dynamic buffer weighting, otherwise it never even adapts as much as my previous fixed weightings based on number of hits in bucket.

1.3.15 APS: 86.55 Survival: 93.67 PL: 6 losses

• Try doing one of my old ideas for dynamic weighting - each set of bins is weighted individually, weights are incremented each time hits are logged based on how similar the bins were to the 'hit bins' I am logging.
• Fixed bug in my hack of the heaptree so that so that it removes the closest point before adding the new point, so that it removes an old point and not the new one =)
• Tuned the DC anti-surfer, but don't have it enabled yet as it still under-performs all my other guns.

1.3.14 APS: 86.87 Survival: 93.97 PL: 2 losses

• Also check the indexes of the re-used imaginary-wave data to make sure it hasn't been changed
• Hacked Rednaxela's tree to remove the closest point to the one being added, instead of the oldest point
• (also played with a DC antisurfer gun using the hacked tree, but no luck so far - my VG was still choosing the VCS one, so I commented it out)

1.3.13 APS: 86.66 Survival: 93.62 PL: 2 losses

• Revert to 1.3.12 (highest scoring and fastest running)
• Re-use stat data from imaginary waves like in 1.5.2
• Do a bit of double checking, so that if the bins need to be recalculated the predictions definitely also get recalculated
• Update to Red's latest tree (1.3.12 was using an old one)
• Change the bullet power predictor to use Red's tree instead of Simonton's

1.5.3 APS: 86.03 Survival: 93.29 PL: 6 losses

• No longer disable imaginary waves
• Use the next-velocity predictor from Robocode 1.7.4beta in my precise prediction formula instead of the slightly incorrect one I had before

1.5.2 APS: 86.59 Survival: 93.67 PL: 4 losses

• Seems the onDeath changes in 1.5.1 didn't really affect anything, so I reverted them
• Now gets data for the real wave from the imaginary wave (if it exists) but still recalculates movements
• Disable imaginary waves if they only match a real wave less than 80% of the time

1.5.1 APS: 86.76 Survival: 93.82 PL: 3 losses

• Somehow I added in onScannedRobot and onBulletHit into the onDeath handling, so reverted that because I think it sometimes causes problems

1.5.0 APS: 86.79 Survival: 93.9 PL: 5 losses

• Made DrussGT.java just a wrapper class, so that it is now as pluggable as Dookious, CassiusClay etc
• Updated to Rednaxela's latest kD-Tree which includes an option for Manhattan Distance - thanks for your continued work on this, Red.

1.3.12 APS: 86.95 Survival: 94.02 PL: 2 losses

• Tweak those speed mods so that they (hopefully) have less 'side effects' =)

1.3.11ny APS: 86.51 Survival: 93.51 PL: 6 losses

• Actually changed the distance in the gun tree to Manhattan
• And: possibly fixed a bug in the code that decides whether the second wave is being surfed (doesn't affect whether it gets surfed, just whether it is acknowledged as having been surfed)

1.3.11

• Only recalculate movement options when adding a wave (gunheat or normal) if there is no second wave already being surfed.
• Optimize the logging of hits to eliminate 99% of divisions, replaced with multiplications
• Further optimize logging hits to only use the actual rolling average formula within 20 bins of the hit bin - outside this it simply assumes it is rolling the value towards 0.
  • These mods seem to eliminate 95% of the skipped turns on my system! Hopefully there's no noticeable performance decrease...
• Update Rednaxela's tree to the latest version, changed the distances back to Manhattan
  • • Somehow missed the Manhattan Distance change... oops. Next one out ASAP

1.3.10yew APS: 86.93 Survival: 94.05 PL: 2 losses

• Now using the fixed tree - thanks for the speedy work, Rednaxela =)
  • Also removed workarounds I had in place to account for the bug...
• Tweaked the radar to have a wider arc, so hopefully will deal with skipped turns better

1.3.10wilo APS: 86.85 Survival: 93.96 PL: 3 losses

• Using Rednaxela's new tree which was modified to use Manhattan Distance instead of squared Euclidian

1.3.10 APS: 86.89 Survival: 94.05 PL: 2 losses

• Made the flattener have less buffers but more active dimensions per buffer
• Stopped weighting the gun scans inversely (hurts my score against Shadow and Hydra)
• Applied several speed optimizations to the movement
  • Now only needs to calculate the buffer indexes once for both the main and the flattener buffers
  • Removed the loop from the danger function, replaced it with two sum from 0...K formulas
  • Re-enabled (and fixed a bug with) caching the dangers of the points on the second wave which are close enough not to require precise prediction.
• Made the remarkable discovery that it is the DC gun which is causing me to skip turns. Perhaps time to write my own (speed optimized) KD-Tree? Or maybe remove a dimension or 2.
  • In light of this, reduced the max cluster size from 100 to 70

1.3.8fast APS: 86.84 Survival: 93.90 PL: 2 losses (Shadow and Hydra)

• Revert to 1.3.8
• Apply some changes to the 'complicated linear prediction' that could speed it up significantly. Just releasing to test that there aren't any small bugs that I didn't catch in local testing.

1.4.1 APS: 86.42 Survival: 92.45 PL: 4 losses

• Completely reworked the bullet power selection algorithm:
  • Projects energy changes forward for bullet powers 0.09999 to 2.99999 in 0.1 steps
  • Bases best bullet power on:
    • Bullet damage
    • Survival
    • Kill bonus
    • Bullet damage bonus
    • Calculated in the way Roborumble calculates score%: score1/(score1+score2)
• Be warned! If you look at the code you probably won't understand it! It is MESSY!
• TODO: calculate the actual average distance bullets are fired from instead of simply using 400

1.4.0 APS: 86.81 Survival: 93.72 PL: 2 losses (gah! one was Wintermute!)

• Re-enabled the inverse weighting
• Shoots with a bullet power of 1.99 as standard
• Shoots with a bullet power of 2.4999 if the enemy is more than 16 energy below ours

1.3.9 APS: 86.73 Survival: 93.81 PL: 3 losses

• Tried reverting just the inverse weighting of gun scans

1.3.8 APS: 86.96 Survival: 94.00 PL: 2 losses

• PM gun matches on velocity/delta heading again
• Change the base bullet power back to 2, not 1.9
• Weight the gun scans in the DC gun by inverse Manhattan Distance when aiming

1.3.7 APS: 86.44 Survival: 93.2 PL: 4 losses

• Add acos to the FastTrig - should speed up movement considerably
• Changed the PM gun to match on lateral/advancing velocity (although it still rebuilds with velocity/delta-heading)
• The AS gun now smooths over all dimensions
• Change the bullet power rules slightly, so it shoots with more power relative my energy, and less relative to the enemy, but still enough to kill them

1.3.6 APS: 86.53 (ELO is Dookious+19) Survival: 93.6 PL:2 losses

• Revert to 1.3.3
• Fix bug in PM gun which caused it to only shoot HOT
• Make the change in rules for the VG based on how many rounds have been played, not on hitrate

1.3.5wua ~ 3 points lower than 1.3.5

• An experiment: like 1.3.5 but waits until it is aimed correctly within 1 botwidth to fire

1.3.5 below Dookious -- buggy?

• Fixed VG bug - Thanks for catching that Nat
• Changed limits that additional guns get disabled at, now less likely to disable them

1.3.4 below Dookious -- buggy?

• Cleaned up the VG a bit to weight the guns differently depending on the overall hitrate
  • CREDIT: Nat who adapted some code from Dookious
• Completely disable the AS and PM gun after 10 rounds, if they are not being used, to speed up execution

1.3.3 (Dookious +17, 3rd PL)

• Add a 3rd gun to the virtual gun array, a specifically designed anti-surfer gun. Lightly segmented VCS/GF with low rolling averages (3), 1/20th of weight to non-firing waves, logging hits and bullet hits negative at twice firing wave weight. Now demolishes WaveSerpent, hopefully some others too. Next is working on the VG selection mechanism, I'm not really happy with it.

1.3.2 2094 (Dookious + 17) (Drop in score, significant increase in PL)

• Add a virtual gun with Waylander's gun (and did a bit of refactoring to allow more virtual guns to be easily added inside the wave code)
  • Mostly just a proof of concept, I don't think it will do much to help my score - next in line will be developing a dedicated AntiSurfer gun
• Also added Rednaxela's FastTrig. Not sure how much it will help, as my sin/cosine use is fairly limited. A sqrt/acos version would probably speed DrussGT up the most...

1.3.1 (Dookious + 24)

• Change the gun time-based attributes to use the forumula Rednaxela used, ie. position = 1/(1 + k*time)

1.3.0 - 2148 (Dookious +20)

• Revert movement back to 1.2.1 in hopes of getting rid of that HOF bug
  • Re-apply some speedups and bugfixes
• The points-creation precise prediction rotates around a linear projection of the enemy's movement, n ticks forward

1.2.7

• Fixed a bug in the 'second wave' surfing which definately affected the debugging, and possibly affected the surfing. Had to do with pointer assignments vs. object cloning...
• Leave out the botwidth being dependant on the angle in the movement. This cures the movement's "skipping turns" problem, hopefully permanently.

1.2.6TC

• Change the distancer to a 'Multiplicative Manhatten' type, ie. distance = (1 + abs(a1 - a2))*(1 + abs(b1 - b2))* etc...
• Seems to work well =) Maybe try 'Multiplicative Squared Euclidean' or play with the weightings? Interesting stuff.

Aspd	Sprw	Fhqw	Yngw	FlMn	EASY	Tron	HTTC	RnMB	DlMc	Grbb	MEDIUM	SnDT	Cgrt	Frtn	WkOb	RkMc	HARD	TOTAL	Comments
94.94	99.13	98.15	98.23	94.57	97.00	90.71	87.85	91.53	88.80	88.79	89.53	88.09	85.24	81.71	88.13	81.93	85.02	90.52	80.0 seasons

• • Hurts the score against surfers quite a bit. So I've gone back to the Manhattan distance.

1.2.5TC

• Remove the Singularity stuff (commented out +-10 lines)
• So effective diff between 1.2.2 and 1.2.5 is just the Squared Euclidean/Manhattan distancer swap (although there was a tiny bit of refactoring to accommodate Singularity)

Aspd	Sprw	Fhqw	Yngw	FlMn	EASY	Tron	HTTC	RnMB	DlMc	Grbb	MEDIUM	SnDT	Cgrt	Frtn	WkOb	RkMc	HARD	TOTAL	Comments
95.14	98.96	97.90	98.49	93.60	96.82	90.64	86.53	91.31	87.81	87.61	88.78	87.00	84.58	82.03	87.84	82.09	84.71	90.10	80.0 seasons

1.2.4TC

• Revert to 1.2.2
• Attempt to merge in some Singularity ideas
• Make the DC distancer use squared Euclidean distances (avoid slow sqrt) instead of Manhattan distances (should be similar speeds)

Aspd	Sprw	Fhqw	Yngw	FlMn	EASY	Tron	HTTC	RnMB	DlMc	Grbb	MEDIUM	SnDT	Cgrt	Frtn	WkOb	RkMc	HARD	TOTAL	Comments
95.15	99.17	97.57	98.20	94.64	96.95	90.31	86.74	90.47	88.23	88.13	88.78	87.21	84.53	82.12	86.55	82.14	84.51	90.08	80.0 seasons

1.2.3TC

• Aim for next tick so the enemy is at their 'next' position

Aspd	Sprw	Fhqw	Yngw	FlMn	EASY	Tron	HTTC	RnMB	DlMc	Grbb	MEDIUM	SnDT	Cgrt	Frtn	WkOb	RkMc	HARD	TOTAL	Comments
95.03	99.09	97.48	98.44	93.90	96.79	90.70	87.27	90.98	88.79	87.97	89.14	87.99	85.74	81.54	86.84	81.80	84.78	90.24	71.7 seasons

1.2.2 - 2177 (Dookious + 16)

• Gun no longer uses the 'smoothing' method for aiming, instead firing purely at the highest overlap of precise ranges.

1.2.1 - unreleased

• Fixed bug where the gun 'aiming' code was called twice, causing the same cluster to be extracted twice from the tree, and then the same angle to be found from the cluster. Gun should be much faster now.
• Fixed movement bug where the single HOT hit that was pre-logged wasn't logged to an unsegmented buffer. In fact, there was no unsegmented buffer.
• Fixed minor bug in precise-prediction movement code that would corrupt the movement prediction if the bot 'overshot' the point it was going to.

1.2.0 - results corrupted

• Gun:
  • All recorded GF's are now calculated precisely, as a range
  • If the cluster is bigger than 30 (ie. tree is bigger than 900), fire halfway across the sub-range where the most recorded ranges overlap, otherwise use old 'smoothed' method (using center of each range as recorded GF)
  • No longer use Event based waves, instead process them in a loop every tick
• Movement:
  • Complete rework of buffer code to speed up retrieval of buffers. Instead of calculating the index for every segment for every buffer, I keep a set of "Slice Retrival Indexes" for each buffer. I calculate the index for each set of slices, and then simply 'retrieve' them for each combination the buffer may have.
  • Only use the 'deadline goto' if the flattener is enabled.
  • Don't rebuild all the waves' dangers after logging a flattener hit. (They can't change the bullets in the air)
  • Add Advancing Velocity segment

1.1.5 - 2157 - Dookious + 4

• Cleaned up the buffer loading code
• Doesn't go to a point immediately if it will be waiting there afterwards - prevents giving away early clues to strong guns

1.1.4 - 2161 - Dookious + 9

• Added another attribute to the gun, one that I think most surfers *don't* have, in a hope of improving my antisurfer targeting. Attribute is 'last recorded GF logged'
• Weight each buffer on how effective it is against BulletHitBullet event logs. Weights are rolled very slowly (depth of 50 for main buffer, 20 for flattener)

1.1.3 - 2158 - Dookious + 7

• Changed the gun back to the old 'based off of guessfactors' one
• Cleaned up a bunch of the movement internals to use methods and loops instead of recursive functions that did more than they were originally intended to =)
  • possibly fixed a few bugs/surfing details during the cleanup - it helps when you can actually follow the logic instead of just trial-and-error for which is correct =)
• Normalize the surfing data on the area instead of the height (I was thinking of doing this a long time ago but never got around to it - thanks to Rednaxela for the reminder =) ) - might make the flattener act a bit differently

1.1.2 - 2142 - Dookious - 11

• Actually fixed the 2-extra-turn problem to line up with the other wave correctly, it was created at the right time but with the wrong firetime
• Changed the gun to use Play-It-Forward instead of GuessFactors. Improves the score against SpinBot tremendously =)

1.1.1 - 2159 - Dookious + 6

• Fixed the 2-extra-turn to actually do 2-extra-turns, not 1. So I actually wasn't even getting the 1 turn advantage, because I was surfing the wrong tick. No wonder it didn't help.
• Went back to the old attack/retreat angles that I realised I changed in 1.1.0 - copied them in from 1.0.20NVBW

1.1.0NE2T - about Dookious - 20? I can't remember, but it wasn't good

• No Extra 2 Ticks =)

1.1.0NDC - 2154 - Dookious + 3.5

• No DynamicClustering in the movement

Lets see which of those features needs work...or if I broke something else in the process of adding them.

• It seems they were both a bit of a problem, although the DC was much worse

1.1.0 - 2140

• Now surfs an 'imaginary' wave for 2 ticks starting when the enemy's gunheat is 0, inspired by the work on RougeDC
• Accounts for the energy-diff due to robot-robot collisions - dunno how I had my good rambot scores without this. I still need to account for wall collisions, next release, I've got enough new stuff in here.
• Most importantly, it merges in Stormrider: there are 2 new sets of data for the movement, for bot visits and hits, kept for DynamicClustering. Parallel to both the normal surfing stats and the flattener is a DynamicClustering set of stats. Hopefully this will improve the surfing against DynamicClustering guns, as well as the random assorted bots that Stormrider did better against. Surfing 2 guns... even further in the CrowdTargeting direction!

1.0.20NVBW - 2151 (Dookious + 5)

• No variable bot width =)

1.0.20 - 2143

• Revert to 1.0.17
• Extended the maximum distance a goto point will be considered so that DrussGT predicts moving the whole time when the wave passes over.

1.0.19 - 2146 (Dookious + 1)

• 1.0.18 introduced a bug where the retreat angle was introduced and the sin of that angle was used to reduce the reachable GF even when an absolute angle was used. Now the retreat angle only affects the botwidth, not the reachable GF.

1.0.18 - 2146 (Dookious + 1)

• Fixed some assumptions in the precise botwidth calculations - could still be improved I guess, but not much

1.0.17NVBW - 2151 (Dookious + 6)

• No variable bot width in surfing - ie. botwidth doesn't depend on speed when the wave hits.

1.0.17 - 2145 (Dookious + 1)

• Doesn't wait to fire

1.0.16 - 2134 (Dookious - 7)

• Aims from the next point (actually, this time).
• Waits to fire until the gunturn of aiming from *this* point is less than 18/distance

1.0.15 - 2138 (Dookious - 3)

• Made the cluster bigger min(100,sqrt(scans))
• Chooses the other aim method if the cluster size is 100
• Doesn't wait until the gun is aimed before firing, but still starts aiming MEA/(PI/18) ticks before firing

1.0.14 - 2133 (Dookious - 7)

• Both aims and fires waves from the precisely predicted *next* location
• Uses a different angle-choosing method (similar to DCBot) if there is a large enough cluster (50*50*50)
  • Which never gets reached in a 30 round battle....duh....
• Smaller cluster extracted from tree min(100,cbrt(scans)) instead of min(100,sqrt(scans))

1.0.13 - 2129 (Dookious - 11) - rating drift is killer ATM.....

• Reverted to 1.0.10
• Now waits until the gun is aimed within 18/distance radians of this aim before shooting
• Fires 3 power bullets if the hitrate is above 33%

1.0.12 - 2131 - (Dookious-6)

• Reverted to 1.0.10
• The gun now fires from a rough estimate of where it will be next turn. This has a maximum inaccuracy of 2 pixels, whereas leaving this out has a maximum inaccuracy of 8 pixels.

1.0.11 - 2127

• The gun is now clustering on gunheat, (or distance from gunheat being zero), weighted same as accel and lateral velocity (ie. maximum the tree allows)

1.0.10 - 2132 to 2130 after the crash

• Another attempt at fixing that logical bug...this time it should be slightly more effecient, and should be functionally identical

1.0.9 - 2129.6 after 1798 battles

• Fixed a minor logical bug where "PredictionStatus" objects were not cleared from points which DrussGT was able to reach and stop on, resulting in them possibly 1) seeming more dangerous due to still moving, and thus a larger botwidth, 2) not being exactly where they should be, due to the prediction thinking they needed to be projected back to where was actually reachable and 3) probably being slightly slower than otherwise. Note: this only influenced the second wave, so should have little impact due to the second wave's low weighting.
  • Grr.....darn PerformanceEnhancingBugs
    • Or maybe it would have helped if that was the only change I'd made....messing with the surfing nitty-gritty is not a good idea when everything else is tweaked depending on it

1.0.8 - 2133 - 3 points below Dookious!

• Revert to 1.0.5
• Change the movement danger bins to use floats instead of doubles
• Fixed a bug that made DrussGT still use 151 bins worth of memory, while only utilizing 101 of them

1.0.7 - corrupted

• Increased flattener threshold again

1.0.6 - 2117 - corrupted

• Minor tweaks to the bot-depth, so it predicts surfing the wave for slightly longer
• Caches the dangers on the second wave for when the velocity is 0
• Decreased flattener threshold slightly

1.0.5 - 2132

• Reverted the segmentation changes
• The second wave now also enjoys the no-stop option to reach maximum GFs, and accounts for the increased botwidth associated with continued motion precisely
• The botwidth is dependent on the angle the enemy fires from
• Unfortunately I had to remove the danger caching on the second wave because of these...so 1.0.5 is quite a bit slower :-(
  • The re-release 1.0.5b might have had some small changes...I didn't just edit the .jar to reflect the version number, but instead re-packaged

1.0.4 - 2111.73 after 486 battles

• Revert to 1.0.1
• Made Druss consider the points on the end that would make him have to keep moving, instead of slowing down
• Made the bot-width and position change, based on what the speed is when the wave hits, in the danger calculation
  • Buggy, the bot-width increased twice as much as it should have, resulting in DrussGT stopping completely for every single wave
• Fixed the bin-width bug I found in 1.0.3
  • Accidentally made some changes to the segmentation when I was fooling around

1.0.3

• Weighting waves as /time-to-arrive, or /sqr(time-to-arrive) if the hitrate is below 3%
• Gone back to 1.0.1 segmentation
• Fixed bug where one bin did not get covered (the highest GF bin), and I'm now projecting the point I am aiming at back to where I can actually get to to make it not a PerformanceEnhancingBug
• Decreased the botwidth slightly to make up for the above bugfix

1.0.2 - 2114 after ~1800 battles

• Reverted my movement segmentation change to using 20 ticks instead, but kept the absolute value of the sum of the signed lateral velocities.
• A slightly different danger calculation, using danger/cbrt(dist) instead of danger/sqrt(dist), and the danger of each covered bin is squared before it is added.

1.0.1 - 2117.91 after 1509 battles

• Found a bug in the attempt at pixel-perfect, which made the second-wave surfing think it had to turn more than it actually did.
• Updated the wave-hit-time for when the bot is not able to reach a point, to the point it actually reaches. The second wave was already surfed from this point.
• Waves weighted as pow(0.88, time-to-arrive) at each point
• Fires a wave at min(the last seen bullet power, energy-left-before-bullet-hit) if the enemy is killed by my bullet when their gunheat was 0.
  • Somehow a movement segment that I was testing slipped into this release...I think it might be to blame for my amazing SandboxDT score. It replaced "sum of the absolute values of the lateral velocities of the last 20 ticks" with "absolute value of the sum of the signed lateral velocities of the last 8 ticks".

0.9.9 - 2119.61 after 1703 battles

• Reverted to 0.9.6, fixed the 2 bugs of 0.9.7 and 0.9.8, and found another one in future-prediction code

0.9.8 - 2100

• Fixed a bug in the so-called pixel-perfect, which was only pixel-perfect if the velocity was positive =)
• Now that the secondary wave is much more accurate, I'm weighting it much higher ( pow(0.92, time-to-arrive) vs pow(0.85, time-to-arrive) )
  • had a late night bug that I was too tired to remember...

0.9.7

• 0.9.6 accidentally weighted the flattener twice what the regular buffer was weighted, sorry 'bout that...

0.9.6

• Removed an old assumption with my second-wave surfing that could allow an inaccuracy of up to 6 pixels. It now surfs the second-wave pixel-perfect, without predicting the movement using co-ordinates =) Might be slightly slower...but not much.

0.9.5 - 2115.84 after 1669 battles

• Changed the non-surfing movement so that it checks both directions, and moves to the one that passes furthest from the enemy
• Added a flattener, using a section of the random buffers, weighted 50/50 with the regular buffers when enabled at a 10% (weighted) hitrate, after the second round. Tuned to only just enable for Ascendant, who beats me over 35 rounds, but who I beat over 100.
• Reduced the number of bins in the movement from 151 to 101, to reduce memory, and allow the use of a flattener and its increased buffer requirements

0.9.4 - 2111

• Changed the gun back to using advancing velocity instead of offset
• Changed movement and gun to use BFT instead of distance
• Changed the lateral-velocity in the movement to use doubles instead of integers - this should make the accel and time-since-decel more accurate
• Fixed a bug which would prevent it from regenerating points on the main wave when detecting a new wave - possibly making the reverse option harder to access

0.9.3 - 2108

• Some small tweaks to the gun segmentation - using offset instead of advancing velocity

0.9.2 - 2111

• A test, reverting all the way back to 0.7.23

0.9.1 - 2106

• Reverting the gun segmentation back to 0.8.7 - it must have been lucky when testing it.
• Changed the way it chooses an angle to fire at: no longer smoothes all the angles to a set of bins, instead checks which angle has the most other angles within a certain tolerance (12/current_distance). It also fires directly at the angle, instead of at a bin, making it slightly more accurate.
• Fixed a bug in the gun where it set the enemy location in the wrong class - I actually don't know how the gun was working at all.

0.9.0

• A bit of refactoring in the movement - I fixed one minor logical flaw, and also made part of the algorithm linear. It should be faster due to 250000+ less decisions for every wave it surfs.
• Added my new top-secret dimension to my gun, replacing distance-last-20. It seems to really help against RandomMovement
  • or maybe not...

0.8.7

• Now using the precise-predicted maximum forward and reverse GFs to 'weed out' any GFs that aren't actually reachable, instead of scaling them to fit

0.8.6 - 2108

• Fixed bug in gun, so now time-since-lateral-dir-change actually works - I'm not sure how long it's been like this
• Weighting movement buffers by sqrt of number of segments, instead of number of segments
• Added 'Shakespearean Insulter' - inspired by the quotes in Dookious =)

0.8.5 - 2106

• Fixed bug in calculating offset for gun
• Fixed bug in lateral acceleration in movement - it was being rounded, so would be able to trip the > 0.6 even if it shouldn't have.
• Using precise MEA as attribute instead of average of MEA and walldistance in gun
• Fixed bug in calculating MEA in gun, where 1.9 was always used, instead of actual bullet power

0.8.4 - 2105

• Finally fixed the Java 5 issue (I hope)
• Using offset instead of advancing velocity in the gun
• Using dist-last-8 with dist-last-8 slices instead of the (buggy) dist-last-8 with dist-last-10 slices for the movement
• Now accepts bullet-hit-bullet for the first piece of data IF the wave has traveled at least 2 ticks (otherwise there are sometimes bad readings for HOT bots)
• If the absolute acceleration is 0, segment on if the lateral acceleration is greater than 0.6 (both gun and movement)

0.8.3 - 2107

• A failed attempt at Java-5 compatibility

0.8.2 - unreleased

• Tweaking the gun a bit

0.8.1 - pulled

• fixed bug in gun - when converting GFs to angles the forward/reverse wall MEA was chosen on lateral direction instead of GF
  • It seems something still isn't right....

0.8.0 - pulled

• in movement:
  • reduced bins from 151 to 47 - mostly for speed, no noticeable performance change
  • reduced binsmoothing width to match new # of bins
  • fixed minor bug in dist-last-10 calculation, was 1 tick off
  • removed all (random) buffers that did not include velocity as a segment - hope this will help my surfing against simple targeters
• in gun:
  • calculates precise MEA
  • uses the (precise MEA)/asin(8/bulletVel) as an attribute, instead of standard arc wall distance
  • uses BFT instead of distance as an attribute
  • reduced bins (for choosing angle) from 151 to 47
  • reduced binsmoothing width to match new # of bins

0.7.25 - 2109

• -- all movement changes
• Fixed to segment on time-since-decel instead of time-since-accel
• Accel and time-since-decel are now calculated using the absolute velocity, instead of lateral velocity
• Changed the segment lateral-distance-last-20 into actual-distance-last-10

0.7.24 - 2108 after 1200 battles

• Trying out a preferred distance of 450 instead of 500

0.7.23 - 2108

• Lots of tweaks, now weighting different attributes in the gun

0.7.10

• MAJOR bugfixes in the gun:
  • For some reason, I wasn't clustering on acceleration
  • Accidentally taking the absolute value of advancing velocity.
• Bug introduced: I was moving in the TC...whoops!

0.7.6 - 0.7.9

• Unreleased
• Tested out several things, including weighting the segments and precisely predicted max-escape-angles. Neither worked.

0.7.5 - 2105

• Functionally equivalent to 0.7.4, but has 150000 less calls to Math.pow with each time it aims, or each time it sees a new wave. Replaced the Math.pow(x,2) with my own sqr(x) function.

0.7.4 - above 2100!!! - 2105

• Using the gun from Stormrider, after seeing what an improvement it was on my earlier attempts.

0.7.2

• Fixed a minor bug in the gun - probably didn't do anything
• Cluster size is sqrt of log size
• Added a max 'distance' cutoff
• Instead of squaring the distance, use power 4
• Increase log size to 50000
• Added gunheat attribute - although weighted fairly low

0.7.1

• Increased the log size ( A lot!)
• Increased the cluster size from 50 to 125
• Added in distance last {10,20,30} attributes, although weighted lightly

0.7.0 - 2083

• Using DynamicClustering for the gun
• Has a fairly small log size, a medium between surfer-killer and lowbot-thrasher

0.6.0 - 0.6.3

• Some experiments I was doing with DC for the movement - I think I learned some things, and this will be continued soon.

0.5.10

• That random selection of buffers really worked well, so I've tuned it a bit, weighting forward wall distance and distance as having a higher chance of being chosen. Pushed me above 70 in the MC2K7!

0.5.9 - 2082

• Added WallDistance segmentation (forward and reverse)
• I got lazy trying to figure out which buffers to add wall segments to, so I wrote a quick program that prints out 100 buffers with randomly chosen segments, and used those. Each segment has 1-4 randomly chosen attributes, with velocity having a much higher chance of being chosen than any of the others. Also, because of the maximum of 4 dimensions at a time, it has low memory usage (compared to what it used before). I could probably even increase the number of buffers (and/or the number of attributes) without using that much more memory. I feel that this is an extension of PEZ's CrowdTargeting, and it looks very promising, especially against top bots.

0.5.8

• Distance up again to 500
• Tuned max advancing/retreating angle (for both surfing and non-surfing) to be best against RamBots
• Dangers at the points on the second wave are cached, because each one gets referenced many times, and several trig calls are involved in checking the danger
• The danger weight of each wave is cached, this eliminates the need to recalculate it for each point on that wave

0.5.7

• Default distance back to 400
  • Being closer is stronger against bottom bots, for some reason

0.5.6

• I think I finally got most of the bugs out...
• Increased the default distance to 500 (from 400)

0.5.1 - 0.5.5

• LOTS of WaveSuffering

0.5.0

• As of 0.5, DrussGT now surfs 2 waves, using PrecisePrediction!

0.4.4

• Using 0.3.10's movement
• Fixed a major bug in the gun, which made accel/decel and time-since-decel random noise

0.4.0Vyper - 2075

• A test version using Vyper's gun

0.4.0 - 2045

• 0.3.10's movement
• Uses a highly modified version of GFTargetingBot's gun
  • Wall segmentation
  • Time since decel
  • Some structure in place for expansion of segments

0.3.17

• Revert to 0.3.10
• Weight later waves higher
• Move around enemy, not fire location

0.3.13 - 2064 - it seems that ImperfectPerfection does very little for your score

• Disabled the flattener

0.3.12 - 2058

• Added back the 'fine' segments
• Added a simple flattener - logs every wave as a hit (weighted 0.5) if enemy gets more than 40 damage per round
• Added ImperfectPerfection

0.3.11 - 2062

• Getting rid of all the 'fine' segments

0.3.10 - 2064

• 0.3.10PM with Raiko's gun instead

0.3.10PM - 2033

• Now also using distance-last-20-ticks and time-since-decel

0.3.9PM - 2028

• Waylander's gun is now 0.3.2's gun (it was set to be too picky on the delta-heading)
• Movement segments are optimized vs Shadow

0.3.4PM1 - 2026

• Shooting regular sized bullets =)

0.3.4PM

• A test version using Waylander's gun instead of Raiko's
  • What's more, it shoots 0.1 power bullets. Whoops =)

0.3.8 - 2055

• Trying the old method for generating goto points - as per BasicGTSurfer
  • • I didn't think that this segment (time since decel) would help, it pulled the mc2k7 scores way down.
    • I'm going to use 0.3.4 movement for my gun release (which will hopefully be soon)

0.3.7 - 2047

• 0.3.6, with the bug fixed

0.3.6 - 1927

• Giving the time-since-decel segment a try in the rumble
• Moves relative to the enemy again
• Slightly more accurate deceleration for precise prediction
• Uses a new method to generate goto points - should follow the PrecisePrediction better
  • had a major bug in the goto method - wouldn't try to turn if it was going backwards

0.3.4 - 2061

• segmentation tweaks (time-since-decel is disabled)
• Moves relative to fire location, not enemy location

0.3.3 (not released)

• Trying a time-since-decel segment
  • It didn't help against anyone except the pattern matchers, and made me more susceptible to Ascendant's anti-surfer gun.

0.3.1 - 2058

• Now using an easily extended buffer system
• Using lots more slices for each dimension

0.2.5

• Added more buffers

0.1.4

• Fixed a PrecisePrediction bug
• Above 2000!