DrussGT/Version History

From Robowiki
Jump to navigation Jump to search

3.1.6 APS: 92.04 Survival: 98.15 PL: 1 losses

  • Add back the timeSinceDirChange, but weighted low.
  • Do a bunch of cleanup, and fix all warnings given by latest ECJ

3.1.5 APS: 91.88 Survival: 98.15 PL: 0 losses

  • Fix bug reported by User:Rsalesc - keep old behaviour by switching to use time instead of timeSinceDirChange, the actual timeSinceDirChange can be added in future release.

3.1.4159 - No change in score

  • Try this one weird trick to prevent getting ThreadDeaths on Java 8 VMs

3.1.4 APS: 91.83 Survival: 98.25 PL: 1 losses

  • Keep move stats in VCS
  • Switch from javac to ECJ
  • A little cleanup of unused imports
  • Add a fast check to prevent precise prediction on second wave when it isn't necessary

3.1.3DC APS: 90.6 Survival: 98.04 PL: 1 losses

  • Like 3.1.3 but with the surfing switched to DC instead of VCS

3.1.3 APS: 91.1 Survival: 98.24 PL: 0 losses

  • Update 2017: APS: 91.28 Survival: 98.16 PL: 0 losses
  • Fix bullet-equality tests (use .equals() instead of == ). This fixes:
    • Bullet-hit-bullet events now correctly mark waves as not carrying bullets for the Virtual Gun
    • Bullet-hit-bullet events now correctly reverse bullet shadows
  • Add a random gun to the Virtual Gun - uses precise predicted MEA to cut down on targeting area, and the VG takes the probability of each shot into account given the MEA and hit width, rather than evaluating the randomly selected angle.

3.1.2 APS: 91.29 Survival: 98.22 PL: 0 losses

  • More bullet shield tuning - more ways to early-terminate bullet shielding when it isn't working

3.1.1 APS: 91.57 Survival: 98.33 PL: 0 losses

  • Some bullet shielding tuning - try to get away from walls at the beginning of the round

3.1.0 APS: 91.34 Survival: 98.25 PL: 0 losses

  • A major refactor of movement subclasses and goto precise predictor
    • Left out wall-hits from the predictor, those will be added back ASAP

3.0.0/3.0.1 APS: 91.29 Survival: 98.31 PL: 0 losses

  • Use my own KD-Tree (thanks to Rednaxela for his 2nd gen tree up till now)

2.9.3 APS: 91.38 Survival: 98.33 PL: 0 losses

  • Use bitwise operations for the logic of some performance critical applications

2.9.2 APS: 91.48 Survival: 98.29 PL: 0 losses

  • Change max bullet damage received via bullet shielding to 98% score (~47 bullet damage)
  • Allow all bullet hits to count towards this, not just unrecognised ones

2.9.1: APS: 91.15 Survival: 98.07 PL: 0 losses

  • A bunch of new FastTrig methods, completely remove all tables, and the new ones are more accurate too!
  • Don't attempt to bullet shield if they don't shoot and their energy isn't well below mine

2.9.0 APS: 91.46 Survival: 98.1 PL: 0 losses

  • Add some bullet shielding from EnergyDome - stops shielding if it calculates it will get less than 99% of score through survival points (let's start conservative, OK? =D )
    • Testing out the new rumblestats!

2.8.16 APS: 90.74 Survival: 98.21 PL: 0 losses

  • Another attempt (after a long time) of pulling the movement out of the main class. This is just to test against bugs, hopefully no new 'features' were added ;-)

2.8.15 APS: 90.68 Survival: 98.17 PL: 0 losses

  • Update the internal counter at the start of every on* method, instead of in the run method. This makes painting simpler to get right.
  • Fix sometimes-off-by-1 in bullet shadows - I thought I had this right before, but perhaps this time?
  • Clean up the bullet shadow nested-if-else into two simple if-else statements - no functional change, although the new code will probably optimize in the JIT easier.
  • Double checked all my precise shadow intersection code - my bad results at bullet shielding attempts using the same code had me worried

2.8.14 APS: 90.57 Survival: 98.12 PL: 0 losses

  • Back to 2.8.9
  • Fix BulletHitBullet passthrough which I fixed in 2.8.10
  • Use the new painting method from 2.8.13

2.8.13 APS: 90.52 Survival: 98.11 PL: 0 losses

  • 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: 90.47 Survival: 98.04 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: 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
  • 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!
Retrieved from "http://robowiki.net/w/index.php?title=DrussGT/Version_History&oldid=54969"