Difference between revisions of "User talk:Khanguy"
(→Skipping Turns?: reply) |
|||
Line 54: | Line 54: | ||
actually no, just a reduced linear gun with a nano sized wall hugging movement(its based on wall smoothing). --[[User:Khanguy|Khanguy]] 20:09, 15 May 2011 (UTC) | actually no, just a reduced linear gun with a nano sized wall hugging movement(its based on wall smoothing). --[[User:Khanguy|Khanguy]] 20:09, 15 May 2011 (UTC) | ||
+ | |||
+ | If you have a version of robocode between version 1.7 and 1.7.2.1, and are running with "-Ddebug=true", then [http://sourceforge.net/tracker/?func=detail&aid=3032423&group_id=37202&atid=419486 this bug] could be what you're hitting. Otherwise, I'd guess it's something in your bot. Add some timing code in your bot to report how long different sections of code take? --[[User:Rednaxela|Rednaxela]] 22:03, 15 May 2011 (UTC) |
Revision as of 23:03, 15 May 2011
WallHugging
I need help fixing my wallhugging code. Everytime I reverse direction or when getHeadingRadians() nears 3pi/2 or pi/2 It seizes up(it won't move). I'm stick and can use any of the help I can use. Here is the code:
static double direction; //1 for clockwise or -1 for counterclockwise
.
.
.
//in the onscannedmethod
wallHugging(); //Dunno why I did this, but it works!
.
.
.
//whenever I want to change direction
direction = -direction; // reverse direction when hit
.
.
.
// this is the absolute heading I want to move in to go clockwise or
// counterclockwise around my enemy if I want to move closer to them,
// I would use less of an offset from absBearing (I'll go right toward
// them if I move at absBearing)
public void wallHugging(){
//Pez's wall smoothing code with adaptation
double goalDirection = getHeadingRadians() + Math.PI/2 + direction*Math.PI/2; // I want it to go straight
Rectangle2D fieldRect = new Rectangle2D.Double(18, 18, getBattleFieldWidth()-36,
getBattleFieldHeight()-36);
while (!fieldRect.contains(getX()+Math.sin(goalDirection)*160, getY()+
Math.cos(goalDirection)*160)){
goalDirection += direction*.1; //turn a little toward enemy and try again
}
double turn = robocode.util.Utils.normalRelativeAngle(goalDirection-getHeadingRadians());
if (Math.abs(turn) > Math.PI/2) {
turn = Utils.normalRelativeAngle(turn + Math.PI);
setBack(100);
} else {
setAhead(100);
}
setTurnRightRadians(turn);
}
Skipping Turns?
Question: what makes bots skip turns and how do you fix it? --Khanguy 00:12, 15 May 2011 (UTC)
A bot is allowed a certain amount of time each tick for processing. The actual time limit is relative to the CPU and stored in robocode.properties (CPU constant, in nanoseconds). If you take longer than that, you are forced to skip the next tick - or possibly multiple ticks, depending on how far you went over the limit. If you take a very long time, Robocode will stop your bot for the rest of the round (I think?).
So fixing it means keeping the amount of CPU time your bot uses under that limit. The limit on your computer should be very close to the same on all computers because of the CPU constant, but there could be some variance with different JDKs and CPU architectures. In general, a few skipped turns (say 1 every 200 ticks) is not a huge deal, but obviously you want to avoid them as much as possible. --Voidious 00:20, 15 May 2011 (UTC)
what about skipping some 300 ticks consecutively? My nanobot that I working on was skipping a lot of turns nearly every round. --Khanguy 01:21, 15 May 2011 (UTC)
Do you use pattern matcher? Nano-size pattern matcher usually can have at most 45 pattern depth, otherwise it usually can't match fast enough. --Nat Pavasant 01:24, 15 May 2011 (UTC)
actually no, just a reduced linear gun with a nano sized wall hugging movement(its based on wall smoothing). --Khanguy 20:09, 15 May 2011 (UTC)
If you have a version of robocode between version 1.7 and 1.7.2.1, and are running with "-Ddebug=true", then this bug could be what you're hitting. Otherwise, I'd guess it's something in your bot. Add some timing code in your bot to report how long different sections of code take? --Rednaxela 22:03, 15 May 2011 (UTC)