RednaxelaBot: Using .

2010-07-01T08:33:00Z

Using <syntaxhighlight>.

Voidious: migrating talk

2009-08-09T22:36:58Z

migrating talk

New page

== From old wiki ==

My test bot.
I don't know what to do with [[Aleph]] at the moment so I started to work on [[Apollon]] to see if there are some small changes with great effect. my first version of Apollon had something like 3200 bytes. So it took me some time to squeeze it into a MiniBot (currently 1496 bytes). -- [[rozu]]

Looks like a strong mini! Way cool. Is it using WaveSurfing? -- [[PEZ]]

It is. with the exact movement prediction just to see if the whole thing fits into a mini. -- [[rozu]]

Can you share the code for that mini-sized predictor? -- [[PEZ]]

Sure. I'll need some time to make it readable...

this is the code I'd use to predict my FuturePosition at the time (getTime() + 10) if I want to go to the point (200, 300) with the well known goTo code somewhere in the run method (I think it should also work for inside the ScannedRobotEvent, though I didn't try it):

<pre>
double moveAngle = Math.atan2(200 - getX(), 300 - getY()) - getHeadingRadians();
double moveDir = 1;

if(Math.cos(moveAngle) < 0) {
moveAngle += Math.PI;
moveDir = -1;
}

setAhead(100 * moveDir);
setTurnRightRadians(Utils.normalRelativeAngle(moveAngle));
</pre>

this is the desired piece of code. I'm not using setMaxVelocity, so it is quiet small.
It returns the predicted position.

<pre>
private Point2D.Double predictPosition() {

Point2D.Double predictedPosition = new Point2D.Double(getX(), getY());
double predictedVelocity = getVelocity();
double predictedHeading = getHeadingRadians();
double maxTurning, moveAngle, moveDir;
int counter = 1;

do {
// the movement code basically the same as above
moveAngle = Math.atan2(200 - predictedPosition.x, 300 - predictedPosition.y) - predictedHeading;
moveDir = 1;

if(Math.cos(moveAngle) < 0) {
moveAngle += Math.PI;
moveDir = -1;
}

moveAngle = Utils.normalRelativeAngle(moveAngle);

// maxTurning is built in like this, you can't turn more then this in one tick
maxTurning = Math.PI/720d*(40d - 3d*Math.abs(predictedVelocity));
predictedHeading = Utils.normalRelativeAngle(predictedHeading + limit(-maxTurning, moveAngle, maxTurning));

// this one is nice ;). if predictedVelocity and moveDir have different signs you want to breack down
// otherwise you want to accelerate (look at the factor "2")
predictedVelocity += (predictedVelocity * moveDir < 0 ? 2*moveDir : moveDir);
predictedVelocity = limit(-8, predictedVelocity, 8);

// calculate the new predicted position
predictedPosition = translatePoint(predicted, predictedVelocity, predictedHeading);

} while(++counter < 10);

return predictedPosition;
}

// the math functions used above
private static double limit(double min, double value, double max) {
return Math.max(min, Math.min(value, max));
}

private static Point2D.Double translatePoint(Point2D.Double p, double dist, double ang) {
return new Point2D.Double(p.x + dist*Math.sin(ang), p.y + dist*Math.cos(ang));
}
</pre>

I didn't make any tests so far with exactly this piece of code. please tell me (or correct) if you can see some misbehavior and/or mistakes. -- [[rozu]]

Wow. Way cool. I just might try it in Pugilist to see if it works. And if it helps me with my GF1 problem. I can't fit this probably, but it's good to know if it would help. =) -- [[PEZ]]

OK, so I tried it. It didn't compile at first, but I managed to fix that. It grew my bot with 200 bytes as I suspected. Unfortunately I didn't get an answer on whether it would help my bot. My reverse destination points are of the battle field for some reason. And I don't understand how to fix it. If you have RobocodeGLV014 you can maybe try yourself to apply this to PugilistGL? It's the destinations calculated inside <tt><nowiki>updateDirectionStats()</nowiki></tt> that I fed your predictor with. Aamzingly simple to apply it when we both thing goTo() style. =) -- [[PEZ]]

BTW. This is pretty cool:
<pre>
Fighting battle 18 ... rz.Apollon 0.2,kawigi.sbf.Barracuda 1.0
RESULT = rz.Apollon 0.2 wins 3358 to 120
</pre>

-- [[PEZ]]

thx, ... . can you send me a version of Pugilist with the above predictor implemented to zuestro@student.ethz.ch. I don't need the GL stuff for this (PugilistGL looks complicated ;)) -- [[rozu]]

Eh, I trashed it when I didn't get it to work. But it's easy enough for me to redo it. I'll do it in PugilistGL, because '''I''' need it for this. That's how I saw the reverse predicted destinations wasn't on the battle field. Pugilist is as complicated as PugilistGL so it doesn't matter if it comes to that. It'll make a nice demo of the predictor too I think. =) -- [[PEZ]]

why is this code so long? if predicting code needs to be this complex, i'm definitely doing something very wrong.--[[andrew]]

Sure there are some bytes you could gain if you don't want it to be readable. You also have to make the difference between "absolutely accurate" prediction and "will be more or less the same" prediction. In many cases the code above belongs into the first group. And if you want to be really accurate look here: FuturePosition (this one is a little bit longer). -- [[rozu]]

Long? Remove the comments if you like. It's only a few lines of code. And it's hardly complex. What it does is iterate the position of the bot from the current position, using current heading and velocity, to the desired destination point, accounting for acceleration and decceleration and max turn angle at a given velocity. Nothing of that can be discarded if you want to do precise prediction. For something simpler, look at Pugilist, which basicly uses the RandomMovementBot movement for prediction. Of course it's more like "what's my desired destination?" than an actual prediction. -- [[PEZ]]

i guess i just don't understand what it does,that's what makes it look complicated to me.--andrew

OK, I'll rephrase that. I mean it's not more complex than the task at hand. It's not trivial to predict your future position accurately. -- [[PEZ]]

Wow. I didn't think I'd ever see a minibot at #2 again, even with only 88 battles. :-) Looks like I'm going to have to do some work on [[Raiko]] shortly. -- [[Jamougha]]

"Wow" is right. --[[andrew]]

Thx, but... Just the typical rz.A... bot behavior going up fast and then falling down deep ;). I think it'll stand still somewhere at around 1960 (not a big deal for Raiko). -- [[rozu]]

1975 after 400+ battles. I'd say that'll be hard for Raiko unless Jamougha changes strategy for it. -- [[PEZ]]

[[Jim]] has gotten the above predictor to work. I have plugged it in a bot I call [[PPP]] and it makes a world of difference I tell you. Now I'm having spikes near GF-1 as well. =) This is with only the flattener active (that is, no adaption). Looks kinda funny. I'll post yet another profile shot (yaps) on the PPPugilist page. Right now I'm just awaiting [[Jim]]'s permission to release the bot for test in the rumble. Can you place the above code under the [[RWPCL]] umbrella? That would make it clearer what you can and cannot do with the code. You should be the only one allowed to use it for closed source bots I think. -- [[PEZ]]

Sure use this code under the licence: "make whatever you want with this code and it would be nice if you give credit" -- [[rozu]]

The code above used to find out a future position can probably make a big difference for wave surfers using to goto-style methode, but wave surfers that circle around the enemy (or the position the enemy was when it shot the wave that is nearest to you) cant find out their future position with this piece of code and the current heading precise. What i am doing in my current project ( - which is not yett running - so i should better say what i am trying to do) is to have a function that calculates a referenced move point with wished circle direction, circle center and move step from my current position. So i can simulate my future move - and end position. What i didnt do is to check if the single steps are really possible - i could implement that with the above shown code. Hope one could understand this. --[[deathcon]]

That's what I do in [[PPP]] and I think that's what [[Apollon]] does too, as does RaikoMX and possibly other surfers. -- [[PEZ]]

@@ Line 14: / Line 14: @@
 this is the code I'd use to predict my FuturePosition at the time (getTime() + 10) if I want to go to the point (200, 300) with the well known goTo code somewhere in the run method (I think it should also work for inside the ScannedRobotEvent, though I didn't try it):
-<pre>
+<syntaxhighlight>
 double moveAngle = Math.atan2(200 - getX(), 300 - getY()) - getHeadingRadians();
 double moveDir = 1;
@@ Line 25: / Line 25: @@
 setAhead(100 * moveDir);
 setTurnRightRadians(Utils.normalRelativeAngle(moveAngle));
-</pre>
+</syntaxhighlight>
 this is the desired piece of code. I'm not using setMaxVelocity, so it is quiet small.
 It returns the predicted position.
-<pre>
+<syntaxhighlight>
 private Point2D.Double predictPosition() {
@@ Line 76: / Line 76: @@
 	return new Point2D.Double(p.x + dist*Math.sin(ang), p.y + dist*Math.cos(ang));
+}
-</pre>
+</syntaxhighlight>
 I didn't make any tests so far with exactly this piece of code. please tell me (or correct) if you can see some misbehavior and/or mistakes. -- [[rozu]]

Talk:Apollon - Revision history

RednaxelaBot: Using .

Voidious: migrating talk