Robo Home | SilverSurfer | Changes | Preferences | AllPages

2004-11-29: version 2.66
Based v2.65
Heavy segmentation: DISTS = 3; VELS = 9; ACCS = 3; HEADS = 4; WALLS = 3;
EnemyWave hitsRA splitted in 3 distance segments (0-200,200-400,400-).
Danger graph for WeakGun only with Hits.(no allHits)
No waves readyToGo? avaliation for WeakGuns.

2004-11-28: version 2.65
Based v2.64
Shortening escape envelope for HOTs if and only if bullet power > 1.7.
back with old Multi-Wave weightening:(1 - ((1D / 55D) * Math.pow(arrive, 2)));
removed no-wall-smoothing for WeakGuns (2.64).

2004-11-28: version 2.64
Based v2.63
Removed the historyHits.
Multi-Wave weightening:(1 - ((1D / 20D) * Math.pow(arrive, 2)));, was:(1 - ((1D / 55D) * Math.pow(arrive, 2)));
Using 9 velocity segments, instead of 5.
Tweaked WeakGun movement to a behaviour very similar to anti-HOT moving (without shortening escape envelope).

2004-11-27: version 2.63
Based v2.62
Removed "rammerKiller" of 2.62
hitsAvg returns 0.0 if hitsCount < 10.
Added a historyHits to danger graphing: allHits+Hits+0.5*visits+0.25*hitsHistory (hitsAvg >= 0.07)

2004-11-25: version 2.62
Based v2.61
if rammer and distance < 300, firePwr=3.0
(Strange diff for such a small stuff...)

2004-11-24: version 2.61
Based v2.60
hits depth set from 3 to 1. allHits depth set from 3 to 1. visits depth set from 20 to 10. selecting danger graph (3 types) based in hits avg:
.allHits+Hits (hitsAvg < 0.07)
.allHits+Hits+0.5*visits (hitsAvg >= 0.07)

2004-11-24: version 2.60
Based v2.59
back to holding fire at pwr 8.
hits depth set from 3 to 1.

2004-11-23: version 2.59
Based v2.53.33
Holding fire at pwr 17.

2004-11-22: version 2.58
Based v2.53.33
Back to 2 dangers graphs (Hot & non-Hot).

2004-11-21: version 2.57
Based v2.53.33
Back to 2.53.33. selecting danger graph (3 types) based in hits avg.

2004-11-16: version 2.56
Based v2.55
Attempt to an auto-select of danger graph.

2004-11-14: version 2.55
Based v2.54
Tired of those boring little tweaks, and of this score hunting, itīs time for a fun-time version!
I call this an "Ashtray" version ;) (not for me, is suposed...). Probably it would reflect also somewhere, but this test is also to find if.
Also "corrected and optimized" firePower.

2004-11-13: version 2.54
Based v2.53.33
recalled down to version 2.53.33, something went wrong after it, or it was only luck... anyway, back with it.
Better ramming detection, bullet power explicitly 3.0 against rammers. Particularly better against "oportunity rammers", like Cigaret.

2004-11-11: version 2.53.39
Based v2.53.38
Back with bonus for last hits:

}else if(hits>0){
   rate /= 1D+(1D - Math.pow((double)hits/(double)MAX_HITS,2 ));
Back with old latest samples bonus formula, now:
rate /= 1D + ((difAge < AGING_LIFE)?1D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);
rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),0.5)):0);

2004-11-10: version 2.53.38
Based v2.53.36
distance-to-corner stronger(1 factor) at corners, weaker(null, factor 0) at middle field.

double cdiff = REFERENCE.distanceCorner - this.distanceCorner;
double minCornerDist = Math.min(REFERENCE.distanceCorner,this.distanceCorner);
double x = minCornerDist/(AxeBot .getIt().getFieldDiagonal()/4D); 
double cornerWeight = 1-(x*x); // 1-((x/250)^2)
cornerWeight = (cornerWeight<0)?0:cornerWeight;
penalty += (rate * (cdiff * cdiff / 20000.00) * cornerWeight);
PatternSample? rating: time-since-deccelerating , distance , heading, distance-to-wall & distance-to-corner weightened.

2004-11-09: version 2.53.36
Based v2.53.35
Back to distance-to-corner (old). PatternSample? rating: time-since-deccelerating , distance , heading, distance-to-wall & distance-to-corner.

2004-11-09: version 2.53.35
Based v2.53.34
Changed the mirror-distance scheme for distance-to-center (PEZ again). PatternSample? rating: time-since-deccelerating , distance , heading, distance-to-wall & distance-to-center.

2004-11-08: version 2.53.34
Based v2.53.33
Changed distance-to-corner for a mirror-distance scheme (distance to the closest "mirrored" reference point). PatternSample? rating: time-since-deccelerating , distance , heading, distance-to-wall & mirror-distance.

2004-11-07: version 2.53.33
Based v2.53.32
Added distance-to-corner (old). PatternSample? rating: time-since-deccelerating , distance , heading, distance-to-wall & distance-to-corner.
Result:2063.94 ** BEST SCORE EVER **

2004-11-07: version 2.53.32
Based v2.53.31
back to AGING_LIFE=100; in:

rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),0.5)):0);

2004-11-05: version 2.53.31
Based v2.53.30
At PatternSample?.rate():

//PEZ dicovered this "bug"(?)...
//I was using rate += (rate * ... without using a bonus
//The rate calculation was not what i expected,
//not sure if it would make any difference, but 
//at least gives me a different rate...
//Dunno however if it will make any dif, or even
//break it, but iīm curious...
//So, all Blame or Shame to PEZ...
double bonus = 0;
bonus += (rate * (tsdeaccdiff * tsdeaccdiff / 200.00));
bonus += (rate * (ddiff * ddiff / 20000.00));
bonus += (rate * (hdiff * hdiff / 500.00));
bonus += (rate * (wdiff * wdiff / 20000.00));
rate += bonus;

2004-11-05: version 2.53.30
Based v2.53.28
an inverse curve comparing to previous. AGING_LIFE=200:

rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),<b>0.5</b>)):0);

2004-11-04: version 2.53.29
Based v2.53.28
AGING_LIFE=200; was 100. in:

rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);

2004-11-04: version 2.53.28
Based v2.53.27
Removed the bonus to the hitted in samples.
Removed the bonus to the last-hitted in samples.
Stronger bonus for newer samples:

rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);

2004-11-03: version 2.53.27
Based v2.53.25
Cleaned old code (some) Gun:
Adding a bonus to the hitted samples:

rate /= (hit)?2D:1D;
Result:2047.58 - buggy?

2004-11-03: version 2.53.25
Based v2.53.23
Back to old vector search in PM:
{1, 2, 3, 4, 5, 6, 7, 10, 15, 20, 30, 40};
Adding a bonus to the 10 last hit samples:

   rate /= 1D+(1D - Math.pow((double)hits/(double)MAX_HITS,2 ));

2004-11-02: version 2.53.23
Based v2.53.22
Trying a more "wide" vector search in PM:
now:{1, 2, 3, 4, 5, 7, 10, 15, 20, 30, 40, 50};

2004-11-01: version 2.53.22
Based v2.53.21
Trying a more "fast" vector atualization in PM:
now:{1, 2, 3, 4, 5, 6, 7, 10, 15, 20, 25, 30};
before:{1, 2, 3, 4, 5, 6, 7, 10, 15, 20, 30, 40};

2004-11-01: version 2.53.21
Based v2.53.20
Back with the old shooting blocking scheme... Added a attempt to faster-learning gun, rating (AGING_LIFE=100):

rate /= 1D + ((difAge < AGING_LIFE)?(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);

2004-11-01: version 2.53.20
Based v2.53.19
Trade the shooting block for bullet power restriction:

if ((lifeAfter <= 8) && (lifeAfter < hisLife) && (target.getDistance() > 150)) {
   pwr= 0.1;

2004-10-30: version 2.53.19
Based v2.53.18
Fixed(?) a positional bug(?) at gun. if i calculate 1 tick earlier, the center of firing should be the next(t+1), right? Extrapolating shooting pos at getFuturePos?().

2004-10-29: version 2.53.18
Based v2.53.17
MultipleChoice grain set back to 20 pixs.
MultipleChoice back to smoothed 1/(n^2).

2004-10-29: version 2.53.17
Based v2.53.16
Added a simple distance control system: "retreats" if (3*me.getLife() < 2*enemy.getLife())

2004-10-29: version 2.53.16
Based v2.53.15
Initial value for rating back to 0.
MultipleChoice grain set from 20 pixs to 15.
MultipleChoice unsmoothed (if PEZ says that neither him or Jam use smoothinī in their GF guns, whom am i to disagree? - Credits, credits...).

2004-10-27: version 2.53.15
Based v2.53.14
PatternSample? rating: time-since-deccelerating , distance , heading & the distance-to-wall scheme.
Initial value for rating set from 0 to 10.

2004-10-26: version 2.53.14
Based v2.53.13
Back to old-fashioned vector normalization. PatternSample? rating: time-since-deccelerating , distance , heading , the new distance-to-wall scheme & distance-to-corner.

2004-10-26: version 2.53.13
Based v2.53.12
Crazy experiment vith the vectors orientation (normalizing not now in 0dgs, but in angle_to_me).

2004-10-25: version 2.53.12
Based v2.53.11
Gun: PatternSample? rating: time-since-deccelerating , distance , heading & a new distance-to-wall scheme.

2004-10-25: version 2.53.11
Based v2.53.10
Gun: PatternSample? rating: time-since-deccelerating , distance & heading.

2004-10-24: version 2.53.10
Based v2.53.09
Gun: PatternSample? rating: time-since-deccelerating , distance & distance-to-wall.

2004-10-23: version 2.53.09
Based v2.53.08
Gun: PatternSample? rating: time-since-deccelerating & distance .

2004-10-23: version 2.53.08
Based v2.53.07
Gun: Trying PEZīs sugestion of time-sinvce-vel-changed (credits to him)... included time-since-vel-changed in PatternSample? rating (took out time-since-inverted, time-since-accelerating, time-since-deccelerating).

2004-10-22: version 2.53.07
Based v2.53.06
Gun: included time-since-inverted in PatternSample? rating.

2004-10-21: version 2.53.06
Based v2.53.05
Gun: re-include the time-since-accelerating in PatternSample? rating.

2004-10-20: version 2.53.05
Based v2.53.04
Gun: re-include the time-since-deccelerating in PatternSample? rating.

2004-10-19: version 2.53.04
Based v2.53.03
Gun: Trying a more "dense" vector search in PM:
now:{1, 2, 3, 4, 5,6,7, 10, 15, 20, 30, 40};
before:{1, 2, 3, 5, 10, 20, 40};

2004-10-19: version 2.53.03
Based v2.53.02
Gun: Trying:

double maxPwr = (BulletTracker.getHitAvg(target.getDistance())>0.35 )?3.0:1.9;
bulletPower = (distance<150)?3.0:maxPwr;

2004-10-19: version 2.53.02
Based v2.53.01
Gun: I just canīt resist to make things more complex, donīt I? Now trying:

double maxPwr = (BulletTracker.getHitAvg(target.getDistance())>0.25 )?3.0:1.9;
bulletPower = (distance<150)?3.0:maxPwr;

2004-10-18: version 2.53.01
Based v2.53
Gun: Trying PEZ (credits to him, obvious) sugestion for bullet power control: bulletPower = (distance<150)?3.0:1.9;.
Result:2039.78 (Thanks, PEZ!)

2004-10-17: version 2.53
Based v2.52
Gun: Total re-construction. Starting with vectorial PM + MultipleChoice(100 samps).

2004-10-17: version 2.52
Based v2.51
Gun: Added my last vector movement to rating.

2004-10-16: version 2.51
Based v2.50
Gun: MultipleChoice with 100 samples (50, before). Rating incremental (rated & aged).

2004-10-14: version 2.50
Based v2.48
Faster learning experiment.

2004-10-13: version 2.49
Based v2.48
Single Wave Surfing.

2004-10-12: version 2.48
Based v2.47
removed rating PatternSample? by fireTime.
tweaked all-waves rating formula.WaveFired? generating recalculation of Course - only if arrivalDelta <= 7.

2004-10-11: version 2.47
Based v2.46.4
Gunnery test: including fireTime as info for PatternSample?, rating by it also.

2004-10-11: version 2.46.4
Based v2.46.3
WaveFired? generating recalculation of Course - only if arrivalDelta <= 10.

2004-10-11: version 2.46.3
Based v2.46.2
Took out the "waves danger zoning" tweaking for HOA (back to same as 2.46.1).
WaveFired? generating recalculation of Course.

2004-10-10: version 2.46.2
Based v2.46.1
Lil "waves danger zoning" tweaking for HOA (same as 2.46). Protection against SecurityExceptionBug, a pull-the-pin-and-swallow-the-granade strategy, idea inspirated in Jonathanīs similar idea (credits to him). Special saving (more precise & smaller, saving only allHits) for HOTs.

2004-10-10: version 2.46.1
Based v2.46
Back with random +-0.5 to chosen gf. Waves danger zoning tweaked.

2004-10-09: version 2.42RLD
v2.42 reloaded.
Version pos-BigCrash?.

2004-10-08: version 2.46
Based v2.42.
Version pos-BigCrash?. LOTS of new stuff...

2004-09-22: version 2.42
Keeping 2.35 cfg.
New "Ramming Detection" algo: if((attackAngle < 15) && (distance < 450) && (Math.abs(vel)==8){ ramming=true; }else{ ramming=false; }
Initializing direction to avoid walls at begin of rounds.
Simplified chooseFuture() method
Fixed some more nasty & stupid bugs (discovered with WaveSurfingChallenge):
AxeVector? class giving crazy angles in setModule(0) cases. Protected now, if setModule(0), module==0.00001.
No anti-mirror if enemy is HOT (also avg value for tetection changed from 30 to 20).

2004-09-18: version 2.41
Keeping 2.35 cfg.
Fixed nasty & stupid bug #1 (discovered with WaveSurfingChallenge):
My "Ramming Detection" algo was: if((attackAngle < 25) && (distance < 450)){ ramming = true; }else...
This lead into situations that SS was anti-ramming when it souldnīt (particularly at WaveSurfingChallenge, because of the stopped opponent, SS sometimes was diving into situations that the conditions for detecting rammers where attended).
New "Ramming Detection" algo (condensed): if((attackAngle < 25) && (distance < 450) && (Math.abs(vel)){ ramming=(rammCount++ > 10)? true?false; }else...

2004-07-12: version 2.35.4
Keeping 2.35 cfg. Movement route prefered angle back to 90dgs. Added time-since-v0 to rating samples at PM gun.

2004-07-12: version 2.35.3
Keeping 2.35 cfg. Back with AntiMirrorSystem . Movement route prefered angle set to 110dgs.

2004-07-11: version 2.35.1
Keeping 2.35 cfg. Took out AntiMirrorSystem. "aware 100% scoring" only in the last 2 rounds.

2004-07-11: version 2.35
Back to 2.33.3 cfg.

2004-07-04: version 2.40
Keeping 2.33.3 cfg . Great change in routing movement, using the BotSimulator? to choose the route, in order to be more precise and maximize escape envelope. Expected to be slow and somewhat buggy yet...

2004-06-27: version 2.34.2
Keeping 2.33.3 cfg . Trying a faster learning segmentation.

2004-06-20: version
Keeping 2.33.3 cfg . Fixing bug in

2004-06-19: version
Keeping 2.33.3 cfg . Removed wall segment. HO detection function. HOA particularization, if HeadOn? enemy, movement intent to be more precise and shorter escape envelope.
Result:2031.14 ** BUGGY **

2004-06-19: version
Keeping 2.33.3 cfg (think itīs broken, but itīs only for comparisson). Added a single simple distance-to-wall segment for moving (0-100,100-).

2004-06-18: version 2.33.3
Keeping 2.33.1 cfg. Back to SingleWaveSurfing?. Trying a "real" bot simulator, that gives(i think...) me accurate navigation even when smoothing hard.

2004-06-15: version 2.33.2
Keeping 2.33.1 cfg. Trying AllWavesSurfing?.

2004-06-15: version 2.33.1
Keeping 2.33 cfg. Correction of bug in 2.33v: "attempt to get a more wide escapvelovelope". using bot dim 36 to calculate consecutives. Only fast-learning see-poe-populated with 2 shots.Artificial wave shot when opp. dies - attempt to avoid "last breath" bullets. Moving too close try to escape if he is closer than u to the wall.

2004-06-13: version 2.33
Keeping 2.31 cfg. Attempt to "get more wide" the escape envelope by choosing a newwave sooner if vel=0. using bot dim 50 to calculate consecutives. Only fast-learning seg pre-populated with 2 shots.
Result:2029.29 ** BUGGY **

2004-06-13: version 2.32
Keeping 2.31 cfg. HOA effort again, now also segmented populated, added also a "aware 100% scoring" RRServer ignores 0 points results (thnx PEZ again). using bot dim 50 to calculate consecutives.

2004-06-12: version 2.31
Keeping 2.27 cfg. HOA effort (thanks PEZ words), in the process detected and fixed(?) a major bug in movement (pray that i had not introduced new ones). Pre-popolulating gf0 with 2 shots.
Result:2035.60 ** Best score ever **

2004-06-08: version 2.30
Keeping 2.27 cfg. Radical experiment in MultipleChoice gunīs feature. Added also attackAngle to PatternSample? rating.

2004-06-08: version 2.27.5
Keeping 2.27 cfg. Anti-ramm tweak again (hopefully without bug of 2.27.4.* series).

2004-06-08: version
Keeping 2.27 cfg. Anti-ramm re-re-tweaking, actually took off the anti-ramm tweaking, to confirm my suspicion that some bug was introduced after 2.27.3 (there is something very rotten in the state of denmark).

2004-06-08: version
Keeping 2.27 cfg. Anti-ramm re-tweaking.

2004-06-07: version 2.27.4
Keeping 2.27 cfg. Anti-ramm tweaking.

2004-06-07: version 2.27.3
Keeping 2.27 cfg. Gun tweaking (added time_since_accelerating & time_since_deccelerating to rating function).

2004-05-30: version 2.29
Keeping 2.27 cfg. Another (hopeless?) experiment, playing around with start moving time.
Result:+74.55(2002.69) *trashy... recalled

2004-05-25: version 2.28
Keeping 2.27 cfg. Playing around with MaxVelocity?.
Result:+77.71(2005.51) *stronger against PMs, but much weaker against the others....

2004-05-24: version 2.27
2.21 back, i must be missing something... faster reading data; compatible with JRE 1.3.1.

2004-05-24: version 2.26
Keeping 2.21 cfg. back to old firePwr; Lots of gf measuring bug correction (hope didnīt trashed anything); Gun firing bug corrected (starting game); Forcing fire if rammed;

2004-05-23: version 2.21.3
Keeping 2.21 cfg. keeping FirePwr? increased; back to RollingAverages?; back to consecutives = 36; faster reading data; compatible with JRE 1.3.1.

2004-05-22: version 2.21.2
Keeping 2.21 cfg. FirePwr? increased; fastAverage n =4; consecutives set to 51 (instead of 36).

2004-05-20: version 2.21.1
Keeping 2.21 cfg. A variant of 2.21, trying a alternative formula for RollingAverage (PEZ sugestion) for more fast adaptation.

2004-05-19: version 2.25
Keeping 2.21 cfg. More bugs: Route orientation when vectorīs module == 0; close-range with wave null now go 120 degrees; other minor bugs.

2004-05-18: version 2.23
** BUGGY ** Keeping 2.21 cfg. Two bugs (at least that i found) from 2.22: Anti-Mirror buggy, bulletInterception adding -12 (break) - Corrected both.
Result: * RECALLED

2004-05-17: version 2.22
** BUGGY ** Keeping 2.21 cfg. Lots of bugs/malfunctions corrections: revised getGF() methods, some buggy; wallSmoothing function improved & optimized .Cleaned some code.

2004-05-12: version 2.21
Manteining 2.20.1 cfg. Navigation more precise.

2004-05-11: version 2.20.1
Manteining 2.17.2 cfg. Smoothing factor set to 1.
Result:+91.09(2017.56) *First version ever to reach 2nd in general 1X1

2004-05-10: version 2.20
Manteining 2.17.2 cfg. Smoothing factor set to 2.

2004-05-07: version 2.17.5
Manteining 2.17.2 cfg. Variant of 2.17 rating form ((1*segmented_segment) + (1*unsegmented_segment)+(1*flattener)).

2004-05-06: version 2.17.4
Manteining 2.17.2 cfg. Variant of 2.17 rating form ((1*segmented_segment) + (1*unsegmented_segment)+(0.5*flattener)).

2004-05-05: version 2.19
Manteining 2.17.2 cfg. Trying an approach based on PEZīs idea of "mirroring" the edges for edge protection under smoothing.

2004-05-03: version 2.18.1
2.18 variant. Lightweighted cannon 10000 samples max.

2004-05-03: version 2.17.3
as PEZ requested: Variant of 2.17 rating form ((0*segmented_segment) + (1*unsegmented_segment)).

2004-05-03: version 2.18
Manteining 2.17.2 cfg. Lightweighted cannon 20000 samples => 5000 samples max.

2004-05-02: version 2.17.2
Variant of 2.17 rating form ((1*segmented_segment) + (1*unsegmented_segment)).

2004-05-02: version 2.17.1
Variant of 2.17 rating form ((0.5*segmented_segment) + (1*unsegmented_segment)).

2004-05-02: version 2.17.
Removed bullet power segments (actually set to 1 seg). Trying rating form %2mentmented_segment + (0.5*unsegmented_segment)) instead of (segmented_segment + unsegmented_segment+(0.1*visits)).

2004-05-02: version 2.16.
Adding bullet power segment (3:0-1;1-2;2-3).

2004-05-02: version 2.15.
5 absolute velocities instead of 3 (now:0;1-2;3-4;5-6;7-8).

2004-05-01: version 2.14.
Trying a FastAdaptation? solution, that is a merge of ABCīs across-segments smoothing solution and PEZīs "unsegmented segment" approach (credits for them both).
2.07 config was not so "the same" in 2.12 & 2.13, corrected the min dist. parameter (100 => 150).
Corrected a bug in the loading, was using readByte that could give me negative values for things that was to be positive, replaced with readUnsignedByte?.
Result:+82.82 (2012.08)

2004-04-28: version 2.13.
2.07 config. Saving data but no pre-saved.

2004-04-27: version 2.12.
Back to 2.07 config. Trying a version without saving data (Letīs see if ABCīs observation works here).

2004-04-25: version 2.11.
Took out DinamicDistancing?. Trying an experimental wave weightening (no surprises if it degrade the rating).
obs: due to size restrictions, this version will not include source.source in 2.10r> Result:+67.70

2004-04-24: version 2.09.
Trying for the first time dinamic distancing, maybe buggy...
obs: due to size restrictions, this version will not include source.source in 2.08

2004-04-23: version 2.07.
Seems that the "tweaked" anti-ramm pull me down somewhat like 8 pts. Donīt really know the problem, just giving a blind shot.
obs: due to size restrictions, this version will not include source.source in 2.06

2004-04-22: version 2.05.
removed the "Lightened" gun back to slow and heavy (perhaps in the future, iīll work more on it).
obs: due to size restrictions, this version will not include source.source in 2.04

2004-04-21: version 2.03.
Tweaked the anti-ram. "Lightened" the gun (10000 samples, grain 30, 10 samps in multiple choice).
obs: due to size restrictions, this version will not include source.source in 2.02

2004-04-19: version 2.01.
Tweaked a little the weight for hits rollingAvgs.
obs: due to size restrictions, this version will not include source.source in 2.00

2004-04-16: version 1.22.
AM data: Introduced velocity and acceleration segmentation. segmentation now: distance - 3, acc - 3, vel - 3.
obs: due to size restrictions, this version will not include source.source in 1.21
Result:+70.06 (first version breaking the 2K barrier)

2004-04-13: version 1.20.
Bug in the wave identification method.
obs: due to size restrictions, this version will not include source.source in 1.19

2004-04-11: version 1.18.
More realistic (strongest) consecutive gf setting to compensate bot size. Improved bullet detection (bulletHitBullet?).Included a lot of pre saved data.
obs: due to size restrictions, this version will not include source.source in 1.17

2004-04-09: version 1.16.
More bug corrections. Included consecutive gf setting to compensate bot size.
obs: due to size restrictions, this version will not include source.source in 1.15
Result:+47.18 !!

2004-04-06: version 1.14.
A lot of bug corrections.

2004-04-03: version 1.13.
Movement based on triangle, wall smooth. Bug correction on rating (now counting hits correctly). Tweaked rating a little
obs: due to size restrictions, this version will not include source.source in 1.12

2004-03-27: version 1.11.
Trying a move-to rating inspired on Jamoughaīs gf rating.

2004-03-24: version 1.10.
More deep inside the restrictions age. Tweaked with PEZīs TGB.

2004-03-22: version 1.09.
Roots, man, roots. Attempt to at least get same score as Okami.
obs: due to size restrictions, this version will not include source.

2004-03-16: version 1.07.
Complete restructuration of AM AI (again!). Measuring GF by angle ok.

2004-03-16: version 1.06.
Complete restructuration of AM AI. New measuring GF by angle.

2004-03-14: version 1.05.
Fixed bug from last version in AM AI. Movement angle & distancing tweak. Mainteining 1.02 alteration.

2004-03-14: version 1.03.
Fixed bug in last visiteds filter. First priority set to last hit GF. Mainteining 1.02 alteration.
Result: -18.60

2004-03-13: version 1.02.
using Math.asin(MAX_VEL/bulletVel) instead of MAX_VEL/bulletVel for calculation of the max escape angle.

2004-03-11: version 1.01.
Trying pre-saved data (.gfs).
obs: due to size restrictions, this version will not include source.

2004-03-09: version 1.00.
Bullet Power increased a lot.
Result: -5.82pts.

Are you still doing AntiMirrorTargeting? If so it doesn't seem to work very well. Your PBI's against mirrorers should be much better then, shouldn't it? -- PEZ

Yep. 2.23 (2.25 too) should have fixed this bug. The problem is that i cleaned the AntiMirrorGun, and leaved the AntiMirrorMoving?... So, if it detected mirror moving, he starts the AntiMirrorMoving?, but without the gun, the result is a really bad moving :). Thanks for noticing... -- Axe

Hey! I never actually suggested you should adapt faster. Your rolling seemed to be working as far as I can judge. =) However, better than to adapt faster with rolling averages I think it is if you always remember the very last hit you got and weight that in together with your unsegmented and segmented visit count stats. But lets see where the current experiment gets you first. I'm curious. -- PEZ

Itīs very much like the formula we were dicussing:

public static double fastAverage(double n, double oldVal, boolean mark){
    return (mark)?1D:(oldVal*(1D-(1D/n)));
Iīm using n=3, letīs see how this behave... Think that it should be more fast than Paulīs RA (at least it should rate allways the last hit higher). -- Axe

Version 2.26 trashed again... As i said to PEZ, just give me some time, iīll be the best trasher ever! Arghh! -- Axe

What do you think about the 2.28 experiment with maxVelocities? It looks like you might have become a little less vulnerable to PM guns. But you have also lost some of the edge against some GF guns, haven't you? -- PEZ

I don't really know by now, i'll need to excel-it to be sure... But i know for sure that the overall score ain't good... But if your analisis says that, surelly is (my intention surelly was to avoid better PMs, but also to maintain the performance against GFs). -- Axe

My analysis was based on a 10 second glance on an uncomplete details sheet. Don't base any descisions on that! -- PEZ

Man, u r one of the best analisersers that i had eveer seen... -- Axe

Hey! You're supposed to be taking a break! -- PEZ

Axe, could it be that there is a bug in your latest version? It's first match (against Moebius) on my client is already taking more than 10 minutes! Are there others observing this problem? Or is it just me.... --Vic

@PEZ or Albert: I had already asked this, but had no answer: Can't the RR Client batch include that "-Dsun.io.useCanonCaches=false" option? At least it would prevent new clients to freezing bots... (more specifically my bots :). Obviously disconsider this if the batch have already that option... :) -- Axe

This time there may really be something wrong. My client could not download your new version. ("could not find the file specified"). The repository is up, so that can't be the problem.. --Vic

Not too strange. The jar uploaded to the repository has the wrong version number. -- PEZ

Achh... Uploaded 2.17.5, not 2.27.5 Sorry for that, iīm taking it out from battle (no fair, since i use saving data...) -- Axe

Looks like SS 2.31 has passed Shadow in the rankings. Way to go! -- PEZ

He... I too have added an attempt to avoid getting "last breath" kisses in CassiusClay. I added it in a really cheap way. Now CC does some interesting VictoryDances that I didn't intend at all. =) -- PEZ

Can you tell us some more on that "real" bot simulator? -- PEZ

Good to see you taking HOA seriously. What I tried with the low 1.8 CC's was this:

    double danger(Point2D destination) {
	int index = visitingIndex(destination);
	double smoothed = 0;
	if (isLowHitRate()) {
	    smoothed = 100.0 / (Math.abs(index - mostVisitedIndex) + 1.0);
	else {
	    for (int i = 0; i < FACTORS; i++) {

		smoothed += (visits[i] + hitsTimer[i] + hitsVelocity[i] + hitsWall[i] + fastHits[i]) / Math.pow((double)(Math.abs(index - i) + 1.0), 0.5);
	return smoothed / Math.pow(travelTime(distance(0)), 0.5);
That is try to stay as far away from the most dangerous GF as possible against weak guns. Seems to work, but I had other problems with my surfing that I have decided to take care of first before I go for HOA particularity.

-- PEZ

Taking care of your surfing is HOA too :)... -- Axe

Indeed! But it looks a bit like your latest HOA efforts have weakened your bot against the stronger ones, doesn't it? -- PEZ

Someone please define "HOA". I am not even sure if I need this too or not =^> -- jim

HeadOnAvoidance?, we all need it. =) -- PEZ

Ah! Thanks. Yes we all need it. I have yet to add any special code to look for this or +1 targeting but I will be soon. Think it is possible to get to 2K on movement alone? DH's gun is mostly the gun in BlackPearl and not really all that highly rated on the TargetingChallenge. I need to consider what to work on next. -- jim

Yes, I think you can reach 2K with the current gun. Though it probably does have some catching up to do on the top guns. To get the answer on where a top gun would take you, just plug Bee in a test version. To get a measure on your gun, join the RRGunChallenge. Your HOA looks pretty OK btw. Special code for it can surely wait. Otherwise you'll risk hiding the room for improvement in your surfing. And, I would still not worry about the cx.* bots, even if you seem to have problems with Spark. Push your surfing a few more steps and then later you concentrating on your gun will take care of the rest. -- PEZ

What does POD stand for? --David Alves

Plenty Of Data (preloaded). -- PEZ

"a pull-the-pin-and-swallow-the-granade strategy, idea inspirated in Jonathanīs similar idea (credits to him)."

What do you mean? Or did I already forget it? :-) -- Jonathan

At ImperfectPerfection: "... and then the losing bot does this:

It really works. -- Jonathan". That gave the idea... :) -- Axe

Probably something else the SecurityManager? doesn't like? (because System.out only did for me a while ago, see ImperfectPerfection) -- Jonathan

That feature is discussed at SecurityExceptionBug, take a look... -- Axe

OK, have read it. -- Jonathan

version 2.46.4 was buggy... sorry for that -- Axe

Hey, mister complexity. Don't fool yourself into thinking you can trick the damage / escape_angle ratio. So what if your hit rate is above 25%? That's measured with what bullet power? And don't you think you'll get an even higher hit rate if increase the bullet speed some? Better write that /WaveSuffering page. =) It'll help you see what complexity can be removed from your surfing too. -- PEZ

I think that helps against some simple bots, actually I do the same thing as Axe but for 35% hit ratio or was it 40%. Easy enough to remove and test with though so maybe I should. Additionally I use bullet power 1.1 for extreme ranges. But other than that PEZ has since a long time ago convinced me of the 3/1.9 strategy. --Pulsar

Maybe looking at the rating of .02 can help people figure if it's worth introducing complexity here or not. Even if it's just a minimum of complexity. If it doesn't pay, why carry it around? Complexity grows like a cancer. I think any way you cut it, your bot is always pretty clueless on what its hit rate really is on a given distance. Too much random noice and stuff there. Better make sure the enemy get's a small escape envelope while damaging it good. -- PEZ

Hehe! I really knew that you was going to say these words, PEZ... But i just couldn't resist to that... Explaining it better:

private static void updateStats(boolean hit, double dist){
   int h = (hit)?1:0;
   int i = getDistIndex(dist);
   hitsRA[i] = RoboMath.rollingAverage((bullCount[i]<20)?bullCount[i]:20,hitsRA[i],h);
private static int getDistIndex(double dist){
   return (dist<200)?0:(dist<300)?1:(dist<400)?2:(dist<500)?3:(dist<600)?4:5;
25% was because of: a 3.0 pw bullet make 16 damage, and if you are hitting 1/4 (25%), you are spending 12 energy (3.0 * 4), while gaining 16... a profit of 4.
I was thinking about 35%, that probably will assure me that it is a real easy target, and so, it's scape envelope wont make any diff... Anyway... That maximize damage/escape_angle theory (The only problem with your theory is it's name - or the absence of a name) seems to be pretty strong. But you know how stubborn i can be. I really need to see things with my own eyes. -- Axe

I can fully understand Axe there, its the same with me. I already have some ideas for trying to adapt bullet powers during a battle. Thats additional complexity with probably no benefit at all, but i'll try it anyway :-) --Mue

I can understand both of you in this. And it's nice to see you go fight these windmills rather than working with things that could improve your bots. =) -- PEZ

Fighting windmills is important! :) Anyway, maybe it's time I tested that famous bp=1.9 solution in Shadow too, I haven't changed my bullet power function in years... -- ABC

And what's your current function like? -- PEZ

A big mess, full of (mostly melee) special cases. The 1on1 part could probably be reduced to:

bp = dist < 200 ? 3 : (900 * 900 - dist * dist) / (900 * 900 - 200 * 200) * 3;

-- ABC

About the windmills... I have a nice picture of Dom Quixote at my home office, it's a kind of inspiration for me...
@ABC: You really must give a try on that 1.9, your bullet power function looks a lot like my old function (but my was a lil bit more complex, Mr.Complexity is a good name for me...): pwr= (Math.pow((life>65)?400:(life>30)?300:200, 1.5) * 3) / Math.pow(dist, 1.5);
SS gain 10 pts with the new PEZ's bullet power func. -- Axe

New? =) -- PEZ

You're definately going to gain points by using 1.9 always above 150 ABC. Here's what I get from Excel with your current function:

200	250	300	350	400	450	500	550	600	650	700	750
3.0	2.9	2.8	2.7	2.5	2.4	2.2	2.0	1.8	1.5	1.2	1.0
You're only maximizing damage / escape_angle at ranges just below 600.

-- PEZ

New for me :) -- Axe

I already changed it, my next version will use it. I'm also changing lots of other stuff (as usual), so it will be hard to know exactly what impact it had. -- ABC

If you didn't change too much in your gun maybe you can try it in the RoboRumbleGunChallenge later. -- PEZ

Good idea, I'll do that. -- ABC

Axe, with my guns segmenting both on time-since-deccel and time-since-accel has never worked. I can't understand why, but it's how it is... Anyway, maybe it's the same with your sampling? You could try replacing those two informations in your samples with just time-since-velocity-changed and see if that makes a difference. -- PEZ

Excelent idea... Iīll try that. Dunno why, but time-since-inverted also dont work... -- Axe

Seems like time-since-decceleration only helped. I wonder why adding time-since-accelration makes things worse... Anyway congrats on a new record high! Some more work with your gun and you'll grab that crown. Distance-to-wall seems like an odd choice of segmentation. Is there more to it than the name implies? -- PEZ

First i caculate my "regular" pattern matching value (lets call it rate), then i do this to rate:
double hdiff = Math.abs(REFERENCE.headToMe) - Math.abs(this.headToMe);
double ddiff = REFERENCE.distanceMe - this.distanceMe;
double wdiff = REFERENCE.distanceWall - this.distanceWall;
double tsdeaccdiff = REFERENCE.timeSinceDeacc - this.timeSinceDeacc;
rate += (rate * (tsdeaccdiff * tsdeaccdiff / 200.00));
rate += (rate * (ddiff * ddiff / 20000.00));
rate += (rate * (hdiff * hdiff / 500.00));
rate += (rate * (wdiff * wdiff / 20000.00));
The higher rate is, the worst. I then throw the best(lower rates) in my MultipleChoice.
About my new distance-to-wall, first i was using a fuction that gave me the perpendicular distance to nearest wall (exactly the same that David recently described). It was a bad choice, my tests show. My new fuction is that:
public static double distanceToWall(Point2D.Double botPos, double heading,
            double vel) {
   Rectangle2D.Double field = AxeBot.getIt().getField();
   if (vel != 0) {
      heading = RoboMath.normalRelativeAngle((vel < 0) ? heading - 180: heading);
      double absHeading = Math.abs(heading);
      double vertD = (absHeading < 90) ? (field.getMaxY() - botPos.y): botPos.y;
      double horzD = (heading > 0) ? (field.getMaxX() - botPos.x): botPos.x;
      double vertA = (absHeading > 90) ? (180 - absHeading) : absHeading;
      double horzA = Math.abs(absHeading - 90);
      double d1 = vertD / Math.cos(Math.toRadians(vertA));
      double d2 = horzD / Math.cos(Math.toRadians(horzA));
      return Math.min(d1, d2);
   } else {
      heading = RoboMath.normalRelativeAngle(heading);
      double absHeading = Math.abs(heading);
      double vertA = (absHeading > 90) ? (180 - absHeading) : absHeading;
      double horzA = Math.abs(absHeading - 90);
      double toTop = field.getMaxY() - botPos.y;
      double toBottom = botPos.y;

      double toRight = field.getMaxX() - botPos.x;
      double toLeft = botPos.x;
      double d1 = toTop / Math.cos(Math.toRadians(vertA));
      double d2 = toBottom / Math.cos(Math.toRadians(vertA));
      double d3 = toLeft / Math.cos(Math.toRadians(horzA));
      double d4 = toRight / Math.cos(Math.toRadians(horzA));
      return Math.min(Math.min(d1, d2), Math.min(d3, d4));
It returns the dist to the intersection of the wall with a big vector representing the moving direction (considering heading & velocity). If vel=0, gives the shortest distance both fwd & backwards direction. It improved my rank some pts. -- Axe

I moved the last part of this discussion to the Targetting page! It was not SS specific and of interest to all who want to improve their gun. --Loki

I moved the part of this discussion concerning data windowing/smoothing to the DataSmoothing page! --Loki

And another question: how about moving this part of the discussion to the GuessFactorTargeting page? I tend to forget where i can find this kind of practical information when it isn't organised. --Loki

Apropos 2.53.19 You shouldn't need any fancy get_future_pos() stuff to figure out the T+1 positions, should you? This is what I do in CassiusClay/Bee:

	Point2D nextRobotLocation = PUtils.project(robotLocation, robot.getHeadingRadians(), robot.getVelocity());
	Point2D nextEnemyLocation = PUtils.project(enemyLocation, e.getHeadingRadians(), e.getVelocity());
	double nextBearing = PUtils.absoluteBearing(nextRobotLocation, nextEnemyLocation);
	double guessedBearing = nextBearing + orbitDirection * (wave.mostVisited() - GunWave.MIDDLE_FACTOR);
Here I assume that the bots will move using their current heading and velocity. A correct assumption, in'it?

-- PEZ

Its probably not a bad assumption. But if you want to be really accurate you can determine your own future position (and only that is needed in 2.53.19 i think) using information from getDistanceRemaining() and getTurnRemaining() (of course movement code has to be executed before targeting code then). I do it in Ascendant this way. --Mue

How would the information from those two calls change the prediction? I think I must make some tests with this. And how come you would only need your own future position? -- PEZ

I've checked some and my predictions are about 0.7 units off on average. Sometimes as much a 2 units off (even if that is rare). How accurate are your predictions Mue? -- PEZ

(edit conflict) Ok, first question: With these methods you can determine your own velocity and heading for the next tick. So you dont need to assume that they remain the same in the next tick.

Second question: I'm of course not sure what Axe needs this for, my guess: Targeting is about predicting where the target will be when the bullet reaches it, so if t is the tick the bullet is fired you want to know where the target will be at tick t+traveltime. In Ascendant i determine the desired heading of the gun on tick before i fire, so that there is usually enough time (1 tick) to turn the gun. Thats why i need a prediction at tick t-1 where the target will be in t+traveltime ticks. When i have this prediction (still tick t-1) i need to calculate the desired gun heading for the next tick (t), which is the bearing from my position next tick to the targets predicted position. There my own future position is needed.

Its probably rather irrelevant in guess factor guns, since these dont return a predicted position of the target but the firing angle instead. Here i use my position the next tick for segmentation purposes (calculating the distance segment to use). I take the distance from my future position to the targets current position to avoid influences from Ascendants movement on the data the gun should learn about the targets movement. Yeah i know, its a very small correction, and i wouldnt have bothered with this had i written only guess factor guns. --Mue

But I don't, purposefully, assume that the velocity and heading will remain the same the next tick. I just thought that the velocity and heading I read tick T will be the velocity and heading used by Robocode to move the bot. Obviously that's a wrong assumption. As you can see above all I use the predicted positions for is to turn the gun the correct amount. I figured that this should make a difference at close ranges. (Since the bot positions can change as much a 16 units). -- PEZ

SS is getting stronger by the day! It doesn't lose against many bots. In fact it's in the lead of PremierLeague. Good work! When do you predict to grab the crown? -- PEZ

Thanks... These tests had show me that y gun has plenty of space for improvement and tweaking, this plus those 9 points your 1.9 bullets gave me (thanks again) is leading me higher fast... About the crown-strike, itīs not time. Yet... :) "When u see the white of the eyes, unleash hell..." :) -- Axe

About your adding of "bonuses" for this or that. I think you're using a bit strange semantics when you translate that to code. For example rate /= (hit)?2D:1D;. I would rather do bonus = hit ? 2D : 1D; and then adjust "rate" later. This is picky you might think, but I am PickyPEZ after all. =) I think the semantics expressed by your code should correlate with the metaphore you use for the solution. In big and in small. -- PEZ

U might be right, but the History is made more for myself, so i rather stick with the original code (even if i sometimes i do lil adjusts for clearbility(?)). The history is a lil dificult to understand for "foreigns", but i try to maintain it clear enought to be understandable with some efforts. Much better than "Tweaked a little", dont? :) -- Axe

U can also ask if u have any doubts... (but that u know) -- Axe

Oh, yes. You have the best history log of all I think. That's not what I meant. I meant that you might benefit from now and then questioning the semantics of your code. I know you have tons of code so it's probably huge work to do this for all code. But the code you currently are working with at any given moment is a good scope I think. I try to always inlclude one refactoring in every update of my bot which is larger than a change in DEFAULT_BLIND_STICK_LENGTH and such. -- PEZ

To be honest, iīve got that from u, Great "Robotcode Prospector"... When u reach such thin air like 2050+, testing more than two issues at one version only leave u doubts. It might be slower to improve, but u remember that story about turtles & rabbits... -- Axe

@PEZ: U might have discovered a bug at my cannon (or broken it...), take a look at 2.53.31 history... -- Axe

Cool. I have to choose between blame or shame often since I can't keep my mouth shut. Those divisors (200, 20000, 500 20000) are weights or what? Meaning you weight ddiff higher or lower than hdiff? The reason I have now started to ask questions about this is that your progress with your gun has made me ready to make another try with Resin. I should be able to merge some of your gun ideas with my GF approach I think... -- PEZ

At least, it means that some listen to u... :) Iīll explain those bonus later, im going now... -- Axe

Well, "bonus" was a very badly chosen name... Penalty should be better. In code, i have a rate propertie, that is first assigned to my "pure" PM rating (see Musashi page for an explaining), then is applied that penalties for h(eads)diff, d(istance)dif, t(ime)s(ince)deacc(eleration)diff & w(alls)diff. These penalties curves (x*x)/n where never tweaked (ill probably do this next), but my idea is to have huges penalties for huger diffs (i made a graph of the curves, but unfortunately my web space is out...). I have also introduced, after having those panalties applied to rate, a bonus (yes, now is a bonus) to newer samples that im currently tweaking. -- Axe

2096 points with 109 battles. Pretty cool! -- PEZ

It wont last... Iīll be happy with 2063... -- Axe

It was at 2099 a while too. Almost touching 2.1K ground! -- PEZ

Mirrored distance to corner. Isn't that about the same as distance from center? -- PEZ

actually no. it isnīt mirrored from corner, but the minor distance between bots absolute positions (sample & reference) mirrored in the 4 quarters of the field (up-left,up-right,down-left,down-right). Tell me if that wasnt clear enought... -- Axe

Robo Home | SilverSurfer | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited November 29, 2004 5:02 EST by Axe (diff)