Editing revision 282 of SilverSurfer/History

Robo Home | Changes | Preferences | AllPages

Editing old revision 282. Saving this page will replace the latest revision with this text.

2004-11-25: version 2.62 
Based v2.61 
if rammer and distance < 300, firePwr=3.0 
Result:2058.94

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+longAllHits(HOT) 
.allHits+Hits (hitsAvg < 0.07) 
.allHits+Hits+0.5*visits (hitsAvg >= 0.07) 
Result:2058.94

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

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

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

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

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

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. 
Result:2048.53

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]]. 
Result:2058.23

2004-11-11: version 2.53.39 
Based v2.53.38 
Gun: 
Back with bonus for last hits:
<pre>
if(PatternSample.resetHits){
 hits=0;
}else if(hits>0){
 rate /= 1D+(1D - Math.pow((double)hits/(double)MAX_HITS,2 ));
 hits--;
}
</pre>
Back with old latest samples bonus formula, now:
<pre>rate /= 1D + ((difAge < AGING_LIFE)?1D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);</pre>
old:
<pre>rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),0.5)):0);</pre>
Result:2053.8

2004-11-10: version 2.53.38 
Based v2.53.36 
Gun: 
distance-to-corner stronger(1 factor) at corners, weaker(null, factor 0) at middle field.
<pre>
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);
</pre>
PatternSample rating: time-since-deccelerating , distance , heading, distance-to-wall & distance-to-corner weightened. 
Result:2059.22

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

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

2004-11-08: version 2.53.34 
Based v2.53.33 
Gun: 
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. 
Result:2059.64

2004-11-07: version 2.53.33 
Based v2.53.32 
Gun: 
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 
Gun: 
back to AGING_LIFE=100; in:
<pre>
rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),0.5)):0);
</pre>
Result:2059.50

2004-11-05: version 2.53.31 
Based v2.53.30 
Gun: 
At PatternSample.rate():
<pre>
//PEZ dicovered this "bug"(?)...
//I was using rate += (rate * ... without using a bonus
//variable.
//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;
</pre>
Result:2061.27

2004-11-05: version 2.53.30 
Based v2.53.28 
Gun: 
an inverse curve comparing to previous. AGING_LIFE=200:
<pre>
rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),0.5)):0);
</pre>
Result:2058.97

2004-11-04: version 2.53.29 
Based v2.53.28 
Gun: 
AGING_LIFE=200; was 100. in:
<pre>
rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);
</pre>
Result:2056.04

2004-11-04: version 2.53.28 
Based v2.53.27 
Gun: 
Removed the bonus to the hitted in samples. 
Removed the bonus to the last-hitted in samples. 
Stronger bonus for newer samples:
<pre>
rate /= 1D + ((difAge < AGING_LIFE)?3D*(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);
</pre>
Result:2060.94

2004-11-03: version 2.53.27 
Based v2.53.25 
Cleaned old code (some)
Gun: 
Adding a bonus to the hitted samples: 
<pre>
rate /= (hit)?2D:1D;
</pre>
Result:2047.58 - buggy?

2004-11-03: version 2.53.25 
Based v2.53.23 
Gun: 
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: 
<pre>
if(hits>0){
 rate /= 1D+(1D - Math.pow((double)hits/(double)MAX_HITS,2 ));
 hits--;
}
</pre>
Result:2062.18

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

2004-11-01: version 2.53.22 
Based v2.53.21 
Gun: 
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}; 
Result:2059.34

2004-11-01: version 2.53.21 
Based v2.53.20 
Gun: 
Back with the old shooting blocking scheme...
Added a attempt to faster-learning gun, rating (AGING_LIFE=100):
<pre>
rate /= 1D + ((difAge < AGING_LIFE)?(1D-Math.pow(((double)difAge/(double)AGING_LIFE),2D)):0);
</pre>
Result:2061.15

2004-11-01: version 2.53.20 
Based v2.53.19 
Gun: 
Trade the shooting block for bullet power restriction:
<pre>
if ((lifeAfter <= 8) && (lifeAfter < hisLife) && (target.getDistance() > 150)) {
 pwr= 0.1;
}
</pre>
Result:2056.15

2004-10-30: version 2.53.19 
Based v2.53.18 
Gun: 
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(). 
Result:2059.21

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

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

2004-10-29: version 2.53.16 
Based v2.53.15 
Gun: 
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...). 
Result:2044.96

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

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

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

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. 
Result:2052.74

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

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

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

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). 
Result:2040.97

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

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

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

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}; 
Result:2041.97

2004-10-19: version 2.53.03 
Based v2.53.02 
Gun:
Trying:
<pre>
double maxPwr = (BulletTracker.getHitAvg(target.getDistance())>0.35 )?3.0:1.9;
bulletPower = (distance<150)?3.0:maxPwr;
</pre>
Result:2041.39

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:
<pre>
double maxPwr = (BulletTracker.getHitAvg(target.getDistance())>0.25 )?3.0:1.9;
bulletPower = (distance<150)?3.0:maxPwr;
</pre>
Result:2038.53

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). 
Result:2031.09

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

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

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

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

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. 
Result:2036.72

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

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

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. 
Result:2024.90

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 [[HOT]]s. 
Result:2038.23

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

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

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

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). 
Result:2042.98

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... 
Result:2037.79

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. 
Result:2027.07

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

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

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

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... 
Result:2028.21

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

2004-06-20: version 2.33.3.3 
Keeping 2.33.3 cfg . Fixing bug in 2.33.3.2. 
Result:2033.94

2004-06-19: version 2.33.3.2 
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 2.33.3.1 
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-). 
Result:2029.78

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. 
Result:2031.70

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

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. 
Result:2033.10

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. 
Result:2031.94

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. 
Result:2029.84

2004-06-08: version 2.27.5 
Keeping 2.27 cfg. Anti-ramm tweak again (hopefully without bug of 2.27.4.* series). 
Result:** RECALLED, UPLOADED WRONG VERSION!! **

2004-06-08: version 2.27.4.2 
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). 
Result:2022.23

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

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

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

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. 
Result:+90.93(2018.73)

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; 
Result:+69.70(1998.54)

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. 
Result:+78.79(2006.42)

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

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. 
Result:+81.79(2010.93)

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. 
Result:+72.40(2000.48)

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. 
Result:+63.31(1992.33)

2004-05-12: version 2.21 
Manteining 2.20.1 cfg. Navigation more precise. 
Result:+89.19(2019.62)

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. 
Result:+75.85(2003.05)

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)). 
Result:+82.05(2009.56)

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)). 
Result:+88.62(2015.59)

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. 
Result:+74.79(2002.24)

2004-05-03: version 2.18.1 
2.18 variant. Lightweighted cannon 10000 samples max. 
Result:+81.76(2009.67)

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

2004-05-03: version 2.18 
Manteining 2.17.2 cfg. Lightweighted cannon 20000 samples => 5000 samples max. 
Result:+82.20(2011.41)

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

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

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)). 
Result:+82.17(2010.80)

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

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

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. 
Result:+59.45

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). 
Result:+57.16

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 
Result:+64.42

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 
Result:+81.02

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 
Result:+67.09

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 
Result:+65.04

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 
Result:+71.37

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 
Result:+53.51

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 
Result:+51.70

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. 
Result:+26.59

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 
Result:+25.53

2004-03-27: version 1.11. 
Trying a move-to rating inspired on [[Jamougha]]´s gf rating. 
Result:+17.02

2004-03-24: version 1.10. 
More deep inside the restrictions age. Tweaked with [[PEZ]]´s TGB. 
Result:-12.25

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. 
Result:-2.60

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

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

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

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. 
Result:+4.75pts.

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

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:

<pre>
public static double fastAverage(double n, double oldVal, boolean mark){
 return (mark)?1D:(oldVal*(1D-(1D/n)));
}
</pre>
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]]
* :^)! Partially refreshed, and also started to suffer of RC cold-turkey seizures! -- [[Axe]]

----

[[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]]

* Never mind. I aborted the match and restarted the client and now everything seems fine again. Very strange though.... --[[Vic]]
* My client stops in mid battle some times too. Might be a pattern to which bots are running, but I haven't looked in to it, since it doesn't happen very often. -- [[PEZ]]
* Something is strange after 2.27.3... But i'm talking about some lost points, not about freezing... SS's gun is heavy, no doubts about it, but i think that less heavy then DT or Iiley's... (@ [[Vic]]): Maybe u r having that freezing because of that [[JRE 1.4.2 SecurityException Bug]], if u r running JRE 1.4.2... ([[jim]] had solved this, just need to use the "-Dsun.io.useCanonCaches?=false" option. Something like: "java -Dsun.io.useCanonCaches?=false -Xmx256M -jar robocode.jar" (if u aren't using it yet). PS: Thanks a lot for reporting it! Pls let me know if it happens again.-- [[Axe]]  
* No, this was not the [[JRE 1.4.2 SecurityException Bug]]. There was no message whatsoever, the client also did not freeze, since I could just close its window. It was just a freak occurrance I think... --[[Vic]]
* Strange, have no clues about it... But the client sometimes behaves very strangely... -- [[Axe]]

@[[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]]
* I knew that u would notice that "last breath" issue... :) -- [[Axe]]

Can you tell us some more on that "real" bot simulator? -- [[PEZ]]
* It´s a class that simulates my bot moving precisely, calculating headings and vel tick by tick... something like [[FuturePosition]]...

Good to see you taking HOA seriously. What I tried with the low 1.8 CC's was this:
<pre>
 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);
</pre>
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]]
* It´s buggy... Don´t know, though, if fixing will help, but... -- [[Axe]]

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: 
 System.out.println();
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]]
* PS: probably a problem during my download... let me know if someone have trouble with it... re-launching it... -- [[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:
<pre> 
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);
 bullCount[i]++;
}
 
private static int getDistIndex(double dist){
 return (dist<200)?0:(dist<300)?1:(dist<400)?2:(dist<500)?3:(dist&lt;600)?4:5;
}
</pre>
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:
<pre>
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
</pre>
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]]
* Thanks for your good luck words! Yep, decell only seems the best in my scheema(?). Btw: i´m not talking about segmentation the way u normally use it, actually is a PM sample rating: 
First i caculate my "regular" pattern matching value (lets call it rate), then i do this to rate:
<pre>
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));
</pre>
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: 
<pre>
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));
 }
}
</pre>
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]]:
<pre>
	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);
</pre>
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 <code>getDistanceRemaining()</code> and <code>getTurnRemaining()</code> (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]]

* Hm, not sure right now, its been awhile since i checked this. I believe they usually match exactly. There are some rare cases where my predicted velocity does not match with the one chosen by Robocode, so that the predicted position is about one pixel off. --[[Mue]]

(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 <code>rate /= (hit)?2D:1D;</code>. I would rather do <code>bonus = hit ? 2D : 1D;</code> 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]]

Summary:
Consciousness check: 6 * 2 =
This change is a minor edit. Send email notification that SilverSurfer/History has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | SilverSurfer | Changes | Preferences | AllPages