Talk:Zoom Radar

There seems to be a lot of errors regarding rendering LaTeX. Is there a way to resolve this? --Frolicking Zombie 17:53, 26 February 2010 (UTC)

Ok, I'm looking into it... --Voidious 18:08, 26 February 2010 (UTC)

Fixed:

<math>

it = {{works - now} \over {\Delta Friday}} </math> Enjoy. =) --Voidious 18:33, 26 February 2010 (UTC)

Some comments

Heh, actually, inspired by what you had on your talk page, though doing the math a bit different, I've already implemented something along these lines in Glaicer. Take a look at Glacier's "ags.muse.radar.MeleeRadar" class, which IMO is much cleaner. It also looks really spiffy in action. Also, the math here is wrong, in that one gets the most change in angle by moving along a chord of the circle created by the distance to the enemy bot, and that fact also simplifies the math to calculate the uncertainty in angle to the following:

            double maxMoved = rules.MAX_VELOCITY*bot.getDataAge();
            double uncertainty;
            if (distance * 2 > maxMoved) {
                uncertainty = 2*Math.asin(maxMoved/(2*distance));
            }
            else {
                uncertainty = Math.PI;
            }

Essentially a single arcsine with a special condition for when they haven't been seen in so long that their angle is completely unknown (i.e. could be PI radians different in either direction).

Another note, is that in order to be accurate enough to ensure you don't slip when being this precise, it's also necessary to count the change in radar origin position caused by one's own movement.

Also, why the name "Zoom Radar"? I don't see any "zooming". --Rednaxela 17:54, 26 February 2010 (UTC)

The triangle formed in your equation would be the equivalent as if the robot traveled along the tangent created by the targetDistance circle. This creates slightly less of an angle (which promotes slip) than if you calculate the intercept of the targetError and targetDistance circles. BTW, why would you use (2*distance) as the hypotenuse of your triangle? --Frolicking Zombie 18:13, 26 February 2010 (UTC)

I think you're mis-visualizing the geometry of my equation, but I think that's my fault. (2*distance) isn't a hypotenuse, and it's made of two triangles, not one. I probably should have wrote it as "uncertainty = 2*Math.asin((maxMoved/2)/distance);" but I was silly and didn't (I really need to get out of my habit of pointless premature micro-optimizations (in this case to do with how multiplication is faster than division)). To get a better idea what it means, see the following diagram that I quickly whipped up:

Moving across the chord of the circle is truly the fastest way to for the enemy to change angles. After all, what's the quickest way for an enemy bot to change it's angle by 180 degrees? Just drive straight to the other side of you. --Rednaxela 19:18, 26 February 2010 (UTC)

I understand your method better with the picture. Both methods will end up with the same result, but yours is less computationally intensive to retrieve the bearing. /me bows. Mind if I update the code to reflect your method? --Frolicking Zombie 19:26, 26 February 2010 (UTC)

Feel free to... but just now I realized that the assumption of the chord being the most efficient path to change angle is incorrect. It's typical, so works well in practice as Glacier shows, but the real uncertainty factor is actually larger. To change angle, it's actually more efficiency to dive towards the enemy, plus if one drives straight towards the enemy, the angle will change by 180 degrees after traveling (distance) not (2*distance) right through where the bot is. It should be follows I now realize:

            double maxMoved = rules.MAX_VELOCITY*bot.getDataAge();
            double uncertainty;
            if (distance >= maxMoved) {
                uncertainty = Math.asin(maxMoved/distance);
            }
            else {
                uncertainty = Math.PI;
            }

to be really safe... in order to tighten it any further than that, and give any guarantees, requires relying on acceleration limits of bots or that they must be at least 'botWidth' distance from you currently. --Rednaxela 19:42, 26 February 2010 (UTC)

I can see now that both of our methods assumed that the target would be orbiting and maintaining itself perpendicular. If you looked at the graphic, the presence of a chord clearly indicates that there are places that the target could travel that would result in greater bearings. The max bearing would be the angle that is tangent, which the angle for is asin(targetError/targetDistance). --Frolicking Zombie 21:31, 26 February 2010 (UTC)