Talk:Linear Targeting

Credits - Example of Noniterative Linear Targeting Old wiki page: LinearTargeting/NanoLinearTargeting Original author(s): Kev

---

I find the noniterative targeting 100% accurate aside from walls if you replace the 13 with a 10. I was fooling around with the code to try and make it more accurate, and I made a discovery! New code:

double absoluteBearing = getHeadingRadians() + e.getBearingRadians();
setTurnGunRightRadians(Utils.normalRelativeAngle(absoluteBearing - 
    getGunHeadingRadians() + (e.getVelocity() * Math.sin(e.getHeadingRadians() - 
    absoluteBearing) / 10.0)));
setFire(3.0);

Does anyone else get the same results? I hope so. If it does, I'll be... remembered! For a very small thing... But... But I'll be like, on a very small scale, like ABC, like all of the "Robocode scientists", I will have made a discovery! I'll be so happy with myself! =') --Awesomeness 22:39, 16 March 2009 (UTC)

Also, I have found that if it remains 13, but the firepower is adjusted to 2.0, it is also 100% accurate. --Awesomeness 22:43, 16 March 2009 (UTC)

This isn't something new. In the formula the 13 represents the speed of the bullet. The original formula assumed a firepower in the general area of 2.33. For a firepower of 3.0 the accurate value is 11, and for firepower 2.0 the accurate value is 14. It probably should be mentioned alongside the code though but it's generally been assumed that people knew what the 13 was. See Robocode/Game Physics for more information. --Rednaxela 23:39, 16 March 2009 (UTC)

=( Oh well... lol --Awesomeness 00:40, 17 March 2009 (UTC)

Ok, this is kind of unrelated, but all you guys here are experts at trigonometry,and although I go to a VERY advanced school, I'm only 13, and I have a limited understanding. I am making a java application totally unrelated to Robocode. Say I have this scenario:

I've made a dot that moves around with the arrow keys, but I want another dot to follow it. I've made the first dot move according to the arrow keys, and I could make the follower dot's movement simple, but I want it to move DIRECTLY towards the arrow key mover dot. To do this I need two things:

-A method returning a double and taking parameters x, y, x2, and y2 giving the angle in radians between them in comparison to vertical. For example, if x and y are 0, 0 and x1 and y2 are 2, 2, then the angle you'd get is 2.35619449, or 135 degrees in radians.

-A way to get the change in x and y when given an angle. It returns x and y and takes a double called angle. For example, if the angle was 90 degrees, (in radians, though, of course) then it would return 1, 0, if it was 180 degrees, it'd return 0, 1, and if it was 270 degrees it'd be -1, 0.

Sorry if this is confusing... Someone help, please!

Well I don't know the exact wiki protocol, so I won't touch this page, but since is too unrelated I moved the conversation to your talk page, and I will answer over there. --zyx 01:22, 29 March 2009 (UTC)

Problem with "Walls" only at the bottom wall?

I wrote a bot that uses circular targeting, basically the same as written on the Circular Targeting page. Now I let my bot fight "Walls". It always wins, but I noticed that, when Walls is running along the bottom wall (only there), the algorithm doesn't seem to be accurate. It rather looks like head-on-targeting.
Since circular targeting should do the same as linear targeting in that situation, I tried the WaveSurfingChallengeBot B, and he's got the same problem versus "Walls". Okay, I know that the algorithm doesn't behave so nicely when the enemy is moving to a wall, but why does it just fail at the bottom wall then, and not at others?
Thanks in advance!

Well Kenran, I suggest you try to output the iteration to the debug screen or to a file to see where it's going wrong. I think it's most likely the code thinks Walls is driving into a wall and cutting it off, or something. :) --Positive 20:05, 30 November 2009 (UTC)

Thanks for your answer. I did some testing now, and I found out what the problem actually is. If the enemy is directly at the bottom wall, the enemyPosition that has to be calculated before is getting a false rounding, there enemyPosition.getY() is 17.99...
Substituting 18.0 by e.g. 17.9 fixes the code and Walls is being hit everywhere :-) Should I edit the page with that? --Kenran 17:01, 1 December 2009 (UTC)