DrussGT/Version History

2.8.13

• Improve my bullet shadow handling a bit, should be more robust. I'm not getting hit by bullets in shadows any more, but I am hitting bullets in onBulletHitBullet that weren't in shadows, which makes me worried.
• Move the ticks back to where they were for surfing and just shift the shadows to where they were in 2.8.12
• Improve the painting a smidgeon.

2.8.12 APS: 0 Survival: 0 PL: 0 losses

• Back to 2.8.10
• While I was looking into the painting, I noticed that the enemy waves are painted differently to my waves (one tick differently). This is an attempt to fix that.
• Fix the bullet shadow cleanup. Also, now that the enemy waves have changed I'm not getting any hits by bullets in what should be empty bullet-shadow area! Hooray!

2.8.11 APS: 87.34 Survival: 94.81 PL: 4 losses

• Go back to the simple accel/decel rules for second wave surfing
• Fix bullet shadow bug where shadows created from adding waves were wrong, but shadows created from adding bullets were right. This was due to when the updateWaves() function was called (in between them) - now the shadows are created using fireTime as a starting point instead of distanceTraveled.

2.8.10 APS: 90.54 Survival: 98.1 PL: 0 losses

• I wasn't calling onBulletHitBullet in the gun, so the VG thought all wave hits counted. VG should be more accurate now.
• Use the 'fancy' rules for the second wave accel/decel

2.8.9 APS: 90.59 Survival: 98.18 PL: 0 losses

• Fix a bug in the goto point filtering. Goto points should now be more evenly distributed along reachable area
• Increase range of goto point generator to account for (fixed) goto point filtering
• Remove unused precise prediction methods
• Remove point cloning which is not necessary now that I generate a new goto point set for each location I evaluate second wave points from (since 2.7.20)

2.8.8 APS: 90.45 Survival: 98.03 PL: 0 losses

• Those were not the AS gun weightings I was looking for. It seems that using WaveSim-ish techniques coupled with genetic algorithms against adaptive movement really breaks down against the super-fast-adapting flatteners, so tune against Hydra!

2.8.7 APS: 90.46 Survival: 98.01 PL: 1 losses

• Back to 2.8.4
• Retune AS gun based on a few more battles

2.8.6 APS: 90.08 Survival: 97.76 PL: 1 losses

• Back to 2.8.4
• Tweak no-wave escape angles
• Add preliminary structure for data poisoning

2.8.5 APS: 90.41 Survival: 97.99 PL: 1 losses

• Make each aiming kNN scan evenly probable - divide weight by (maxGF-minGF)

2.8.4 APS: 90.46 Survival: 98.03 PL: 0 losses

• Movement back to 2.8.0

2.8.3 APS: 90.44 Survival: 98.01 PL: 0 losses

• Disable future waves until I can figure out what is going on - why they don't give me any score boost
• Minor movement tweaks
• Limit the bullet power so that the bullet will only cause damage for the energy they will have when it hits

2.8.2 APS: 90.3 Survival: 97.92 PL: 1 losses

• Disable my 'tricky path to destination' if I am using future waves - it would upset the buffers selected

2.8.1 APS: 90.34 Survival: 97.88 PL: 1 losses

• Give another stab at Future Wave surfing now that I am:
  • Predicting enemy movement
  • Recalculating goto points for each second wave movement option

2.8.0 APS: 90.38 Survival: 97.96 PL: 0 losses

• Back to 2.7.25
• Predict the enemy's movement and use it for:
  • Orbit center for generating goto points
  • Point for evaluating distance to enemy for danger function
  • Note: I am just using a simple 1-NN PIF method for generating locations, I will upgrade to something more robust in the future.

2.7.26 APS: 90.21 Survival: 97.85 PL: 0 losses

• Make it more dangerous being close

2.7.25 APS: 90.34 Survival: 97.92 PL: 0 losses

• Fix small bug in the bullet power prediction algorithm - it was comparing the test item to itself when assigning a weighting/score, not just the others (doing kernel density)
• Don't fire enemy waves unless their gunheat is 0 - I thought I already had this, turned out it was missing?!

2.7.24 APS: 90.37 Survival: 97.98 PL: 0 losses

• Generate a few less points for the GoTo point creation
• Delete some of the filters for the GoTo points, they are no longer needed since I create a new set of points for each start position
• Add another filter which removes points if there is already another point within 4 pixels of it (trying to get the speed up for the Next Big Thing)

2.7.23 APS: 90.33 Survival: 97.94 PL: 0 losses

• Scale surfing GFs by 0.9 so that 1) all of the bot is covered by the danger and 2) detected shots which go over the edge aren't rounded down to GF1
• Use a faster bullet power prediction algorithm for gunheat waves, should also be more accurate

2.7.22 APS: 90.28 Survival: 97.9 PL: 1 losses

• Lower thresholds for the flattener in later rounds - it seems with all of my improvements, I'm only reliably flattening against a few bots even though it helps against quite a few more.
• Fix a minor bug in the coarse advancing velocity segment - slices went {-2, -4, 3} instead of {-4, -2, 3}

2.7.21 APS: 90.23 Survival: 97.84 PL: 1 losses

• Fix the bug in second wave weighting
• Better stopping conditions for generating goto points - should bring speed back to 2.7.17 levels, even though I'm not caching point dangers for the 'stopped' condition and doing a bunch more precise predictions with wall smoothing

2.7.20 APS: 89.21 Survival: 97.38 PL: 1 losses

• Revert to 2.7.17
• Choose new goto points every time I surf the second wave so that I get the correct second wave escape angles
  • Buggy: The second wave had it's weight set to 0, so this is effectively surfing 1st wave only, no other bugs. Nice comparison: [1]

2.7.19 APS: 90.04 Survival: 97.72 PL: 0 losses

• Remove the no-wave surfing, put in the 1-wave future waves

2.7.18 APS: 90 Survival: 97.84 PL: 0 losses

• Put back the no-wave surfing (now that the buffer extraction bugs are fixed)

2.7.17 APS: 90.15 Survival: 97.81 PL: 0 losses

• Increase number of bins back to what it was in 2.7.12 - whoops

2.7.16 APS: 90.08 Survival: 97.81 PL: 0 losses

• Comment out the future wave stuff, check again nothing is broken compared to 2.7.12

2.7.15 APS: 90.07 Survival: 97.79 PL: 0 losses

• Fix another 3 buffer extraction bugs with future waves:
  • accel still used the signed latVel, unlike the other code
  • time since decel didn't have the 0.4 margin of accel, unlike other code
  • distance-last-10 (which is actually made by summing recent latVels) wasn't being multiplied by direction, since it is stored as absolute value

2.7.14 APS: 90.12 Survival: 97.82 PL: 2 losses

• Fix bug in the buffer extraction when using future waves: I was forgetting to take the abs of latVel, so negative values would extract from the 0 bin.

2.7.13 APS: 90.09 Survival: 97.82 PL: 0 losses

• Bring back future wave surfing for the second wave

2.7.12 APS: 90.22 Survival: 97.87 PL: 0 losses

• Only round up if my energy is above 50

2.7.11 APS: 90.08 Survival: 97.8 PL: 0 losses

• If the shot would kill them, round up the x.x5 value to the next highest

2.7.10 APS: 90.22 Survival: 97.85 PL: 0 losses

• Fix my x.x5 exploit - solves my 10%-lower-than-Diamond score against FlowerBot

2.7.9 APS: 90.04 Survival: 97.77 PL: 0 losses

• Steeper bullet power descent slope

2.7.8 APS: 89.94 Survival: 98.07 PL: 0 losses

• Don't limit my bullet power to (predicted enemy power - 0.1) unless my hitrate is below 12.5%

2.7.7 APS: 86.84 Survival: 93.99 PL: 3 losses

• Keep firing higher powered bullets for longer

2.7.6 APS: 89.68 Survival: 98.19 PL: 0 losses

• Take my profile into account, as well as some enemy energy

2.7.5 APS: 89.41 Survival: 96.15 PL: 1 losses

• Cut down on the firepower with a steeper slope, and start shooting 0.1 at 15
  • Buggy - only copied enemy profile, didn't take mine into account

2.7.4 APS: 89.2 Survival: 95.98 PL: 1 losses

• Slightly more aggressive base power
• Copy the enemy's bullet power profile, and if it is less than mine shoot just below their level
  • This version tanked on survival quite badly... thus loosing points in APS
  • Buggy - only copied enemy profile, didn't take mine into account

2.7.3 APS: 89.92 Survival: 97.81 PL: 1 losses

• Use less memory in anti-PM buffers by only using 4 nested attributes instead of 6

2.7.2 APS: 89.96 Survival: 97.85 PL: 0 losses

• Put the second wave back where it was
• Turn the gun and robot to help the radar before there is a lock
• Don't ignore BulletHitBullet if they are the first piece of data (this was in to help against HawkOnFire... wow takes me back)

2.7.1 APS: 89.78 Survival: 97.73 PL: 0 losses

• Simulate start surfing the second wave 1 tick earlier

2.7.0 APS: 89.87 Survival: 97.8 PL: 0 losses

• Back to 2.5.6
• Fix post-enemy-death surfing so that it is on the right tick (even though painted incorrectly, since it works from run() )
• Change anti-PM buffers to all have deep segments - 6 active attributes with strong time dependencies

2.6.6 APS: 89.66 Survival: 97.76 PL: 0 losses

• Disable the Future Waves for the second wave, only use them when there are no other waves to surf.

2.6.5 APS: 89.63 Survival: 97.82 PL: 0 losses

• Weight danger more strongly with distance
• Weight 'Future Waves' 1/5 of regular waves
• Use a wider 'gaussian' for future waves to account for the uncertainty in the firing location

2.6.4 APS: 89.5 Survival: 97.79 PL: 0 losses

• Find bug in 2.6.3: wasn't surfing post-enemy-death waves. This would explain the 0.2% loss
• Re-enable the 60 main buffers disabled in 2.5.8 - it seems that they are fast enough not to make a difference.
• Make the 0-wave surfing branch at the point the enemy fires, as well as now, so similar computational complexity to surfing 2 waves

2.6.3 - APS: 0.2% below 2.5.8

• Back to 2.5.8, reapply specific changes and copy across framework, but comment out new framework usage

2.6.2 - buggy

• Shift imaginary wave back to where it was in 2.5.8

2.6.1 - buggy!

• Comment out actual Future Wave evaluation
• Increase distancing back to 650

2.6.0 - buggy!

• Add Predicted Wave Surfing - if 0 or 1 wave is present use precise prediction to figure out what they would see and fire and surf the relevant wave
• Fire imaginary waves 1 tick later
• Weight imaginary waves half of real waves
• Reduce preferred distance to 450

2.5.8 APS: 89.75 Survival: 97.78 PL: 0 losses

• See if I can speed up the stats component without loss of score by removing 60 out of my 100 main buffers, about half of my flattener, ABS and tick buffers, and using 71 instead of 171 bins
• Shift the second wave back to 2.5.6 position

2.5.7 APS: 89.8 Survival: 97.81 PL: 0 losses

• Start surfing the second wave 1 tick earlier in simulations
• Weight second wave slightly higher, switch weighting from quadratic to power

2.5.6 APS: 89.85 Survival: 97.8 PL: 0 losses

• Put the anti-mirror stuff back
• Add a bunch of buffers with the randomly chosen attributes weighted for simple targeters and PM guns

2.5.5 APS: 89.72 Survival: 97.73 PL: 0 losses

• Remove the anti-mirror attribute in the gun

2.5.4 APS: 89.83 Survival: 97.8 PL: 0 losses

• Fix the second wave surfing - all the prediction points had their time initialized relative to the first wave firetime instead of absolute time

2.5.3 APS: 88.49 Survival: 97.24 PL: 1 losses

• Fixed bug with order of execution in precise intersection prediction - bullets move before robots, not the other way around!

2.5.2 APS: 88.75 Survival: 97.3 PL: 0 losses

• Make the prediction wait one more tick before decelerating, like the physics do (but how it didn't work as well with the non-precise prediction)

2.5.1 APS: 88.73 Survival: 97.3 PL: 0 losses

• Fix the unequal-weightings bug mentioned in 2.5.0

2.5.0 APS: 88.84 Survival: 97.39 PL: 1 losses

• Precise intersection for surfing the first wave, still regular intersection on the second wave for speed reasons.
  • Whoops, this has a bug: it accidentally weights precise waves ~80x higher, essentially neglecting the second wave. I'm going to see where it stabilises at to see how much my second wave surfing helps...

2.4.14 APS: 89.63 Survival: 97.7 PL: 0 losses

• Shift only the second wave half a tick backward (as it actually should be, why no extra points?? reached limit of accuracy??)

2.4.13 APS: 89.64 Survival: 97.7 PL: 0 losses

• Back to 2.4.10 with just the FastTrig fix

2.4.12 APS: 89.35 Survival: 97.52 PL: 0 losses

• Fix bug with the static initialization of the FastTrig - no more skipped turns on start, hopefully!

2.4.11 - bug found, see 2.4.12

• Was my surfing half a tick off? Some mods to the surf mechanics.(Dangerous, I know, but some quick tests are fine with it...)

2.4.10 APS: 89.6 Survival: 97.49 PL: 0 losses

• Align the imaginary gunheat with the real gunheat - shouldn't have any effect but gives me warm and fuzzies =)
• Comment back in an 'early stop' for the precise prediction if I reach the destination before the wave hits - should run faster, so less skipped turns
• Fix a bug making the stay moving as long as possible, even if you're at the destination already not work sometimes

2.4.9 APS: 89.37 Survival: 97.34 PL: 1 losses

• Switch movement accel/decel over to new model (discovered it was one tick off from before, which is why I never got it to work.)
• Minor bugfixes in movement - negative distances caused by overshoots can play havoc with movement decisions
• Rather than stop as soon as possible, then resume, stay moving as long as possible and then stop.

2.4.8 APS: 89.55 Survival: 97.65 PL: 0 losses

• Collect new data using the weighted gun. Tune main gun against this new dataset.
• Add rolling to the main gun, with a nice power curve so it slows down over time. Speed is tuned genetically (like the rest of the attributes).

2.4.7 APS: 89.25 Survival: 97.63 PL: 0 losses

• Add a power curve to the rolling so it starts quick then slows down - again tuned genetically
• Tweak the bullet power
• Fix the painting for precise intersections - it was broken in 2.3.6

2.4.6 APS: 89.23 Survival: 97.26 PL: 1 losses

• Add a rolling segment to the antisurfer gun, genetically tune against Tomcat and Diamond
  • Had the interesting effect of also increasing my APS against the general rumble 0.25%... needs investigation.

2.4.5 APS: 88.99 Survival: 97.02 PL: 1 losses

• Some anti-Diamond tuning
  • Well... it seemed that worked... now to do some simultaneous anti-Tomcat 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: 9