Editing PulsarMax/OldChatSummer2004

Robo Home | Changes | Preferences | AllPages

i'm decompiling this first chance i get to see exactly what else it's "based" on. --[[andrew]]

Ok, can't really stop you, but I don't really care either, but what are you implying? --[[Pulsar]]

17th!! A hell of a start! Congratulations! -[[Axe]]

Thanks! --[[Pulsar]]

Something must be wrong with your WaveSurfing. I think that with working surfing and just a basic (and working) GF gun you should get 1930+ points at least in the current RoboRumble environment. With a TC top-10 gun 1950 points is some kind of minimum. Have you tried using RobocodeGLV014 to debug/tune your surfing? If not I strongly suggest it. Check out PugilistGL to get a head start, even if that version of P was a bit flawed in its surfing. All releases of P has the GL code with it, commented away. So the latest release (1.9.3.3) could be a better choice since I think it is more similar to Max's surfing. (It's iterating the waves and bot future positions to find the impact and such.) -- [[PEZ]]

Oh really? Could very well be one or more bugs then, actually more than likely there are I guess, easy to get lost in the wave surfing! The movement is fairly flat though (for waves fired when I fire) when I checked with TGrapher yesterday(nice utility!), well at least when I tried 500rounds. Adding velocity and acc segments to it made those too flatter as well, but I guess they increased learning time enough to make just about 0 difference in the ranking, without any dynamic segmentation. Indeed, I have RobocodeGLV014 stuff in my bot that I can easily activate again. The waves are all lined up with the shots etc at least. Anything else I should look for you think? Hmm maybe draw the guess forward and backwards guess factors I think I will reach. It couldn't be something simple as the wall avoidance which isn't exactly perfect? 
I iterate over all waves that haven't impacted yet (time left to impact less than 1) and that have been fired by the enemy (real waves only). Calculate the forward guess factor and reverse guess factor by iterating my position one step at a time (inlcuding wall avoidance). Sum up the values for that index I'm going to reach for backwards and forwards, sum it upp for all waves weighted on distance and make the choice. Basic wavesurfing from the wiki. Though I like to implement stuff myself so I understand it better. "Grasp the idea and (try to) do it" (and get the bugs ;-) ).
Hmm could the problem be that I calculate time left to impact and then iterate that number of steps, instead of calculating positions until the wave has passed whatever iterated positon I'm at. Well that doesn't help at least! Even sounds likely!

Maybe I should try:
# Iterate positions until impact and not for time left to impact steps.
# surf one bullet at a time again, with some simple test bot firing at me, back to basics
# The movement is based on circling my enemy, and I assume they stay in place when iterating my future positions. Should do something else? Circle a bullet origin, those don't move after all.
# Check all the math, maybe the guess factor and/or guess factor index calculations are wrong? Boring but I guess I will have too check all math :)
# all of the above :-)

Think I should start with the first point and maybe the two second ones after that.

Thanks for the heads up! Sounds promising! If I just NOW hadn't got this PILE of work dumped on me and the upcoming 5-6days therefore ruined it might have made me spend a lot of time on it this for a couple of days -- [[Pulsar]]

I think you have a bug somewhere. The things you mention are all possible improvements, but [[Pugilist]] 1.6.4.30b didn't do 1, 2 or 3 and still collected 1982 points. The iteration should be: iterate the wave and bot position one tick at a time until they impact. But this only gets really important when WallSmoothing, so it can be compensated quite much by heavy wall bouncing. If you're wall smoothing much then you might want to fix the iteration thingy first. As long as you weight the bullets you surf by closeness to you you can surf all bullets in the air. This should in theory be better than just surfing the closest. I think that it might be better to circle the enemy when figuring out the guessfactor and doing the actual movement, but make sure you calculate the visit-counts from the wave origin. Use RobocodeGLV014 to check all your assumptions. Assumptions are bad! You shouldn't work weekends anyway. =) -- [[PEZ]]

Thanks again [[PEZ]]. Ok a bug then, but I'm not wallbouncing, sort of wallsmoothing but always in the direction of the enemy (based on ideas from the WallSmoothing page), which is bad when too close, but somewhat compensated by trying to keep distance. Will add "wall smothing away fron enemy" when too close and/or bounce later on.  I'll have to do the bug-search dance then when time permits. Anyone who have tried to set up a debugger with robocode by the way? As we have back in time debugging possibilities nowadays with java it would be rather nice testing with robocode, (go back and forth between ticks). Some remote debugging I guess. -- [[Pulsar]]

If you're not wallbouncing at all and not iterating the bot and wave position forward to impact (or calculating this somehow else as exactly) then this could be the full explanation for your missing 70+ points. I say do the iteration-thingy and add "wall-bouncing when close" and see what happens. You might not have that huge bug after all. Chasing [[Shadow]](s) is better done in the rumble. =) -- [[PEZ]]

Trying to catch some stats in action away from walls:
<pre>
RobotVelocity=0.0 Wave dist left=202.64002879859044currentIndex=19 forward=15 reverse=22
RobotVelocity=0.0 Wave dist left=414.1613097423001currentIndex=14 forward=6 reverse=24
RobotVelocity=1.0 Wave dist left=188.41461374203703currentIndex=19 forward=15 reverse=22
RobotVelocity=1.0 Wave dist left=399.7700213372559currentIndex=14 forward=6 reverse=23
RobotVelocity=2.0 Wave dist left=174.25876362077844currentIndex=18 forward=15 reverse=22
RobotVelocity=2.0 Wave dist left=385.28228705011645currentIndex=14 forward=6 reverse=22
RobotVelocity=3.0 Wave dist left=160.16215847190603currentIndex=18 forward=15 reverse=21
RobotVelocity=3.0 Wave dist left=370.68752132557324currentIndex=14 forward=6 reverse=22
RobotVelocity=4.0 Wave dist left=146.1090248666706currentIndex=18 forward=15 reverse=20
RobotVelocity=4.0 Wave dist left=355.9695755799086currentIndex=14 forward=6 reverse=21
RobotVelocity=5.0 Wave dist left=132.0773869296625currentIndex=18 forward=15 reverse=19
RobotVelocity=5.0 Wave dist left=341.10601997438175currentIndex=14 forward=6 reverse=20
RobotVelocity=6.0 Wave dist left=118.03954189812373currentIndex=18 forward=15 reverse=18
RobotVelocity=6.0 Wave dist left=326.06865634136625currentIndex=13 forward=6 reverse=19
RobotVelocity=7.0 Wave dist left=104.64479478064493currentIndex=17 forward=15 reverse=18
RobotVelocity=7.0 Wave dist left=311.5067835707963currentIndex=13 forward=6 reverse=18
RobotVelocity=8.0 Wave dist left=91.26507239705967currentIndex=17 forward=15 reverse=17
RobotVelocity=8.0 Wave dist left=296.7916148154651currentIndex=13 forward=6 reverse=17
RobotVelocity=8.0 Wave dist left=77.7598085150679currentIndex=17 forward=15 reverse=17
RobotVelocity=8.0 Wave dist left=281.9495289542424currentIndex=13 forward=6 reverse=16
RobotVelocity=8.0 Wave dist left=64.12626133286074currentIndex=16 forward=15 reverse=16
RobotVelocity=8.0 Wave dist left=266.97812231267676currentIndex=12 forward=6 reverse=15
RobotVelocity=8.0 Wave dist left=452.52341536184446currentIndex=14 forward=25 reverse=6
RobotVelocity=6.0 Wave dist left=50.215872587923currentIndex=16 forward=16 reverse=16
RobotVelocity=6.0 Wave dist left=252.06393283689192currentIndex=12 forward=15 reverse=6
RobotVelocity=6.0 Wave dist left=438.26487518705574currentIndex=14 forward=6 reverse=25
</pre>
currentIndex is the guessFactor index I am at now for this wave. Dist left is the dist left this wave has for me right now (no not the one I use to weight them, I use the wave origin for that of course). Forward and reverse indexes are my predicted guess factor indexes for going forward and backwards.
Shouldn't forward and reverse index-distance from current index always differ with about 4 if speed is 8? (I guess velocity/2 in general).
I'll try assuming my forward index prediction is ok and just use that minus velocity/2 in the other direction as reverse guess factor index now I guess. Hmm well even if account for accel/deaccel that's too simplistic I guess though. -- [[Pulsar]]

Hmm disregard all that, depends on how wide the guess factor is at this distance relative to the velocity of the robot, I mixed up time and indexes :) -- [[Pulsar]]

(Edit conflict) ... disregarded. =) -- [[PEZ]]

Might have found something, but that is a really small thing, if I covered more than one guess factor I used the last one all the time. Seems way too small a thing though. Removing all movement stats saving, doubt it helps much anyway, maybe even the opposite as it isn't using rolling averages (just adding to them). Still haven't found a good way of doing wall bouncing when under a certain distance, usually gets semi-stuck for a second or two if I do that it seems, maybe I need a margin or something. -- [[Pulsar]]

Yes, probably too small a thing to make a huge diff. Bouncing is trickier than some people think. But can be truly simple if you get it right. Here's how I do it in Pugilist:
<pre>
 static Point2D wallSmoothedDestination(Point2D location, double direction) {
	Point2D destination;
	double tries;
	int i = 1;
	do {
	 tries = 0;
	 while (!fieldRectangle.contains(destination = project(enemyLocation,
			 absoluteBearing(enemyLocation, location) + 0.4 * direction,
			 location.distance(enemyLocation) * (1.2 - tries / 100))) && tries < MAX_WALL_SMOOTH_TRIES) {
		tries++;
	 }
	 direction = -direction;
	} while (i-- > 0 && distanceIndex < 1 && tries > 20);
	return destination;
 }
</pre>
The outer loop is the bouncing. I use do-loops just because they cost me less bytes. Rewrite as for-loops when you're not code size constrained like me... Note that Pugilist uses the above function both when it's evaluating the forward and reverse possibilities and when it's actually moving. -- [[PEZ]]

Thanks, but I will find a way to adapt the way I do it so I understand what's happening to 100% (or think I do) :-) 
I use this which is just slightly modified/added to from one of kawagis old examples I think (WallSmoothing page) (some tried things commented out).
<pre>

//double goalDirection = currentTarget.bearing+Math.PI/2; //good for melee?
 double goalDirection = currentTarget.absbearing-Math.PI/2*direction;
 //mod depending on distance (move closer or further away from enemy)
 if (currentTarget.distance > Settings.WAVE_SURF_OPTIMAL_DISTANCE+Settings.WAVE_SURF_MARGIN_DISTANCE) {
 goalDirection += direction * Math.PI/32; //TODO tweak
 } else if (currentTarget.distance < Settings.WAVE_SURF_OPTIMAL_DISTANCE-Settings.WAVE_SURF_MARGIN_DISTANCE) {
 goalDirection += direction * -Math.PI/8;
 }

boolean wallAvoiding = false;
        double turnDirection = direction;//-direction; //TODO doesn't work in corners when changing direction! or something like that
        while (!field.contains(move.x+Math.sin(goalDirection)*120,move.y+Math.cos(goalDirection)*120)
               &&field.contains(move.x, move.y) ){

/*if (currentTarget.distance < 300) {
 this.direction *= -1;
 goalDirection += Math.PI;
 break;
 }*/

/*if (currentTarget.distance > Settings.WAVE_SURF_OPTIMAL_DISTANCE+100) {

} else if (currentTarget.distance < Settings.WAVE_SURF_OPTIMAL_DISTANCE-50) {
 turnDirection *= -1; //TODO but needs other things further below I guess, tends to get semi-stuck, could be because it takes a while to change dir, or interaction on next movement when border condition?

} else {

}*/
            goalDirection += .1 *turnDirection; 
            //or exactly at 450... need margin both ways
            //(currentTarget.distance > Settings.WAVE_SURF_OPTIMAL_DISTANCE ? direction : -direction);  //turn a little toward my enemy and try again
            wallAvoiding = true;
        }
        double turn = robocode.util.Utils.normalRelativeAngle(goalDirection-move.heading);
        if (Math.abs(turn) > Math.PI/2){
            turn = robocode.util.Utils.normalRelativeAngle(turn + Math.PI);

if (wallAvoiding) {
                maxVelocity = turn>Math.PI/6?0:8;
                robot.setMaxVelocity(maxVelocity);
            } else {
                maxVelocity = 8;
                robot.setMaxVelocity(maxVelocity);
            }
            robot.setTurnRightRadians(turn);
            robot.setBack(Double.POSITIVE_INFINITY);
        }
        else{
            if (wallAvoiding) {
                maxVelocity = turn>Math.PI/6?0:8;
                robot.setMaxVelocity(maxVelocity);
            } else {
                maxVelocity = 8;
                robot.setMaxVelocity(maxVelocity);
            }
            robot.setTurnRightRadians(turn);
            robot.setAhead(Double.POSITIVE_INFINITY);
        }

</pre>

So now you see why I need to improve it some :) -- [[Pulsar]]

Of course you should do it your way. I just pasted the code to show you what I mean by wall-bounce-if-close. It's basically RandomMovementBot with some bouncing added. Your code isn't that different really. If I remove all comments that is. =) -- [[PEZ]]

Cool! 1905 points, it's going in the right direction. And I thought I was the last Swede updating a bot last night. =) -- [[PEZ]]

1920 points!! You really like burning midnight oil man. Watch out though, you also need that beauty sleep or you'll get to be a pain for your work mates. =) -- [[PEZ]]

Hehe Well work during the day, and the eurovision songcontest and dinner at a friends place, when I finally got home I felt like checking robocode and immediately noticed a few weak things with the wave surfing. Strange thing is those small details seem to have made it weaker against the good bots and better against the weak ones. Go figure. -- [[Pulsar]]

That happens all the time to me. And alomst always it means a higher ranking. It's an oddity of the ranking system I guess. There are more weak bots then there are really strong ones. -- [[PEZ]]

One more thing. The [http://rumble.robowiki.net/servlet/RatingDetails?game=roborumble&name=pulsar.PulsarMax%200.2.6 details sheet] of 0.2.6 is looking really good. That's what I call a strong bot! -- [[PEZ]]
Regarding evading steeper at close ranges. Wish you luck. I've tried often, but never get it to work. If you solve it please share your implementation. For me allow-wall-bounce-when-close work better than any of my evade-steeper tries (and those are plenty). Also welcome in the club of people who refuse acceleration segmentation. =) -- [[PEZ]]

Well down 10 so far :-/ But that could just be random noise in my experience so far, 35 round battles can throw around the scores quite a bit. The evade steeper thing was for anti ramming I guess, I just increased the angle for distance keeping when the target is really close. I'm trying to wall bounce right now when close, think it works, could probably be improved thugh :)  I guess the increased complexity of the wave surfer segmentation (8, 3, 3, 2, 27) to (8, 5, 5, 2, 27) might have increased the learning times too. Soon I'm at the stage where I have the basics in place and can look at things such as dynamic data segmentation hopefully! -- [[Pulsar]]

Before you move on to dynamic data segmentation you could just try what I do. I use an unsegmented visit counter that I weight in when checking the visit counts of a particular destination. That improves learning speed a lot. 10 points is ''not'' random noice in the RoboRumble. 35 rounds x 260 enemies tends to level things out. =) -- [[PEZ]]

Was just seeing these 20-30% differences in scores against the same bot, not too rarely at all, but yes I guess it evens out. Hmm interesting, sort of a poor mans (byte starved? ;-) ) way of decreasing leanring time eah? Guess it is all about how you exactly weigh in those visit counts then. Hmm, gave me somethign to think about! -- [[Pulsar]]

Doesn't matter much how you weight'em as long as you weight it low enough to let your segmented data rule when you have data there. fast_visits / 1000 probably works. But I divide by total number of buckets (multiplying all segmentation dimension widths). Yes it's a byte poor mans fast-learning trick. [[ABC]] keeps visit stats of different levels of segmentation and sums them up weighted. I guess that borders dynamic segmentation. -- [[PEZ]]

gah I'm getting tired of testing stuff, so hard to see if things are an improvment or not :) I'm testing with both problem bots and better bots etc. Example:
<pre>
1st: pulsar.PulsarMax 0.2.7	2857
2nd: davidalves.net.YALT 1.3	2076
</pre>
Then the next run:
<pre>
1st: davidalves.net.YALT 1.3	2810
2nd: pulsar.PulsarMax 0.2.7	2136
</pre>

35 round matches... :-/ This is quite common for me at least. How can I possibly measure improvements? :) I guess the movement and targeting challenges are the only alternatives? And "graphers".
If I use longer battles it doesn't match the 35 round results. Anyone have some good ideas regarding testing? -- [[Pulsar]]

Run repeats of the 35 round battles (deleting any saved data between battles) and sum up the scores. Longer battles hide the difference in learning speeds, so may come out very differently from short battles, yet in shorter battles there is a higher level of randomness in the outcome of results. By repeating a shorter battle you should eliminate the randomness yet depict the learning speeds between bots. That said, i'm impatient so i just test over 100 rounds... --[[Brainfade]]

Yep, use RoboLeague to run many short battles. Also running longer battles, like 500 rounds or so, is much better than just running a single  35 round match. Try running against a [[TestBed]] that don't save data. Also there is the TargetingChallenge, CurveFlatteningChallenge and the real RoboRumble. -- [[PEZ]]

Thanks both of you! I had downloaded RoboLeague but hadn't tried it. Tested it now and it seems nice! And the targeting and movement challenges I was thinking I was going to try them out when my robot todo list grew shorter and it's time to start tweaking! I also think the maybe it was extra random due to some distance bugs in the wave surfing. -- [[Pulsar]]

No, it probably wasn't extra random. The margin of error is huge in 35 round battles. If you're testing against a bot of about equal strength then the above two results are typical I would say. If I where you I would start with the targeting and movement challenges ''before'' prioritizing that todo list. Doing it the other way around is ... well, silly (no offense!), wouldn't you agree?

One more thing I have been thinking about... You said somewhere that you corrected a huge bug where you didn't stop surfing waves that had passed you. I must ask. When do you stop surfing waves now? I don't have tests to support it, but I think you should keep surfing the wave until it has fully passed you. Since otherwise you might drive into the bullet you "know" is there from the side. Maybe you already reason like this, but anyway. =) -- [[PEZ]]

I don't trust anything with less than 1000 rounds... -- [[ABC]]

Fair enough :) Right now I surf waves that have passed me with a margin of 20 (distance left = -20). Thinking of playing around with it. 0.2.5 was the best and didn't surf waves that were passed the center (distance left 0) but there were other changes as well so we will see I guess. Maybe -10 is good enough, or I could use the time. But -20 sounds like the most logical choice to me. What do you all do? I weight all bullets/waves from 1 tick left to hit me (I iterate my future position together with the bullets distance travelled to get this time) to minus whatever ticks as 1 (Math.max(1, timeToHit)). I weight them by time left to hit me and not distance by the way. -- [[Pulsar]]

I use -18, might try 0 now when you mention it. =) What do you mean by weight all from 1 tick left to hit you? Time or distance for weighting is probably irrelevant in most cases except against CigaretBH (which fires with random bullet power). But even then I think that maybe weighting by time might be non-optimal since you weight high power bullets lower than low power. Then again, I weight by bullet travel time too. =) -- [[PEZ]]

I mean that waves with time to hit  with zero or lower I weight the same as with 1 tick left. -- [[Pulsar]]

0.2.10's detailssheet at 30 battles looks insane! 29 60+% wins. =) But. Looking closer I see you must have some big problem with your surfing. DuelistNano is firing head-on only and it's not a rammer. Which means you shold get 95+% against it. [[Jam]] once gave me the great advice to test my surfing against [[Barracuda]]. I'll pass that advice on to you. Good for my Karma. =) Are you trying to flatten your profile with your surfing? If so that could be why you give DuelistNano so many points. I would start out with only considering the enemy's actual hits on you. Then when you have gotten that to work you can experiment with weighting in flattening. -- [[PEZ]]

Ah great advice, thanks! Yup trying to flatten the movement, but assigning an actual hit a lot more points (trying a factor 10 and 100). I only use waves from the enemy when it is  firing at least. I was about to test against head-on targeting, but forgot! I think I will do as you say, to get that to work perfectly first and then move on. Thanks again! -- [[Pulsar]]

A good WaveSurfing should be able to get almost 100% against a HeadOnTargeting, i use [[Rozu]]�s HawkOnFire to test this. I use the mantra: "If it isn�t working against HeadOnTargeting, something is very wrong...". Btw, congrats for the improvements, Sweden seems to be a very good soil to Robocode! -- [[Axe]]

I fear that if [[Pulsar]] drops his flattening efforts I will no longer be top Swede though... Have to work harder with my Pugilist I guess! -- [[PEZ]]

Pugilist is a mini bot! You are embarrassing a lot of us right now due to that fact. :) You also have a micro in the top-20 general rumble! -- [[Pulsar]]

[[Pulsar]], the flat profile isn�t required for WaveSurfing (actually, i think that only me & Jamougha are using a flattener, and even we use it with a very small weight in comparisson with the adapter - just to create a kind of background noise). I think that the flat profile in WS depends a lot on the gun that is firing at you... I think that [[PEZ]] is right, u should not be so concerned about the flat profile.-- [[Axe]]

(Edit conflict). Thanks Pulsar! But I'm not sure it's an actual merit that Pugilist is a mini really. As long as it fits all important functionality I mean. Yes, I have had thousand and one idea for things I would do if I had unlimited bytes left. But the byte starvation forces me to prioritize. I had 22 bytes left the other day. And I actually had to think hard a while to figure out what I needed them for. =)

Another good test bot is bons.NanoStalker. It fires head on. But it also tries to fight point blank and even ram you. Which means you must have your close combat behaviour in good shape in order to score the 98%+ that is actually possible.

-- [[PEZ]]

The clean code also avoid u to introducing lots of bugs when cleaning your source (Like i did in SS) :) -- [[Axe]]

0.2.11 is much better against DuelistNano. Is it that you have shifted to avoid-real-hits only now? Then your result against NanoStalker might indicate that your surfing isn't prepared for when there are no enemy waves in the air. Something that happens at close ranges (since the enemy must wait for its gun to cool before firing again). I suggest you check for this condition (no wave to surf) and then either create a virtual wave or just plain evaluate which one of the reverse or forward options bring you the farthest from your enemy and then go there. [[ABC]] switches in mirror movement here, with great results. -- [[PEZ]]

Yes only real hits, well a factor of 1000 of difference between them instead (had only tried 10-100 before). I also init the guess factors to slightly avoid head on and linear aim. No indeed "close range means no bullets in the air, add virtual waves depending on gun heat estimate or something" is on my todo list as you guys mentioned something along those lines somewhere :) . I'm still plagued with targeting guessfactors way outside of 1 to -1, can go a round without them entirely and then get 10-20-30 at once now and then. But I'm waitig with gun improvments to 0.3.x. I also changed the enemies fired waves not to include my previous tick stats but the tick before that (t-2). Hope that's correct. Adding/changing too much at the same time here :) -- [[Pulsar]]

While gathering the strength to do virtual waves based on gun heat and such you could just do something much simpler. The important thing is that you keep moving away from a ramming or close-combat opponent. Yes, wait with the gun. You have some 20 or so points hiding in the close-combat thingy alone. That's 1950 points! I use mostly current tick stats. For velocity I use t-1 and t-2. But I would really like to use t-3 for all stats but last_velocity where I would want to use t-4. Can't fit it in my mini though... -- [[PEZ]]

By the way, I can't write thank you [[PEZ]] after ideas directly now coming from you in the change history above, that would mean writing that after almost all of them! :-) 
Hmm t-3?! You sure about that? t=current stats, t-1=enemy fired, t-2=enemy decided to fire, t-3=used to get acc and such. Hm maybe I'm missing one tick when enemy is getting a tick old stats in t-2 there? -- [[Pulsar]]

No, you're probably right. What I would want really is to decide what tick I want the stats from at will. The reason I'm still able to help you is that you are trailing my surfing efforts. I've just been where you are. Just passing on the lessons I've learnt. I'm happy if it really helps you. =) -- [[PEZ]]

Maybe it's too code size expensive, but why not use something like:
<pre>
double[] myVelocity = new double[HISTORY_LENGTH]
...
myVelocity[getTime()%HISTORY_LENGTH] = getVelocity();

//get velocity one tick back in time:
oldVelocity = myVelocity[(getTime()-1)%HISTORY_LENGTH];
//get velocity two ticks back in time:
olderVelocity = myVelocity[(getTime()-2)%HISTORY_LENGTH];
</pre>

I was using something like that in an old bot but haven't started to use it in this one yet. Just make sure you don't use it beyond the history-length-1. Can be codesize optimized to fit the exact usage I guess. -- [[Pulsar]]

Since I seldom have more than 5 bytes left I can't fit that. But I have made some experiments with keeping the waves in a list (like you probably do already) and then pick data from previous waves. Can't fit it yet, but I just might now that I make some other simplifications in Pugilist. -- [[PEZ]]

I'm not sure you really need a special case for rammers. What I can't fit in Pugilist, but I would like to is to check if there indeed are any bullets in the air towards me or not. And if not I would switch to a movement that basically just tries to get as far away from the opponent as possible. Then when the enemy fires I would start surfing again. This is different from what it says above you do in 0.2.12 - mirror movement for close combat. "Mirror movement when no waves to surf" is better probably, even though I haven't tested that myself. Rammers are what they are. If they really want to ram you it's hard to do much about it. I'm happy with the 65% or so I get. It's still a victory. And they can never ever win against my bot as long as I don't do something really wrong. Removing wall-bouncing is bold. But I would do it if I could fit the above scheme ... hmmm ... maybe I can. I must try.

Another issue. You say you factor hits 1000 times what you do flattening visits. That leads me to think you are not using rolling averages? I can't fit rolling averages in Pugilist, but I do this instead:
<pre>
 public void onHitByBullet(HitByBulletEvent e) {
	EnemyWave wave = EnemyWave.passingWave;
	if (wave != null) {
	 wave.registerVisits(++enemyHits);
	}
 }
</pre>
That means I almost only regard the last hit of the enemy. If you don't do anything like that you might be very slow at adapting when a GF gun has tuned in on you. P does really bad if I remove the cheap (byte wise) trick I do above.

-- [[PEZ]]

OK interesting, wave surfing seems to be getting less and less about flattening the more I use it and you tell me about it :) I originally thought it was all about that! I'll try this in a version soon. Probably 0.2.14, have to sort 0.2.12 results out in 0.2.13 I guess. Rolling averages are on the todo list, for both targeting and movement, but this seems quick enough to give a quick try! -- [[Pulsar]]

You are surelly on the right path, WaveSurfing is a really complex thing, small details can make a very huge difference... I think that Jamougha was the only one of us (and [[ABC]] too, i think...) that made it with none or few suffering (SilverSurfer�s name came from that, he is a surfer that suffers:), but Jamougha is a special case, a true genius! Wish only that someone (wish more that someone == me :) can dethrone RaikoMX, and awake him... -- [[Axe]]
* PS: if you aren�t using RollingAverage (or something like that) yet, you have a lot of pts. to collect there... -- [[Axe]]

I doubt rolling averages in the targeting will give you many points though. Flattening is not important in WavesSurfing it seems. At least not very important. Robocode was too easy for [[Jam]] I think. =) -- [[PEZ]]

Running [[Shiz]] some against Max (to check if I could see that strange results happen) I noticed that you give Shiz quite a few hits for free. The head-on targeters are legio in the rumble. If you can get Max to by default avoid head-on fire and only when hit with linear aim change its mind you have many points to collect. I do this simply by:
<pre>
	double direction = robotBearingDirection(ew.startBearing);
	...
	if (EnemyWave.visitsReverse < EnemyWave.visitsForward) {
	 direction = -direction;
	}
</pre>
That means that if reverse and forward are equally dangerous I go forward. Since I only count when I'm hit this makes P move GF1 until forcibly convinced that's a bad idea. You have to drop the flattener for this to work of course. But it's so much simpler than trying to figure the correct weight for the flattener and then trying to pre-load the counters for GF0 avoidance. Simpler often means better in Robocode.

-- [[PEZ]]

Hmm disabaled flattener entirely, and made sure the forward and visit check keeps me moving ahead. But I'm not always moving ahead. Wall avoidance and/or prediction problem it seems. -- [[Pulsar]]

Try forcing your predictor to always return the same danger value for reverse and forward. If you're still not always moving ahead you can probably rule out the predictor as the bug source. -- [[PEZ]]

Was about to follow your bug-finding advice there when I found this bad bug with the indexes when updating stats when a bullet hits. Now that's better, but it seems I always start of using avoid rammer movement the very first round. That's not too good a movement against most :) While investigating this also I found that registering the hits for the entire bot size covered guess factors isn't such a good idea always. At least not with the same value, should be lessened with distance I guess, some nice curve. I'm starting to understand the things you are all saying about minis and less complexity, in practice I mean. There are so many things like this :) But I would feel too limited in a mini or smaller. I'll try those when I have a decent bot here first. Again, so many ideas to test and so little time! A CPU-farm would be nice too have for testing as well. Right now I'm more testing some things but mostly add things that SHOULD be good, at least in the long run.... -- [[Pulsar]]

I wouldn't bother about bot width and stuff. Just smooth the stats when reading and it should all sort itself out. I use 25 bins with the latest versions of Pugilist and I just update whatever bin happens to match the best. I recall you are using 27, which is what I used a while ago, so it should work for you too I think. You can always add bot width complexity on top of a simpler design later.

As I said somewhere above. Try avoiding special cases. I only have one; point blank I allow wall bouncing. I was all the time planning to remove that special case, but am beginning to think it's stupid to force wall smoothed surfing at really close ranges. It's better to just try to get the h*ll out of there. Special cases invite bugs in my experience.

-- [[PEZ]]

Good point. Sort out the basic stuff first and introduce special cases later, bot still not too many. But I have a movement array. Main movement is wave surfing, but close up it's using mirror movement or if it looks like a rammer I run away. Then if the enemy is disabled I ram. Can't decide if I should let the movments decide them selves (they report how well they think they would be doing every turn, nothing fancy) or just have a central selector somewhere. The latter sounds like less bugs, but not as modular (who cares! well I do.. hmm) Details... just the system architect in me I geuss :) -- [[Pulsar]]

Movement selection is truly tricky business. Take it from someone who has explored that more than many. ([[Swiffer]]). I would wait with glueing that onto your surfing. Otherwise you will have a hard time knowing if your surfing works or not. More importantly. I think a rule like "mirror-movement when close" is not a good idea. What [[ABC]] is doing is "mirror movement when no waves to surf". Big difference. -- [[PEZ]]

Ok your objections are noted :) Mirror movement shuld maybe have that requirement as well indeed, thanks again, makes sense. In practice it usually has that, but not when distance less than 100. Wavesurfing returns Movement.SCORE_OK (rather low) when there are no waves to surf. I'm almost always wave surfing, the other stuff is just for special cases (yeah yeah I can hear you from here). I'll try ignoring the distance thing altogether, and only have it when no waves instead. It's almost the same but not quite and might be important. The good part about having distance in there is that it helps me get away when backed up against a wall. The bad part is that I could possible get hits that could have avoided. So maybe a short term vs long term decision. Hmm... could probably combine those things though. That's for later. Another thing for the "do/test later" part on the todo list :)
<pre>
In MirrorMovement:
public double getScore(DynMultiDimArray stats, AdvancedRobot robot, Enemy target, Map radar) {
 if (target.velocity != 0) {
 if (target.distance <= 100) {
 return Movement.SCORE_GREAT;
 } else {
 return Movement.SCORE_GOOD;
 }
 }
 return Movement.SCORE_NO;
}
</pre>
For short, I want learn from all your guys experience of course, but on the other hand I don't want to end up with basically the same bot as someone else's :-) But while debugging etc I agree it of course makes sense to for example disable other movements. -- [[Pulsar]]

Ah! I thought you were going to choose from measured performance, like [[Swiffer]]. The above is a different story. Looks OK, though a bit too fuzzy for my taste. I think the following sums up pretty well what's needed:
<pre>
void surf(boolean allowWallBounce) {
 ...
}

void move() {
...
 Point2D destination = (numSurfableEnemyWaves > 0) ? surf(distance < 120) : mirror();
...
}
</pre>
Don't worry about your bot ending just like any other bot. You're way to stubborn for that. =)
-- [[PEZ]]

hehe ok. For the next version (0.2.16 I guess) it will be:

<pre>
public double getScore(DynMultiDimArray stats, AdvancedRobot robot, Enemy target, Map radar) {
 if (target.velocity != 0) {
 if (target.getWaves().size() <= 0) {//target.distance <= 100) {
 return Movement.SCORE_GREAT;
 } else {
 return Movement.SCORE_GOOD;
 }
 }
 return Movement.SCORE_NO;
 }
</pre>

Indeed makes a little difference it seems. -- [[Pulsar]]

Hey, top 10! Congratulations! -- [[Axe]]

Thanks, didn't last after some more after 500 though :-( -- [[Pulsar]]
But back in top 10 at 600matches! :-) :-) Nice milestone for me. Did you have to add silverfist, now there are 9 instead of 8 ahead of me ;-) -- [[Pulsar]]
* [[PEZ]] & me , actually. Life isn't fair... :) -- [[Axe]]
* "You" is plural too ;-) Just makes it more challenging=fun! -- [[Pulsar]]
* SF is also beating SS & P (woops, we just had shoot our feet!:). Everything in the name of science! -- [[Axe]]

I see in 0.2.15 and .16 details sheets that you seem to have gotten both close combat behaviour and head-on avoidance in place now. It's not as easy to read out from the details what is now missing. Though I see that you have suspiciously low scores against [[Quest]], [[R2D2]], [[Aristocles]], [[Sedan]] and a few more GF targeters. To check I ran a short battle with Max and Quest. This because Quest is my current testing bot (together with DevilFISH) so I can compare with how P behaves. Here's the result:
<pre>
1st: pulsar.PulsarMax 0.2.16	7465	2600	520	3805	464	6	69	52	48
2nd: ad.Quest 0.10		7050	2400	480	3716	453	0	 0	49	52
</pre>
Now, 100 rounds is too short to draw too many conclusions from maybe, but I have run many, many 100 round battles against Quest and, unless something is broken in Pugilist, I never see Quest almost outsurviving me. Watching Max's output window I see that your lost rounds come in bursts. This might be a clue. Maybe you don't roll your movement data fast enough? Then Quest is adapting its gun faster than you adapt your movement. I think you should try going to the extreme where you only really consider the last hit in any segment. That would make you adapt instantly and give Quest a harder time catching up with you.

Just a thought. As always I might be wrong. Nothing seems to be for certain in Robocode. =)

/PEZ

I have my own personal expert robocode robot analyst! Great! I guess rolling averages are next (or ry some quick and dirty solution first), together with a few movement tweaks, and I'm sure I will find a bug or two as well. Then it's off to to gun-experimenting land in 0.3.x for a while. -- [[Pulsar]]

In Shadow 3.04 I don't use rolling averages or any other kind of stats decay... --[[ABC]]

Interesting. With Pugilist it's very important. Quest eats it alive if I remove the decay thingy. What do you think makes it not necessary for Shadow? -- [[PEZ]]

I don't know, I never had any problem with quest or any other GF gun (except DT's) with any of my wavesurfing variants... -- [[ABC]]

Could it be because you only use 17 stat bins? -- [[PEZ]]

I recently started using 31 bins, most of my previous variants used 19. -- [[ABC]]

RollingAverage is very important to SS. Perhaps because i use 97 bins (but i compensate it somehow marking the neighbour bins that are inside a circle of 36 diameter - bot dimension). 
I'm pretty sure that u all might already beeing doing this (but in case of not...), one thing that helps me to gather info is that i use the onHitByBullet AND the onBulletHitBullet event. In case you are not doing this yet, that can help also... -- [[Axe]]
* Ok, so now i think i've been thinking along the same lines as you here Axe, let me guess that the magic number 97 is because (1.2*Math.sin(8/11))/(botWidth/maxPossibleDistance))*2 = 97 bins?? Dammit, and i thought i was being original :) --[[Brainfade]]
* U got it right, that is the reason... I wanted a good resolution at bigger distances (that is important in my way of WaveSurfing) -- [[Axe]]

But now I am curious why Shadow doesn't need to decay the data to stay ahead of the GF targeters... I must be missing something obvious! -- [[PEZ]]
* Yep, that is strange (but you also don�t decay, u raise :) -- [[Axe]] 
* That's decay too, isn't it? Just not a rolling decay. -- [[PEZ]]
* Yes, just kidin�... -- [[Axe]]

How important, in terms of ranking points, would you guys say it is? -- [[ABC]]

For Pugilist about 70 points I think. -- [[PEZ]]

Can�t say for sure, but i think that about 25 pts for me... -- [[Axe]]

Wow, that's a lot. Maybe I'll try it again, now that I have a better movement control and gun. -- [[ABC]]

Yeah, your gun seems to top Pugilist's with some 5+ points. I'll have to work on that! I might over estimate the number of points the stat decay gives me. But it depends on the number of GF targeters I guess. -- [[PEZ]]

There's hope for 0.2.20 it seems. 1991 with 65 battles fought. Can still drop or rise a lot of course. But it's a sign! -- [[PEZ]]

Oh that would've been nice but I'm happy with 1940 for now! I can't believe that that famous Sandbox DT is number 8 now a days and that I have to beat it soon to advance further! Again many thanks to the wiki and you especially Pez. -- [[Pulsar]]

And now 1953 with 0.2.21! Isn't it nice when a few releases in a row raise the score? It's almost worth all those which drop. =) It's really 2 steps forward and 1 backward cycles for me at least. Can you share some more details on the velocity tweak of the latest version? Anything gaining 13 points gets my attention. Of course I understand if you want to keep the lid on it a while more too. -- [[PEZ]]

That's very much my feeling too!

I'm not a fan of open source in robocode but that's NOT due to me not wanting to share ideas. It's too easy to end up copying parts of the code etc. At least I feel I learn more if I read about the theory of for example wave surfing or guess factor targeting and then try and implement it myself. I got a feeling that my movment prediction wasn't all that great, dispite my efforts in the area. So I started some fundamental testing and had to remove the maxVelocity I use at times to try and confuse the enemy's targeting segmentations (deacceleration doesn't have to indicate that I'm going to reverse direction then). Tested by always going forward at 8 and predicting bullet impact location and always reversing on fire and predicting too and that both gave me near perfect predicted impact locations. So I wondered if the maxVelocity changes could screw up the predictions or not (still had no evidence that they were wrong though). So I turned them off and always used 8. Resulted in worse scores.... OK so the velocity changes were useful then. But I figured that 6 might not be enough to make me stay at those non top segments long enough. So I tried 5 too.
So to make a long story short. I changed max velocity changes to use 5 and 8 instead of 6 and 8. Quite an improvement for such as small change. Guess at 6 I didn't get down to the next segment for most robots or at least not that often/long enough. I'll try 4 next I guess :) Or maybe even more choices instead (8, 6, 4).

In other news my bot was never very fast, but nowadays I'm struggling along at around 80fps tops (2.8GHz P4, 1GB RAM, -Xmx512m. Quite a slowbot I guess. I'll look into it. Think at least a big part of it is the use of reflection. But I'm occasionally having out of memory problems at startup (beginning of round 1 that is, and if so all the following rounds). Haven't found the source yet. But I've just quickly glanced at the profiling information. -- [[Pulsar]]

Interesting. You have this really complex surfing system and you are starting to get it to work. Scary! -- [[PEZ]]

Scary indeed... Maybe too much scary... As i said before, WS is a nest of potential bugs... I still think that a good and simple WS (without segmentations and etc..) working with 98+% against HeadOns would be the best starting step (i did that way), but "When everyone is thinking the same way, no one is thinking"... 
I also think that i should not think that way about OpenSourcing... If someone "steal" your ideas or code, the one that is loosing is him, not u. No pain no gain, if he don�t suffer, he won�t be able to be as good as u. I think very much like [[ABC]], i like to do things by myself, and i doubt that there is someone in the top 20 that don�t think that way... RC isn�t static, even the most powerfull bot don�t last forever. In the end, the difference is made by your capacity and tenacity (that last one i have a lot). -- [[Axe]]
 
Totally agree. I'm not at all bothered by someone "stealing" my code (as long as it's done according to the rules I apply to each piece of code). I'm not bothered if someone just takes one of my bots and tweaks it a little and beat me. Actually I encourage anyone to do that. It'll show me where I can improve my bots. In the end I'm enjoying to see the whole Robocode thingy evolve. Inventors like [[Axe]], [[ABC]], [[Kawigi]], [[Paul]] and [[Vic]] and others are needed to cover white spots on the map. Followers and tweakers like me are needed too to push the findings towards their limits. =) -- [[PEZ]]

Don't get me wrong, I clearly see the advantages of open source especially regarding robocode, it is more I want to try out for myself first though and that's easier when you only share ideas and not source code I think. I could get tempted to use source code from somone else, it's hard to resist if you see something neat. So I try and not look at other people's source code for now either. When I figure I'm stuck or reached a certian level or something I'll most likely open soruce my bot and look more closely at other's source as well. That doesn't mean I'm only using my own stuff, I've stolen ideas from all over this wiki, and even including source code (FuturePosition). To be hoenst I couldn't resist the temptation to look at the master's source code fo course, and even glanced at some of Pez's, but no offense but don't like what I see. Too few classes and too many global variables etc. I know it's mainly due to codesize restrictions or inheritance from there and that 1vs1 doesn't require much organization of information. I'm concentrating on 1vs1 but my bot can handle melee as well, but there is no special tactics for melee for now. Too bad that robocode doesn't encourage more code structure I think, especially with it's intent of encouraging the learning of java. -- [[Pulsar]]

Heh, you're so right about Robocode encouraging bad practise.  I believe that there's none of my code since my days of CPM+ BASIC that's so bad as my bots. :)  The gun in RMX, for example, is just a more complex version of the one in RaikoMicro - even I can't modify it any more.  Complete BuildAndFix.  I'll reach for my RefactoringHat Real Soon Now, of course... -- [[Jamougha]]

I beg to differ. There's no such thing as "too few classes" I think. Granted, mini code, can be a bit too unstructured. But it's so little code in total at all so it's still more maintainable than many mors structured megabots. A mini almost never goes stale from lack of maintainability. And granted too, some of the tricks mini's use (like using a variable named "distance" (example from an old mini) for some other purposes as well, is not helping readability and clarity of the code. But Robocode is perfect for learning the lesson that for a simple task as shooting down an enemy bot there is no need for an excess of structure. With some bots I've unpacked that doesn't do all that much more than [[Aristocles]] does  it takes hours to figure out what's going on. It's delegation here and there and all sorts of funny stuff. Just to move and shoot. The important thing with the bot code is that it expresses what the bot does I think. To the bot author that is. If the author thinks in huge structures, then that is better. If the author thinks in patterns more like "gather data", "use data to shoot", "use data to move" than a structure like that is better for that bot. -- [[PEZ]]

I know what you mean - certainly having too few classes isn't necessaily a bad thing, after all you can write good code in C too ;-) and I've seen a few programs with too many classes to be even vaguely readable.  RMX, though, has a bunch of ugly warts in the code by virtue of having grown out of Raiko rather than been designed - but then, you can't go about robocode with a design document, and once something is working there's usually too much danger of breaking it to bother changing. :-\  Also, the minis and micros use a lot of idioms which are pretty clear and sensible to most robocoders but which would seem crazy to anyone else; like a C++ newbie coming across a statement like while(*p++ = *q++);. -- [[Jamougha]]

I really understand the both sides... [[PEZ]], [[Jamougha]] and others are master of minis, and for that purpose a good structured code won�t be appropriate (and neither fit in a mini). They really do miracles with so few bytes, and i have learned a lot of java looking at minis codes... I the other hand, if we talk about [[MegaBot]]s, this kind of practice is suicide, and there i disagree with [[Pulsar]], RC encourage a good structure as any other software, it is up to the designer decide what do he(or she - unfortunately we don�t have yet any she, but i pray every day for that day :) wants to do. 
PS1: I am not saying that my code is well structured, but at least i try to have something barely structured :) 
PS2: I have also to remember that super-structuration and by-the-book coding is one of the reasons of Swing be so heavy and slow... 
PS3: Where are that rc-girls afterall? -- [[Axe]]

----
1960 with 500+ battles! And a top-10 if you don't drop more than 5 points. Now maybe is a good time to just try plug the SilverFist gun in and see if you should maybe work with targeting a while. 2K club membership could be within easy reach if you currently have a lousy enough gun. =) (I'm not suggesting you should keep the .p gun, just use it once to calibrate.) -- [[PEZ]]

I'm tempted to try that indeed to see what is currently possible, just that I'm stubborn enough to want to improve the movement even more first, I still need to do that wall bouncing when close, or some version of that. But yes I will try. I'll see if I have some time tonight. Strange this, I always figured movement was boring and thought I was going to spend most of my time with the gun(s) at first! -- [[Pulsar]]
*1990 with that gun, guess I have around 30 points (simplified but roughly) to collect with the gun "some time in the future then"(tm). -- [[Pulsar]]
** With that same gun, RaikoMX.p collected 2004 points or something. Which means your bot with a RMX-class gun has some 70 points to collect with the current movement. Not that you really can add up points like this, but anyway. -- [[PEZ]]
*** Woha... Well RMX class-gun will take quite some time but it's at least nice to know that there is potential! Gun stuff is for 0.3.x though.

So you're a gun nut, eh? =) I think I should try work up some enthusiasm for gunning too. I just always have thought it more fun to work with movement. That "bounce when close" is nothing really necessary. I guess it depends some on how precise your surfing predictions gets at close ranges. Mine are always a bit sloppy and it gets worse at close ranges and thus I need to allow bouncing then. But RaikoMX manages without it and I wonder if [[Shadow]] isn't a "pure" surfer as well. -- [[PEZ]]

Well my other idea is to smooth away (if there is room) instead as now when I could possibly smooth into the enemy, most noticable against head on targeters where I can even run into them as I try to keep moving forward. -- [[Pulsar]]

Well, this is where a "pure" surfer would not do that because it can accurately avoid it by just surfing. But as I said, you need to have less sloppy predictions than I have at least for that. -- [[PEZ]]

How could a "pure" surfer avoid running into an enemy bot even if it has never been hit (doesn't really matter)? Some care need to be taken regarding minimum distance at least. And what I currently have to handle distance doesn't help enough, too small a direction chnage to keep distance that the wall smoothing totally overrides it. -- [[Pulsar]]

In general, if you're in the act of dive-bombing a bot then a small amount of flattening will catch that motion and make you reverse.  I get very occasional collisions at the start of the first round, but nothing much otherwise.  Bouncing - at least 'soft' bouncing, where you increase the danger weighting as you get closer - does help against simple guns, and I do that once I've detected a simple gun, but in general I've found that it decreases performance.  Of course [[Axe]] is the guy to ask about movement. :) -- [[Jamougha]]
*Fair enough, I'll give it a shot! Thanks again. -- [[Pulsar]]

What does a "pure" surfer do when there are no waves to surf? I think in general that it should try to go in the direction taking it farthest from the enemy. That would generally keep the bot from ramming the enemy, wouldn't it? -- [[PEZ]]

Sounds predictable to me though? -- [[Pulsar]]

Yup, that's what I try to do. That was one of the tweaks which pushed me over 2K, in fact.  Predictability isn't a big worry if the opponent hasn't starrted firing. :)  -- [[Jamougha]]

Good point! -- [[Pulsar]]

---

The next version will take even more time it seems, heavy refactoring is in progress and I'm trying to get have a stable middle step currently, but I'm failing miserbly. Movement only works for the first round or sometimes two and it shoots almost only head on now for some reason. Soo much for refactoring to minimize the amount of bugs (trying to reuse even more code all over and provide better support for gun experiments etc)

Score of 1983 without any gun experimenting at all and one or two bugs that I've found so far when refactoring in wave surfing, looks promising I think at least. 1990, SandboxDT and 2k will be done soon at least. Aiming higher :) --[[Pulsar]]

Hmm ok I expected it be be lower, but not that much, I obviously still have some bugs introduced in the refactoring. --[[Pulsar]]

Hey I just noticed one of your goals was to score higher than any minibot. All MegaBots should have that goal I think. Otherwise all those extra bytes are just fat and love handles. =) I can help in raising the bar a few rating points soon I think. I have 21 bytes free in [[Pugilist]]. Just need to sort out which of all changes made in CC from P that fits in 21 bytes and gives any extra points... -- [[PEZ]]

Well I geuss that's true! Well apart from maybe less code size tweaking and overall structure and readability. Though I know you say that you are careful with that [[PEZ]].

This stupid refactoring is killing me. I thought I was close to done now, but the score.. oh my, lost over 50points!

--[[Pulsar]]

Maybe you must roll it back. Make some unit tests asserting the behaviour of the old code and then refactor it ever so slowly from there. It's no fun I know, but I have been forced to do this at some points with CC too. -- [[PEZ]]

About readability and structure. If it doesn't bring home more points, then, what good is it anyway? Yes, I like to try make my code readable. But in both [[Pugilist]] and [[Aristocles]] I have been playing with the very last bytes and it has made me take quite ugly shortcuts. But as I said before, the code body is so small that I can still read and maintain my own code. Something that can't be said of all my MegaBots. =) -- [[PEZ]]

Well good variable names comes a long way on it's own and if it is a limited amount of code yes I agree. But I like structure, I rather have a util class or two, a gun class with some abstract classes for different guns and movements etc. Waves, enemy data etc are of course separate classes as well. Genral guess factoring stuff etc etc. Makes it easier to experiment and get back to understanding the source code after a break from it I think.

Guess I will have to do that soon, I'll try a thing or two first though I guess. It could be as simple as the gun not working well, I couldn't just refactor those so redid it and only have one simple gun now. Seems good enough against most low and middle ranked bots but rather bad against the better bots, maybe that's the only problem.
-- [[Pulsar]]

Yes, gunning is still important even in the surfing era. =) -- [[PEZ]]

Yes but 50points from a not so good gun to start with? I think it's something more. It's still a rather heavily  segmented  guessfactor gun after all. (maybe too much, but haven't seen much difference in performance by reducing segmentation). But haven't been too much effort put into it. -- [[Pulsar]]

Well, I did a rather small change to Pugilist's gun resulting in 30 points gain. A less worked through gun could have even bigger losses or gains I guess. -- [[PEZ]]

Aah ok, could very well be that then, I'll give it (more gun stuff) a try one of these days. --[[Pulsar]]

Your LRP graph suggests you can still tune that surfing a few notches. Do you have any unsegmented stats for fast learning weighed in? If not that would probably give you quite a few rating points. -- [[PEZ]]

But misunderstand me correctly. The graph shows a bot with working surfing I think. I don't think you have any real big issues there. Just tweaking and tuning. The life of a robocoder. =) -- [[PEZ]]

Yup unsegmented as well as flattener. Flattener added a few versions ago, now only used when I've been hit moving constantly forward similar to the Musashi trick. -- [[Pulsar]]

OK, and how do you weigh the flattener, the unsegmented data and the segmented data? What do you segment on btw? -- [[PEZ]]

Well the weighting is controlled by a settings class so trying different things (but not dynamically), mainly between 0.1-0.5 for the flattener (if active). Non seg 1 and seg 1. Rolling averages with a really low number of samples for nonseg and segmented data. And somewhat more samples on the visits (flattener). Not using the actual number of visists/hits for the samples though, just a constant, for now (still doing the basics). Non-seg returns the max value when calculating the value for the gf index if that index was the last hit, regardless. Segmenting on different things for different versions. It's easy enough to change around. For the wave surfing there is usually a mix between distance or bullet travel time, lateral velocity (figure I mostly move lateral anyway) or velocity, acc, wall. So rather simple stuff I guess,s eems to work rather well.

Just tested with the CC gun some yesterday. Then I had no troubling winning against most bots (including, RaikoMX, Shiva, Aleph etc). Silversurfer, cc, and shadow still won with a few hundred points. So I guess the conclusion is that I need slightly more movement tweaking but most of all some serious time spent on guns. When I tested with the Bee I couldn't help but notice how simple and uncomplicated it seemed overall, I'm amazed, well done! Lots of interesting details there I bet. Nice way of getting around the dynamic data segmentation I think too?

For my current gun, I've tried a few things, but it's based on the same GF utils as the surfing now (so yes rolling averages etc, but controlled with different settings for weigting and samples etc. The segmentation I've quickly tried there (not all at once, but almost in some versions) is distance, flight time, acc, velocity, lateral velocity, wall, advancing velocity, time since de accel (read somewhere that that was a good one). But I'm not sure I've gotten the implmentation right for all segmentations yet. Not using unseg in targeting at all. No dynamic data segmentation at all yet.
But that means I still have a bunch of segmentations that I played with in the 0.2-series that I haven't refactored yet.
-- [[Pulsar]]

Rolling averages for the gun might not be the best thing, I didn't have that in 0.2 series so maybe I should figure out a way of testing without that first. But as I'm playing around with totally different number of samples and weighting then it could possibly work anyway I figured. -- [[Pulsar]]

I think you could try with weighing unsegmented data 0.5 in your movement. I have tried diefferent weights, and 1.0 isn't the best one. I don't use the actual visit-counts either. At least not in CC.

For the gun i guess if you roll it very slowly you'll get the same effect as doing it non-rolled. But the most important aspects lie in firing waves every tick (now that you segment quite heavily that is). Advancing velocity seems to kill my guns performance, but it might just be a faulty implementation. Protecting the gun stats from contamination is also important. (I tend to either segment on bullet power or not collect data on energy managed fire.) My home brew of dynamic segmentation I only added some versions ago. Gained me 5 points or so, nothing major. (I'm ot sure my reasoning behind it holds, but since it gained me some points I'm keeping it for now.) But it must be some other details keeping your gun back. Cool that you liked the simplicity of my gun. It must be simple since it's the gun from a micro to begin with. I bet I could plug in [[Aristocles]] gun unchanged without losing too many rating points. GF gunning is as delicate as surfing almost. It's the nitty-gritty details that counts. It's very easy to feed the wrong bullet power or the like and still get reasonable performance. That's the trap I think. I would say a visit count based GF gun like Bee that doesn't collect 90 points in the TC is broken or badly segmented.

-- [[PEZ]]

Ok thanks again, will try that with the movement. I'm not too concerned with the exact numbers for now as long as they work decently. I'll just run some (well quite a few) roboleague matches with different permutations of a lot of settings later and see what works and what not.

Targeting, the advancing velcoty segment helped with Tron I think, as it should I guess if I use lateral velocity.  But I will give everything a shot :) For targeting I use waves fired every tick (but not for wave surfing for now). Energy managed it is, in a simple way, but filtered away with segmentation, but just very basic, my energy below 12 or the enemy's energy below 12 (so three segments, rather bad when not using and across segmenation/dynamic segmentation, but was the quick way of doing it). And constant bullet power or same bullet power for the same distance segment.

-- [[Pulsar]]

That should be enough stat buffer protection I think. As for weighing of unsegmented data. I view the unsegmented data as necessary only for when I have no data in the segmented buffer. Once I have segmented stats I want it to take command and the way to do it is to weigh down the unsegmented data. You can do a very simple test with this. Run 250 battles against DevilFISH with each different sets of weights. It should quickly be evident which one works best. -- [[PEZ]]

My gun is just a big failure as it is now. Something is terribly wrong as I can't get close to my 0.2.35 performance (score 1982) and I can't figure out why for now. I'll release a version with the Bee and after that, with your permission PEZ, I'll try and implement that gun using my structure and utils just to see where my bugs are. Then after that I can start over with guns of my own! -- [[Pulsar]]
* I have gone through this as well. It is a lonely and frustrating feeling. If you have any versioning control, roll back to your last know good gun and run a TargetingChallenge with 100 rounds instead of 500's. Then roll forward until you find the break. If you do not have versioning control, you can try using some decompiler on your own code to find the break. Absent all of that, you have to start again :(. I would highly recommend that you add some versioning control if that is the case though. CVS is free and available from many places. It also integrates nicely with Eclipse if you use that IDE. Shout if you need help or encouragement. --[[jim]]
** Thanks jim! I'm to lazy to CVS this right now but I'm saving every version source separately anyway. The big problem is the major refactoring I did from 0.2.x to 0.3.x. I'm confident that I sooner or later will get the guns to work again and I'm reluctant to go back to the old structure, I like the new one :) --[[Pulsar]]
*** CVS effort now will be greatly rewarded down the road. It has saved me more than once. Good luck with your bug hunting though. It is frustrating and tedious work. You are so familiar with the code you end up "reading" what you expect to see and not whats actually written in the file. At least thats how it works for me. -- [[jim]]
**** Thanks! Oh yes that's exactly the way it works :) I'll install CVS sooner or later. Using tortoise CVS as the client right now for other stuff. Just don't have my own CVS server right now.

Well, you don't need my permission of course. But you have it anyway. =) -- [[PEZ]]

----
Pulsar, your bot seems to be one of the most slowest bots... SilverSurfer looks very light comparing to PulsarMax, and SS ain�t nothing light... Maybe you are loosing lots of rounds, and that�s keeping u away from improving your WaveSurfing... Had u try to count how many rounds u might be loosing? -- [[Axe]]  
 
I echo this thought. Does PulsarMax qualify for as a SlowBot? -- [[jim]]

* If I qualify SS as a SlowBot... But seems that the bee series with PEZ�s cannon lightened a lot PulsarMax... Think that the more heavier now is vic�s [[Locke]]. -- [[Axe]]
* Yeah, [[Locke]] has been slow since the 0.6 branch. The framerate is not too bad, but after each round there is a very expensive rebalancing of the log. This is mostly solved in 0.6.8.4, where I only do that rebalancing after each of the first 6 rounds. [[Locke]] will never be lightning fast due to the design with a searchable log, but performance up to par with most patternmatchers should be possible. --[[Vic]]

I'm sorry, I've had other concerns than too look too much into this. It could be but as long as I don't use my verbose mode I rarely skip turns (always less than ten total in a 35 round match I think). It shouldn't vary by computer I guess but who knows. A version or two back I almost doubled (well over 50% at least) the performance. And yes the bee version is even faster. Still quite slow though. I'll look into it and see if there is anything obvious. --[[Pulsar]]

It's hard to make a surfer that's not a bit slow I think. At least if you want to make surfing decisions every turn. But the Bee cannon should at least be very fast, which isn't too surprising considering how few things are going on there. -- [[PEZ]]

----
It was decided yesterday that I will leave for the states on monday (work) for a month or more, so will probably be awhile before any updates will take place. I'll bring the source for the robot but I doubt I will ahve much time for that. I'll remove the bee version from the list now. But hopefully I will at least be able to check the wiki regularly too see the progress made and check everyone's impressive efforts! CC for example looks very promising lately! -- [[Pulsar]]
* Where are you going to? It is a big place but maybe we can get together if you are anywhere near Washington, DC. -- [[jim]]
** That would be great. Not too far off, but still not close. Two places: Greensboro, NC and Chesepeke, VA (Norfolk). I should visit PEZ the next time I'm going to Stockholm too ;-). -- [[Pulsar]]
*** Norfolk is not too far away. It would be a whole day committed to driving both ways though so I think we will just have to settle with being in the same state. :( I hope you enjoy your time here though. Norfolk is beautiful down near the bay. 
** Indeed you should! Where in Sweden are you living? -- [[PEZ]]
*** Goteborg --[[Pulsar]]

Ah, too bad. I was hoping for some PulsarMax releases now. Well, stay tuned. Because I will pass RMX or perish trying. =) -- [[PEZ]]

Debugged quite a few things and found some "interesting" stuff, no time to fix it all now though, but I've made some notes that I can hopefully decipher later on! I've been too generic (common problem for me :) ) with some things, regarding waves but most of all the data storage of my and the enemies' stats, especially when comparing a current value with the previous value (fetch from storage with time and time-1 would usually give the time-1 values for both). Looks nice though :) Found some various other bugs too. No idea of the impact this all have had yet. Most of it is stuff introduced in the refactoring for 0.3. I've got hope again! :) --[[Pulsar]]

I'm amazed yet again. A wall index which returned random numbers basically. Lastvelocity/lastx/lasty/lastEverything values that in were the same as the current one or if that was correct then returned a 4ticks old value if even that. And a bunch of other minor things fixed. Gained me 8points only :) --[[Pulsar]]

That's odd. The wall-index, was that for your movement? My experience with wall segmentation for the movement show that it can help against some enemies, but it slows down learning in general so it lowers my rating. Do you use any direct acceleration segmentation? You should really gain more than 8 points from fixing those lastEverything measures. I think you still have huge bugs lurking. -- [[PEZ]]

Oh yes some interesting bugs yet to be found :) Wall index was for both movement and targeting. Just made a quick test earlier and removed the wall segmentation for wave surfing and that made it worse. But I will try it again against more enemies then, thanks! For wave surfing I use the sign of the acceleration and usually for the targeting too or similar for lateral acceleration. So all those should have been wrong before the fix. --[[Pulsar]]

Well allow me to change that a bit, my experience so far with Robocode is that there is rarely one big bug but a few medium/smaller ones! --[[Pulsar]]

That's if you consider getting the current velocity when you ask for the last ticks velocity anything else than a huge bug I guess. =) -- [[PEZ]]

Eahm, good point :) -- [[Pulsar]]
----
Is it just me or is this bot sllllloooooowwwwwwwwww? It drags my RR@H client to a crawl. -- [[jim]]

It's not just you I'm afraid. I'm back in sweden since today (well yesterday now I guess...) and have vacation for 3weeks, a few hours will be used for robocoding hopefully, part of it optimizing the wave surfing code, which makes this one slow... well targeting is not far behind either :-(
Performance hint for everyone by the way: use the server jvm if you aren't already (will be slower the first few rounds but quicker after that). -- [[Pulsar]]

To compensate I usually run the RR@H client on three different machines at the same time here, so every time I update the bot it should be fairly quick anyway. -- [[Pulsar]]

I just came down to see that my client had stopped with an OutOfMemoryError on a PulsarMax round. Have you noticed this before? -- [[jim]]

No but I've seen the same thing here now, third time, can't remember what robots were involved before but this time it was wiki.rrgc.ResinRRGC 0.2 vs kawigi.robot.Girl so not PulsarMax in that round at least. And again just now: wiki.rrgc.ResinRRGC 0.2,dz.Caedo 1.4 . So Resin perhaps? Edit: again Resin  match caused an out of memory for me... -- [[Pulsar]]

Yes, it could be. I think there might be a bug in [[Resin]] where it drains all memory from the machine in one big slurp. Can't see it though. All loops seem tight...  But I'll remove Resin anyway and see if I can sort it out. -- [[PEZ]]

----
Hmm my wavesurfing has broken reverse predication it seems. Look at it against some simple head on targeters and when it is getting close to a wall and the wave surfing forward predicts it will end up too close to GF0 and it therfore reverses (or some reason like that) it, not too rarely, gets hit. Ouch. Well I guess that is good news for me :) -- [[Pulsar]]

Yeah, it looks a little worse than it does for CC. Is that you bounce walls even when you're not quite close? It looks a bit like you do. If you don't eveluate the stop-position yet, maybe that can help. Like if your wall bouncing kicks in and makes reverse and forward destinations about the same, then maybe the stop-position could be a better choice. Doesn't really work 100% for me, but it's how my bot works in theory... -- [[PEZ]]

Thanks for looking at it! I never bounce I let the wave surfing together with the wall smoothing handle that. What could effect it though is the distance keeping (trying to stay just above 500 for now) and the modifier that tries to keep it at that distance. Playing with it, but at 150 or 200 or so distance it is trying to move away at a 30-45 degree angle and then less and less the closer it gets to the desired distance setting.
I still have over 30points to collect with the gun compared to the Bee (some version) but can't stop thinking about the movement now. I'm supposed to be a gun-addict!! :) -- [[Pulsar]]

Hmmm, maybe I could do something like that too... Never thought about it that way actually. Tis like smoothing backwards. Anyway, Does you eveluation destinations take wall smoothing into account? In my case I let the wall smoothing decide what destination coordinates to evaluate. That should, in theory, make my predictions accurate also near walls. I know everything about getting stuck in the "movement-swamp" (maybe it's OK with Swenglish since you're a Swede. =) -- [[PEZ]]

Hmm when you say stop position do you mean velocity 0? I predict using velocity 3, 5 and 8. If memory serves including vel 0 made the scores worse, but could possibly include it if near a wall maybe (or use 8, 4 and 0 or so, migth have been the number of velocities other than the max velocities that was the problem). Or do you mean something else? -- [[Pulsar]]

With stop-postion I mean the position you'd reach if you stepped on the brake pedal. I do a quite sloppy evaluation of this:
<pre>
	MovementWave.dangerStop += wave.danger(project(robotLocation, robot.getHeadingRadians(), robot.getVelocity() * 1.5));
</pre>

Ahh about the same thing then. I predict future guess factor indexes for the different velocities at bullet intercept time (iterated) including wall smoothing. At least forward position predictions seem to be near perfect. Only few pixels wrong the further away the bullet is, as the enemy is moving a lot then (I'm circling the enemy). Reverse is a bit harder to test but I tried to test by changing my movement to always reverse direction when the enemy fired and it seemed almost as good but not as easy to test. Think I will try and find some time to debug this in action and see what the different values evaluate to when this happens. -- [[Pulsar]]

OK, so now I've looked a bit more on PM vs HawkOnFire. You do take some strange and unecessary hits. At first I thought it was only in the beginning of the match, indicating you could improve stuff by pre-initializing your movement stats with head-on hits. But it looks like you take those strange hits even later in the match. I'm not up-to-date with the features of PM so bear with me... Do you take care not to dodge "phantom" waves and not miss real waves by applying [[Kuuran]]'s advice on the EnergyDrop page? I doubt this is the source, since I only very recently applied that stuff and didn't before take hits from HawkOnFire like PM does. Worth looking in to anyway. Are you using a fast-learning buffer to immediately start avoiding simple guns? I guess you have, just checking. I agree this problem is probably good news for you. You're close to 2K and have a visible bug to fix. I wish I had that too. =) -- [[PEZ]]

I noticed the new stuff on the energy drop page but haven't applied it yet no. I start off by avoiding head on targeting by setting the flattener weighting to 0 when it looks like I'm up against a head on targeter but also in addition to the rolling averages for the wave surfing (only using waves fired when the enemy fired for now) I override the evaluted value and set it to the max for the last hit gf index when returning it for wave surfing evaluation. This last hit index is set to GF0 at the start. So that seems good enough to me, hence I believe that I have a bug :) 0.3.20 changes the no waves to surf situation from move the farthest away possible to simulate a fired wave when the enemy gun heat indicates it could fire and other small things :) Maybe I should use that check rigth before adding an enemy wave in general too. Well as you said I doubt that is the case. Could be tested or checked with roboGL I guess.  But I'm not using a fast learning buffer for wave surfing I think it's fast enough anyway as it is now, with a gun like yours it ended up at a score of 2022 at least (for version 0.3.10). Again thanks for all the feedback! -- [[Pulsar]]

When I added a quick learning buffer to DH it made a 20 point or so difference in it's performance. I used an unsegments array of GuessFactors I was hit at. GF 0 was incremented +=1 every time I was hit as was the GF I was hit at. I then divided the predicted GF by GF 0 and added that into the rolling buffer. The hope is that this number will become smaller and smaller over time and thus not as significant. It seems to work although I can not get over the 2020 hump so take it with a grain of salt. I also echo [[PEZ]]'s comments above about allowing my movement algorithm to choose my wall smoothed destination for prediction on the impact GuessFactor. It seems to work fairly well. I would suggest you look at what movement segments you are using as I removed one of mine and it improved it vs some bots and lessened it against others. This suggests to me that there are lessons to be learned there. - [[jim]]

Ooh you are right, stupid me, I use a non-segmented thing as well. weighting right now is [1, 0.5, 0.6] for segmented,non-segmented and flattener (fully segmented but includes waves fired all turns). Sorry for the confusion, I was mixing up versions. Flattener disabled against head on targeters though. The last hit index set to max value should take care of most of that fast adoptation I think. I'm not looking to improve my wave surfing in general right now (for later, in versions 0.4.x) but I would like to fix this bug about sometimes being hit by head on targeters! Though what kind of weighting do you use for the different segmented and nonseg etc? -- [[Pulsar]]

That's all well then. Though I weigh fast learning (non-segmented) higher than the flattener. [1, 0.6, 0.45] to be exact. I too disable the flattener agains head-on. Or, rather, against simple fire. No point in flattening against any fixed-GF targeters, is there? -- [[PEZ]]

Interesting with the fixed-GF targeters, but let's say a linear or a circular targeter, as you vary your speed etc when using the normal max escape angle formula, don't account for turning etc. Or would some segment make sure this is always the same, hmm possibly... Or how do you detect those? It's on my todo list to detect those but then more advanced than analyzing the guess factor array only and see if they are close to one spot, which it sounds like you are doing, or? I was thinking of doing the actual linear and circular targeting for the enemy and see if it is within some margin of those or instead of max escape angle use linear and circular (in addition to the current one), with some modifications. I've done that in the past with a pre PulsarMax bot with some success but wasn't segmenting on anything other than distance though... --[[Pulsar]]

You must be mistaking me for a rocket scientist. =) I have toyed with the idea of analysing the non-segmented array to see if the hits are grouped together, but I am doing a much simpler thing now. I start out without flattening and if the the enemy can't hit me very well then I keep it off. Otherwise I switch it on. -- [[PEZ]]

Well to me you are, everyone at close to 2050 score and more is a rocket scientist to me :). In your case you it's more so due to simple elegance IMO. First time I looked at CC source code, to use the Bee gun in testing with PM version 0.3.10, I was so surprised. So little code in there and it works so well :) I'll try the doomed rocket scientist way one of these days. That's the problem using the theoretically better/more exact stuff, takes too much time, gives too little, if anything, back and makes it all too complicated... I love and hate it... :-) Hmm first thing now though: to find this stupid bug with head on targeters... -- [[Pulsar]]
----
It's a little early but you are over 2K after 370+ battles. I am pulling for you. I will start my client here in a bit so you will get some more battles. Hold tough PM. We need another 2K bot. -- [[jim]]

Hehe, thanks!! -- [[Pulsar]]

1999.82 with 502 battles :) A later version it seems! -- [[Pulsar]]

You spoke too soon! I have a screen capture of 2000.08 after 504. Would you like? Congrats! -- [[jim]]

Hahahaha, indeed even 2000.61 after 521 :) Thanks, many thanks to all of you on this wiki! Now I'm still puzzled what caused this increase in score though, I know I made it worse against rammers with a simple misstake there at least. -- [[Pulsar]]

What did you change? It is suprising how subtle the difference is between a top competitor and an also ran. Also, why aren't you on IM? It would have been fun to chat while watching to see your bot climb. We could have both cracked open a cold beer and sat around the virtual bar =^) -- [[jim]]

Hahaha I would have loved that! Didn't know we had an IM-info page somewhere?! Thanks [[jim]] and many thanks to the others here on the wiki again, especially [[PEZ]] and his feedback which makes me keep trying! Added the changes I did to the version list above. Lesser steep evasion when keeping distance, enemy faked waves when no waves to surf and wave surfing evaluation for guess factors now constant instead of sqrt (pow=1 instead of pow=0.5). --[[Pulsar]]

You mean your BinSmoothing is now linear? I think I have tried that too, but it was long ago. Think it helped your rating? How many bins do you use? -- [[PEZ]]

Yup I meant linear (for wave surfing). I'm fairly sure it helped about 6-9points from the previous versions testing. I use 27 bins for wave surfing. I figure it can depend on a lot of things though, like evaluating for multiple velocities etc. It helped with Tron 2.02 for sure. -- [[Pulsar]]

Seems I managed to improve [[Pugilist]] in time. =) Congrats on making a more stable entry into the 2K club! Maybe it's time for you to start working on your weaponary? -- [[PEZ]]
* Oh yes you did, hehe. I tried to use ++ etc instead of rolling averages (samples 10 right now) for gunning but didn't seem to improve (didn't release it for the rumble though). I'm not out of ideas though, but I was quite surprised by that. -- [[Pulsar]]
* Depending on implementation the values used for rolling averages or simple incrementations are very important. At least that's what my latest experiments tell me. If I in CC use 1.0, 1,0 and 0.45 for weighing my hit and flattener stats (using rolling averages) I get very different results than if I use the weights 100.0, 100.0 and 45.0. (The latter is much better.) This led me to try initialize [[Pugilist]]'s enemy hit counter to 50 and it gained me 7+ points in general rumble rating. Food for thought and there might lurk some easy points for you to collect there. -- [[PEZ]]
* Hmm yeah noticed the djungle here too. Wave surfing: Using weight 5 in the rolling averages formula (samples 3*5=15) is better than weight 1 and samples (3*1=3). No idea what to think about this yet! The number of samples makes a huge difference as well both in targeting and otherwise of course, set number or the actual number of samples optionally up to a certain limit etc etc etc. Thanks I will try and initilize everything to the middle value then (I'm using 0-100). When you say hit counter what do you mean exactly? Surfing? Gun? Real hits, virtual hits? All buffers? -- [[Pulsar]]
* I'm talking about surfing stats only. (Missed that you were taling about gunnery.) I think it might be due to the smoothing that the "size" of the values used for rolling averages are important. A "hit counter" is what I use in Pugilist to update my movement stats with. Each time I'm hit I increment the hit counter and use that new value to update my stat buffer. It's my home grown way of doing byte cheap stat decay. The decay seemed important in my tests. But now I am beginning to think that it was the rapid growth of the values used in the stat buffer that is important. More tests to follow. I've said it before, but let's say it again. ''I've never ever seen BinSmoothing help a stat gun.'' -- [[PEZ]]
* Hmm I use the same utility functions for both surfing and targeting, but the smoothing etc is parameters. Currently I use bot size smoothing (a hit covers multiple guess factors) for both wave surfing and targeting, but linear decline and for just those that fit the bot size at this distance. For wave surfing I also smooth with a linear factor when reading, no such thing with targeting. (and sqrt for time to hit). I'll test some (more) I guess, thanks!-- [[Pulsar]]
* First thing for you to try is then to remove the bot-width smoothing for the gun. It'll be interesting to know if you'll provide the first case were bin smoothing helps a stat gun. -- [[PEZ]]
Congratulations on joining the The2000Club! btw, I just noticed that [[Paul Evans|he]] dropped out of the top 10! Isn't that amazing! I wonder if he will ever come back with SandboxST (Surf This!) and put you all at The2000club back in your place. --[[Vic]]

Thanks. Yes, can't believe that, amazing! -- [[Pulsar]]

----
OK. I hate to do this to you [[Pulsar]] but this is the SLOWEST bot I have ever tested against. I can see now why you have so much time on your hands to work on PulsarNano. What takes this bot so long to process? I mean a slow bot has it's advantages (I will never test vs it again :P) but it has to be hell to test and verify that it works. FYI: I am getting less than 60 FPS minimized when running your bot. I do not think that CigaretBH is that slow. -- [[jim]]

Yes I know and I'm sorry, haven't timed the different parts lately, but runs at 150fps or so for me (2.8GHz P4). Use the -server option, gives a slight increase (after a few rounds). Surfing every bullet and evaluating for 3 different speeds probably is one reason for it running slow... I'm constantly speeding it up though, believe it or not... --[[Pulsar]]

PM 0.4.14 is good. The LRP graph seems to indicate the surfing is very good even. But the gun defeats you against the stronger bots probably. Like if your movement is as good or even slightly better than theirs, you have to have a gun on par or even better than they have. I think. I might be making the wrong conclusions. (I due that now and then. =)  -- [[PEZ]]

You are probably right. As soon as I moved away rom the rolling averages (0.4.13 and 0.4.14 are enot using them) my score against the stronger bots got quite a bit worse. But I'm experimenting with the segmentations now. But even with the Bee gun I didn't get more than 2027 (maybe a few more points are possble with the Bee now with the small movements tweaks done since then, but not much) so still some work to do with the movement too, but hopefully not much needed against the stronger bots. The current goal is to get above 2020-25 something with gun tweaks alone and after that improve the non-top bots movement some. Then it's time for REAL experimenting :)

Well, to contradict myself, becoming stronger against surfers might actually mean you have impaired the gun. Both [[Jam]] and I have released surfer-killers which have gotten that power because of bugs in the gun. Still, when two bots meet where both have good guns and equally good movements, the one with the best gun wins I think, surfers or not. -- [[PEZ]]

Summary:
Consciousness check: 4 + 9 =
This change is a minor edit. Send email notification that PulsarMax/OldChatSummer2004 has been changed.
(Visit Preferences to set your user name.)

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