Talk:Wall Smoothing/Implementations

Hey, I need some help with wall hugging(my question is here because I base my wall smoothing implementation on wall smoothing). I am using PEZ's wall smoothing code to hug walls. The only differences being that when I call the method I use getHeadingRadians() instead of absoluteBearing and I also removed -Math.PI/2*direction from the variable goalDirection. My problem here is not when it hug the walls clockwise(it hugs them perfectly), but when it tries reverse direction by going anticlockwise. It seizes up and oscillates between a few pixels. Thanks in advance --Khanguy 21:44, 10 April 2011 (UTC)

Hmm, kind of hard to say without seeing the code. My guesses would be your back-as-front method is messed up (you have right angle to move in but aren't moving that way correctly), you're not calculating current direction correctly, or you just lost some direction-sensitive piece of logic in your adaptation of the code. Can you draw (or even just print out) the angles that are being considered, like in this YouTube video? That should offer some clues. --Voidious 02:01, 11 April 2011 (UTC)

static double direction;	//1 for clockwise or -1 for counterclockwise
.
.
.
//in the onscannedmethod
wallHugging(); //Dunno why I did this, but it works!
.
.
.
//in the onHitByBullet method
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);
}

I don't know how to find the angles, but the code I was testing is above. This works clockwise, but it sometimes stalls when trying to hug walls counterclockwise. --Khanguy 17:58, 11 April 2011 (UTC)

Well, there are some things I don't understand about the code. First, if wallhugging is a method with no arguments, I think you should have () after the method name, like public void wallhugging() {. In fact, I didn't even think what you have there would compile, and my Eclipse / JVM is definitely yelling at me when I try it. The getHeadingRadians() that you are passing as an argument - I don't know where that's ending up. So I can't quite figure out exactly what I think should be happening from the code.

And if absBearing is facing directly away from the enemy, then you are moving directly away from the enemy at all times, but wall smoothing to turn in the desired direction when you get near a wall? Or is absBearing pointing directly at the enemy? I'd normally move at something like (absBearing - (direction * (A_LITTLE_MORE_THAN_HALF_PI))), to move slightly away from them, then use that as the starting angle in the wall smoothing.

What are you setting absBearing to, and where? Sorry I don't have an answer for you yet, still trying to get a handle on the code and how it is actually working. =) --Voidious 20:28, 11 April 2011 (UTC)

Code should compile now (it compiles in eclipse for me), counterclockwise still doesn't work. --Khanguy 23:12, 11 April 2011 (UTC)

There, try it now. I added back the direction*Math.PI/2, but also added an extra Math.PI/2 so that it is inline with the direction you are going rather than parallel to it. --Skilgannon 05:56, 12 April 2011 (UTC)

Hmm...though less of a problem now, this code still seizes up when getHeadingRadians() is near 3pi/2--Khanguy 05:57, 14 April 2011 (UTC)