Talk:SilverSurfer/Version History
From old wiki
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
- :^)! 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:
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
- 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:
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<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
- 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:
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
- 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 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
- [View source↑]
- [History↑]
