DrussGT/Version History

1.3.20

• 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!

Insert non-formatted text here <math>Insert formula here</math>