[Home]WaveSurfing/Archive20070511

Robo Home | WaveSurfing | Changes | Preferences | AllPages

Archive from 5/11/2007

A hack implementation of WaveSurfing

As per PEZ request, here's a description of how my AM works in RaikoMX 0.2. Try not to burst out laughing too much.

Essentially; collect enemy firing data as in Narcissus, using EnemyWaves. I collect both statistics on my overall movement profile, with a wave fired every turn, and on where the opponent has been firing recently. Segmentation is as in FloodMini, since it's by far the most influential GuessFactorTargeting bot around.

Now, each tick I look through a vector of the waves which were fired on a turn when the enemy fired, and find the closest one which has not yet passed me. This represents the bullet I'm trying to dodge - I only dodge one at a time.

In order to make my movement more predictable (to me) I orbit around the location the bullet was fired from until it passes, or another once becomes closer. From here I just need to simulate my forward movement until the bullet passes - however, there's an ugly way of avoiding doing this hard work.

The max angle which I can travel in the time it takes a bullet to reach me is well known, Math.asin(8/bulletVelocity). If the bullet has traveled 2/3 of the way from the target to me then I can't get as far from my current position - only Math.asin(8/bulletVelocity)/3. So, I measure the distance the bullet has left to travel and it's total travel length, both to my current location. Then, I assume that going forward will get me to my current guess factor + bearingDirection*zeroGuessFactor*distLeft/totalDist. This is pretty accurate at constant velocity when clear of the walls. I assume that turning will bring my to exactly my current guess factor, since it takes ~12 ticks to turn and get back to the same place and a bullet is fired ~every 15 ticks.

I then get a goodness function for each of those guess factors. This is calculated as the sum of the values of the guess factors and hit factors divided by the square root of their distance from the guess factor I expect to end up in. This gives me a nice fudge factor, so I avoid general areas rather than trying to weave in between bullets.

Finally I set my direction of circling to +/-bearingDirection based on the results. If I meet a wall I bounce, without worrying about flatness.

And that, basically, is that. :-) Nothing fancy, and I'll probably squeeze it into Raiko later on.

-- Jamougha


I've always wanted to try this with Shrapnel dodging. Maybe i'll wait for someone to release some of the math/logic of figuring out which factors you've traveled to. =) -- Scoob

Scoob, see Narcissus for an open-source implementation of EnemyWaves. It only requires a couple of minor changes to work out which guess factors you've been hit at.

It is a pretty cool name. :-) I'm working on my own system currently - it scores close to 80% against FloodMini, but doesn't do much better than that against ratosh.Wesco. :-\ I may be the first person to release an adaptive-movement bot complete with the MusashiTrick. :p -- Jamougha

The name is cool, ain't? I expect that my implementation correspond to how it sounds, the only reason for this not happen would be this one that is writing... Good names a part, i think that Aleph had already implemed something very similar... Just see the score against Barracuda! Last time i saw was something near 98%, if WaveSurfing is well implemented, i think that there is no reason to not beating HeadOnTargeting bots by near 100%. -- Axe

Yup, all you need to do is know your exact forward position. Oh whoops... anyhow, RaikoMX 0.2 is out. You'll be ROTFLYAO when you see what I did, and I don't think it's the way forward, but we'll see about 0.3. :-) -- Jamougha

Well, the secret is out in OpenSource bot RaikoMX!!!!!!!!!!! That's about how I was going to do it. Surf on! -- PEZ

RaikoMX is the 4th. 1950+ bot! That 2K barrier is going thinner and thinner... With all those paralel implementations of WaveSurfing, i predict that within 10 days we will have about 10 bots above 1950 (3 different versions from PEZ, as usual :)). -- Axe

Within 10 days? Not even I would be able to do that. But expect Pugilist to join the 1950+ club in that time frame. Everything else would make me hugely dissapointed. -- PEZ

As the first person to describe how WaveSurfing is done I say that Jamougha should write the start of the serious part of this page. That'll take him some time too so I can stand a chance to catch up. =) -- PEZ


"however, there's an ugly way of avoiding doing this hard work." Don't put yourself down. That's not ugly, it's simple. And simple means elegant. Well done! You know, I think even I could get a working implentation of that eventually, thanks!! (Only the best people can think of obvious ideas. :-)) -- Tango

I don't know how FloodMini is the most influential GuessFactorTargeting bot around, I tend to think that SandboxDT gets that distinction no matter how you think about it. -- Kawigi

Tango, well, *scratches chin* it's a functional way of doing it in a mini, which is partly what I was aiming for, but it's not effective against low-ranked bots. Scores like 77% against FloodNano and 83% against Barracuda (not to pick on Kawigi :p) aren't acceptable if you want to climb to the top; my LRP graph is currently almost flat. Partially this is due to the current balance between dodging fire and flattening, but it's going to take real simulation of my forward movement to pick up some 98% scores and climb past 2K. However RMX scores about as well as Shadow and DT against most GFT bots, so it's promising. :-)

Kawigi, don't sell yourself short. :-) DT has inspired many people to use guess factor guns, but in terms of implementation an awful lot bots are derived from FloodMini, at least conceptually. Eventually I may fit multiple enemy guns and try to work out which best corresponds to what they're using, but assuming everyone is FloodMini works fairly well. -- Jamougha

I so totally agree. DT might have proved how effective GuessFactorTargeting is, but until FloodMini it was pretty tough to figure out a simple way of doing it. Silly me had been using Wave based statistical aiming for quite a while, but never understood how close I was to GFT. Enter FloodMini. OpenSource and KISS. I love you for it Kawigi. No bot has influenced my Robocoding like FloodMini I tell you. -- PEZ

As the first proposing the WaveSurfing term (at least i think...), just added the general definition. Agree u all? Need help with english surfer terms, like peak, we call it here "crista"... Hang-loose (here is an example:) -- Axe

To get get a nice picture about WaveSurfing. run DuelistMicroGL? and surf this waves (see here RobocodeGLV014) :) -- rozu

Well, I suppose out of necessity more people use code from FloodMini than SandboxDT or SandboxLump, even though SandboxMini has been there (which was Jim's starting point for Jekyl). I think FloodMini may have just happened to come at a time when minibots were taken seriously, and with version 1.3 and 1.4, it specifically was taken seriously. The FloodMovement I think changed a lot of peoples' outlooks on movement, or at least refocused it on not letting any shot bearing be better than another. I think that in the end, though, it was a quick detour on the way to more practically sound movement like Raiko's. If FloodMini is really that influential in targeting, it is either because I hacked together a grapher for it one day for debugging purposes and Jim conned me into giving it to him, or because it just happened to show impressive TC scores when we started doing that, one open-source bot sitting between all the super-secret bots like SandboxDT, Tron, and CigaretST. I had started to suspect a little before that that FloodMini's gun was better than its movement, which was a revelation because it was originally written for the sake of its movement. Improving targeting, though, was more deterministic than improving the movement, so it progressed while the movement might have even peaked around 1.2 or so. So I guess that I would tend to take credit for the use of setMaxVelocity? before I'd take credit for wave implementations of GuessFactor guns.

One targeting idea I maybe could take credit for was more creative segmentation of a guess-factor gun. If people did it before, they didn't try very hard or they didn't publicize what they were doing as far as I knew. -- Kawigi

Publizising is the key here. For me the performance of your gun had little to do with it influencing me. I had read the SandBoxMini? code several times and never understood a thing. With FloodMini the implementation was so obvious. I think I said "Aha!" out loud when I read the code. It really was the simplicity of the implemenation. (Mind you I even understood it despite the heavy code shrinking obfuscation in there.) The segmentations I had done myself with my other lousy targeting methods before. =) -- PEZ


Does this really make a big difference? Because you have to assume how the enemy segments his data, which varies by each bot. --Mike

I assume you are referring to the pages topic. =) It doesn't matter all that much how the enemy segments its data. Although heavy segmentation might help. And against many implementations PatternMathing? seems to help too. -- PEZ

The point is seeing where your enemy tends to shoot in a given situation. Similar to GF targeting which is seeing where your enemy tends to go in a given situation. The situation is defined by the segments, but if your definition of the situation is more specific than your opponent's it doesn't really matter, because you'll still include all their situations and in a given situation they'll behave the same way (ex: if they don't segment on acceleration then you'll simply have the same value in all the acceleration bins, but it will still be the valid value). Going the other way is a bit iffier, but because it's all measures of tendency even if your enemy segments in ways you don't know about you're going to see how they tend to shoot in a given situation as defined by you. A little bit of error will be the result of not knowing which additional segments you're in, but since these methods are all approximate and your enemy's targeting data will often change it doesn't matter a whole lot. You're still defining a pretty specific situation with four segments, if they have two more they've got a minute advantage on you, they'll still tend to shoot the same way when the four segments you know about are the same, and the further segments will likely show as additional peaks which you'll also be avoiding. Just think of it like this: before people moved based on guess factors stat guns still worked because they measured where people were likely to end up going. This movement measures where you're likely to end up shooting no matter how you decide that. -- Kuuran

If you're good at this surfing thing you won't get hit, but if you don't get hit your statistics will degrade (because the only way to get that data is by getting hit, no?), so you'll get hit again ... looks unstable to me. -- FnH

A possible Anti-surfing gun: take a regular GF-gun and every time you hit the enemy, delete or 'age' the data in the bin/segment you used to fire. This will make sure the surf-bot has wrong data about you and you're learning speed for that segment/bin will be higher adapting as fast as possible to the enemy's reaction. -- FnH

So you score a lot (maybe..) against these bots. And what about the others? -- Axe

Virtual guns would be necessary. Have an anti-surfing gun and a regular GF-gun too. -- Alcatraz

That is exactly the beatyfull thing about AM... I think that probably it would "blur" the virtual guns array. -- Axe


ok , so in my enemy wave i have this:
public void directionyes(){
				Point2D ahead=project(robotLocation,getHeadingRadians(),20);
				Point2D back=project(robotLocation,getHeadingRadians()+180,20);
				if (eAimFactors[(int)Math.round(((Utils.normalRelativeAngle(absoluteBearing(this.eGunLocation, ahead) -this.eBearing))/this.eBearingDirection) + MIDDLE_FACTOR)]<eAimFactors[(int)Math.round(((Utils.normalRelativeAngle(absoluteBearing(this.eGunLocation, back) -this.eBearing))/this.eBearingDirection) + MIDDLE_FACTOR)]){
					direction=-direction;
				}
		}
		
		public boolean test(){
			this.eDistance+=(20-3*this.bulletPower);
			if ((this.eDistance)>this.eGunLocation.distance(robotLocation)-20){
					directionyes();
			}
		//		out.println("wave within 20 units");
			
			 if ( this.eDistance > this.eGunLocation.distance(robotLocation)){
			//	out.println(timeFired+" "+getTime()+" Enemy wave hit. ");
				//out.println((int)Math.round(((Utils.normalRelativeAngle(absoluteBearing(this.eGunLocation, robotLocation) -this.eBearing))/this.eBearingDirection) + MIDDLE_FACTOR));
				try{eAimFactors[(int)Math.round(((Utils.normalRelativeAngle(absoluteBearing(this.eGunLocation, robotLocation) -this.eBearing))/this.eBearingDirection) + MIDDLE_FACTOR)]++;
				}catch(Exception e){out.println("enemy wave error!");}
				removeCustomEvent(this);
		    }
			return false;
		}

and after i run the bot for a while,10 rounds or so, i get this error:

.r2d2.R2d2 .35: Exception: robocode.exception.RobotException: You cannot take action inside Condition.test().  You should handle onCustomEvent instead.
robocode.exception.RobotException: You cannot take action inside Condition.test().  You should handle onCustomEvent instead.
    at robocode.peer.RobotPeer.tick(RobotPeer.java:949)
    at robocode.peer.RobotPeer.turnRadar(RobotPeer.java:1084)
    at robocode.Robot.turnRadarRight(Robot.java:1001)
    at ahf.r2d2.R2d2.run(R2d2.java:41)
    at robocode.peer.RobotPeer.run(RobotPeer.java:616)
    at java.lang.Thread.run(Unknown Source)

any ideas? i don't understand why this would happen as the rounds progress.

--andrew

Try just to set flags within your Condition class, avoid calculation or any huge processing. (btw, next time try to clean up and ident your code posted here, itīs very difficult to read confused code :). -- Axe

What does this line do?

 Point2D back=project(robotLocation,getHeadingRadians()+180,20);
Adding 180 radians to your heading is usually not a good idea. -- Scoob

good call. if i add pi to it,doesn't that project my posistion backwards instead of forward. that's what i'm trying to do anyway--andrew

Yes, that should work. I always seem to get radians and degrees the wrong way round... -- Tango

About that first exception you posted, Andrew, did you see if a different exception was thrown in test() in the round before it started happening? Usually that happens as a result of an exception being thrown in test(). -- Kawigi

Kawigi is right. I already had similar problems, but forgot that. That first exception usually have a better trace, try to find it... -- Axe

you are right, i just noticed that it throws an array out of bounds exception when i try to access the eAimFactor? array to test which direction to move. After further examination, i realized that the enemy wave has errors saving to eAimFactors?, and since i use the same method to determine the guess factor as with my normal wave, somthing must be wrong with what data i put into the wave. i'm posting the code for that on page andrew in case anyone feels compelled to look at it, and it doesn't really relate that much to general wave surfing, just mine. --andrew


Ok, i've bodged together WaveSurfing ala Brainfade but theres one thing i'm not sure about. Currently i pick the GF i want to move to, either move there, or move to point that wont cause me to hit the walls:
        while(!fieldRectangle(50, AR).contains(vectorToLocation(myHeading, moveDistance, this))&&tries++<100)
        {
            myHeading += direction*0.05;
            double theta = pi - (Math.asin(moveDistance/targetDistance)*2);
            double angle = pi -theta - 0.05;
            moveDistance = moveDistance/Math.sin(angle)*Math.sin(theta);
        }
The last 3 lines of the loop,make the assumption that i'll be closer to the enemy if i smooth the walls so i want to adjust the distance i travel to try and keep the resultant angle the same. Without this code i tend to have a movement profile with a larger positive spike. Whereas with it, i have a profile that appears overall flatter, but it seems to fair worse against most bots. What do you guys do?? --Brainfade

I've been there too. With about the same results. Now I instead iterate both my future (wall-smoothed) movement and the wave movement one tick at a time until the wave hits me. I think that's the way to go. -- PEZ

I pick the wave closer to me. Then i calculate maxGF_forward and maxGF_backward (that is how far that i can get forward and backward until the wave reach me). Then i choose the "best reachable gf" (given maxGF_forward and maxGF_backward), and navigate to there. Note that i do this only once for each wave... -- Axe


hey you robocode geeks what about this: if i can use enemy waves to find out at which guess factor i have been hit, why shouldnt i use it to find out at which factor i am not hit??? All enemy waves that have hit me are removed and those which have not hit me could be used to find out that factor (or factors) , the enemy could have NOT shot at you, because else you would have been hit which your arent. Call me craze if i am. --deathcon

Ummm, what would you use it for? -- PEZ

Imagin you have a bot with a really cool and working wave surfing. After some rounds when you learned some about the habbits of your enemy to aim you will get hit seldomly. Until the enemies gun has detected that u changed your movement you will not learn - the enemy will. But if you use 'negative enemy waves' you could predict when the enemy has changed his targeting so that it fits to your movement. This would make your bot react much more quick --deathcon

My first surfing implementation was something I called /GoToStyle which always went for the "valleys" of the self profile. Of course it wasn't "cool" and certainly not "working" so it might be wy I didn't have any success with it. I retried it to some extent with a 0.9.* version of CassiusClay though, but I didn't get it right then either and decided to push in the main stream of surfers a while more. Is this type of surfing something like what you mean? Someting tells me you think of something more fancy... -- PEZ

1) i dont know how you dodge Waves but i try to move to that GFIndex that i have been hit fewest and that i can reach. Another possibility is to move to that GFIndex that is farest away from that index that will hit you most probable.

2) The idea posted above was this: a 'normal' enemy wave surfer learns only if it gets hit. Then you add 1.0 or whatever to the hitIndex. But you could also substract .1 (just an example) from that index (or more) that you have definitly NOT been hit at.

--deathcon

1) That sounds like WaveSurfing/GoToStyle to me.

2) It sounds a bit fuzzy. At least after a while when I have been hit everywhere? -- PEZ

Sorry but i thing this here doesnt fit on the WaveSurfing site. It only uses EnemyWaves, but anyway...

1) Do you move as far as possible away from that index that will hit most probable, or how do you use enemy waves for dodging?

2) WaveSurfing/GoToStyle would mean: select a point (using information of how the enemy fires) and move to that point. If you have reached or if something unexpected happens select another point

3) i do no goTo style. I calculate to which point i would come if my circle direction was 1 and where it would lead me if it was -1. Then i calculate which GuessFactor this were seen from the enemy wave that will hit me next. Then i look for that index that has fewest hits and that is between the both maximum reachable indexes. Finnaly i look if i have to move with circledirection 1 or -1 to get to this best index and move.

4) Maybe i just cant explain but here my third try:

Imagin you are fighting a bot that uses GuessFactorTargeting. It alway shoots with that factor its most likly to hit you. As a WaveSurfer you try to avoid to move to exactly this factor. But how do you know which factor the enemy takes? You fire enemy waves and if you are hit you look which factor it was that hit you. Then you add 1.0 the the index of your hitIndex array that represents the factor you have been hit. So you wont get at this index in the next time, because you avoid it. The enemy gun detects that you dont move anymore to that index and shoots to another that is now the best. You (as a bot that surfs waves) need some time until you changes your movemnt again, because a single hit doesnt influence much but many of them do. So you must everytime get hit some times until you change your movement effectivly. Agree with me?

4.1) to avoid this you could use your enemy waves. Everytime an enemy wave has traveled the distance so that it could have hit you (by the distance), but in reality it DIDNT hit you, you can substract 0.1 (or anything different) from all the hitIndex that represent a factor THAT would have hit you, because it the enemy had fired with this factor it WOULD HAVE HIT you which it DIDNT. Ergo: the enemy has NOT fired with this index. And when he detects that it should have shot with this factor to hit you it learns and maybe shoots next time with this index. If you use now my methode you could find our how the enemy fired not. And that is just what you want to know because you want to move where the enemy fires not.

--deathcon

Funny. I think this sounds all like WaveSurfing. I just love your idea now when 4.1 got me to understand it. I might try it tonight. Your current surfing still sounds like what I tried to achieve with my goto-style surf, only you do it in a saner way. Currently I surf much like you do with the difference that I only check the extreme forward and the extreme backward destination and adjust my orbit direction to avoid the one with the most hits. But I don't wait for the enemy to hit me several times at the same GF before avoiding it. Pugilist learns immediately and CassiusClay take two hits to "get it". -- PEZ

It sounds like normal flattening to me, but I don't understand why you would subtract .1. If you visited that GF and the enemy didn't hit you there, you should add .1, because that GF became more dangerous than any other "not hit" GF. Anyway, flattening works great against good guns, but will make you weaker against simple guns. -- ABC

Yeah the same idea came to me writing this ,abc ,but if you subtract .1 it gets better against weak guns. --deathcon

With weak you mean "slow in learning"? The difference between this and the way I do flattening is that I use every-tick waves to flatten, whereas this would only use "real" waves, right? -- PEZ

No actually it would detect bugs in guns. --deathcon

No, I mean weak as in you'll eventually get hit when all the .1s add up to a 1 and you start dodging that GF as much as a GF where you were actually hit. If you subtract .1, I think it'll make you weaker against good guns, since you'll revisit GFs too often. About every-tick waves, I don't know, I never used them, they seem a bit counter-intuitive to me... -- ABC

But you use every-tick info in your gun, don't you? -- PEZ

Yes. :) -- ABC


as pez wrote "adjust my orbit direction to avoid the one with the most hits" i wondered how many possiblities there are to "dodge" enemy waves. Can you please fill in here so that one can see what has been succesfully implemented. If you dont want to type the name of your bot (because nobody should know what your bot really does) , you can can just add a x :

ActionBots
Move in the direction where you have been hit the least in the maximum reachable pointsCassiusClay
Pugilist
Shadow
PulsarMax
Move as far as possible away from where hit most
Move everywhere but not where you have been hit most
Move to index where you have been hit fewestShiva

@pez isnt that the same??? If you move to the opposite direction you will always move as far as possible away, imho. --deathcon

I thought so too first. But then I changed my mind. And now I changed my mind again. But I don't know exactly what it is I do. =) There, now maybe... -- PEZ

In Shadow I currently simulate 3 possible movement decisions: moving in the same direction, inverting direction, and stopping. I then evaluate the consequence of those 3 actions until the last bullet arrives, and choose the least dangerous one. Not exactly the first option in that table, but similar. -- ABC

Unless you define your current position as one of the "maximum reachable". Which it is in a way. -- PEZ

Of course, if I'm going full speed, stopping can be different from my current position. You are right that it's a "maximum reachable if I take this action" position, though. I can actually evaluate any (direction, maxSpeed) pair easily with Shadow's current movement code. -- ABC

Cool. See any rating points coming your way through this? -- PEZ

I've had it like this since the early Tron/Shadow? v3 versions. I tried many different combinations but never saw major performance differences in my tests. I never tested it in the rumble, though. -- ABC

I tried that in a couple of versions, but it caused me problems against head-on targeters... possibly because my prediction was broken, thinking about it. :) Currently I'm doing a binary search of the positions I can move to if I turn on the current tick and turn/not turn on every tick when a wave passes, and taking the direction with the best minimum value. Not sure it's worth it, though. -- Jamougha

Really interesting - and unexpected for me, i have to say. Well i will have to test more but i thing that my methode should work best ( dont we all thing that :P ) if implemented correctly. You methode doesnt care about a possible secound pike in your movement profile. --deathcon

Sure it does, it looks for "valleys" in my current movement profile and tries to stay inside them, avoiding any number of spikes. I never even calculate the most probable enemy firing GF, I just go for the best one I can reach (or combination of them, if there are multiple bullets in the air). -- ABC

How do you find out the direction where you have been hit fewest??? What direction do you mean. The direction seen from your current position (circle direction) or direction seen from an enemy-wave's GF0 ? --deathcon

The direction is determined by the current orbit direction. Thus I check maximum reachable forward and max reachable backwards positions. ABC obviously checks the position he would arrive at if he stepped on the brake too. -- PEZ

I simulate my movement until the last bullet arrives for every decision I want to test. The danger of each one of them is the sum of the visits to the resulting GFs (weighted by ETA). If, for example, the danger of inverting is less than the danger of continuing in the same direction, I invert direction. -- ABC

That's exactly what I do too. -- PEZ

A few years ago I visited London (UK) in business. I had half a day free and spent it in the game arcade's trying to paint the high score tables of their Sega Rally 2 machines (see http://pezius.com/sr/ for more info on the subject of SR2). Well, to cut a long story short... I went by a shop and saw these awesome shorts in the window and just had to buy them. As it is very hot in Stockholm today I am wearing those shorts. Then I suddenly realized something...

Now, isn't that amazing??

-- PEZ

That's a painting by Hajime Sorayama in case anyone's interested. http://www.sorayama.net
WARNING: Most of Sorayama's artwork is adult in nature, viewer discretion is advised. --David Alves


If i remember correctly you ABC (and maybe some other guys) wrote somewhere that Shadow circles around the CURRENT position of its enemy and not around the position where the closest bullet has been fired from. But if you always use this position to determine which direction to circle would be best, your calculation gets definitely wrong, because the currect position of the enemy changes from tick to tick. So do i remember wrong or how do you solve this? --deathcon

Shadow used to circle the current enemy position in its first wavesurfing versions. Since then I changed it to circle the closest bullet origin. See Ascendant's page for a discussion about that, Mue uses enemy position circling in the current KingBot?... -- ABC

I think you must be thinking wrong somewhere deathcon. Why would the calculations go wrong if you circle the current enemy position? There's a difference between what point you circle and the center of the waves where you calculate danger. I made a recent version of CC circle the current enemy position instead of the center of the closest wave (like I usually do). It made no difference at all in terms of RR@H points. -- PEZ

It probably depends on the style of surfing you use. If its similar to TrueSurf (so you just decide every tick whether changing direction is better than continuing forward), its very easy to change the center.

If you use something similar to GoToStyle the calculations get a lot more complicated. One problem here is that you usually determine the range of reachable guess factors by iterating the movement forward and backward, which only works when theres a static center. I tried to use the opponents position at decision time for this (the best guess factor only needs to be calculated once per bullet). Second problem is that you wont reach the edges of the interval of reachable guess factors at the and of the iterations but somewhere in between. So it does not work to iterate movement forward and then calculate the guess factor, the guess factor must be calculated during every step of this iteration (and maybe it should be even stored in a lookup table so that its easy to convert it into a position in case it turns out to be the best guess factor). So all in all its difficult to change the center of the orbit for GoToStyle but of course its still possible. --Mue


I have a problem with my surfing, my bot loose about 3% of its scans events, so sometimes I miss a bullet or I detect the bullet one tick later. I was wondering how other deal with it. For the moment I extrapolate a scan when there is only one missing and I am wondering if it would be worth using GetScannedRobotEvents. --Florent

Loosing 3% of scan events, sounds bad too me. Though I haven't checked if PulsarMax misses any. To answer your question how others deal with it, I don't. What exactly do you mean with loosing 3% of the scan events anyway? Does your radar lock slip at times or are you not receiveing the radar events due to too much time spent doing other things? Do you execute much code in your event handlers? -- Pulsar

What I count as missed scans is when the time difference between two consecutive scan is superior to 1. The radar works fine when the bot does not move. And yes I think I execute too much code in my handlers In onScannedRobot I evaluate the danger forward and back, I think this is where it takes too much time. It might also have something to do with my computer, it seems pretty slow (iBook G4) for exemple in my last battle vs CC, CC skipped 1117 turns in 35 rounds.-- Florent

Regarding the missed scans: Not sure if this is it but a quick look at the radar scan arc of Toad (preferences->visible scan arcs) and it looks like you might have a beam that is too narrow at times and the enemy could perhpas (rarely) move outside the scan arc ? Regarding skipeped turns for CC: As you are using multiple threads your bot "steals" CPU time from CC. Try increasing the cpu-constant in robocode.properties to something big like 100. The cpuconstant thing is flawed and needs to be reworked IMO. --Pulsar

Since there isn't anything you can do in onScannedRobot( ScannedRobotEvent ) that you couldn't do just as well in the regular turn, you may as well save off the events in a collection (e.g. List) and process it later. I don't do a lot of calculations in my event handler. I just create a new enemy object if one does not exist yet for that name, and determine if I'd rather make this enemy my primary target instead of my current primary target. All other tasks, such as aiming at him, occur in the main loop. - Martin Alan Pedersen

When all processing takes place in the main-loop, you take the risk that your main-loop is not 'finished' when the turn ends. You won't miss scans, but you do not have enough time to process them. What do you think is worse: get bitten by the cat or by the dog ;-). GrubbmGrb is my only bot where the processing takes place in the mainloop, all others do it in the onScannedRobot event. The best remedy is to speed-up your processing. --GrubbmGait

I do quite a lot of computations in my main loop. I calculate about 5 layers of movement behavior. I finding firing solutions for 7 guns, two of which assume my target is moving based on my movement, meaning I have to project where I'll be in addition to where he'll be. I have no issues that I've noticed with skipping turns, unless there is some overall lag spike on my machine. It was such a non-issue that I had the warning about missed turns disabled until last night, and I was running hundreds of rounds of 10-way melee at 75 FPS without any warnings about skipping turns. Even back when I was starting I'd see odd stuff like skipping turn 55 and 555, more than once. An odd coincidence, but I digress. Skipped turns are just not a concern, and I have a fairly elaborate framework of classes, though I think the code is pretty clean as far as speed. - Martin Alan Pedersen

I just changed cpu-constatnt to 100, and now CC does not skipp any turn and I can even run trab.Crusader (it timed out after its first shot before). I now miss less than 0.1% scans. --Florent


Robo Home | WaveSurfing | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited May 11, 2007 18:07 EST by Chase-san (diff)
Search: