Talk:Radar

Mind if I work on this after I get my page put togeather? --Chase-san

Not a problem. It is a wiki, after all. --AaronR 07:46, 12 November 2007 (UTC)

I fixed some spelling / grammar stuff as well as did some revising of stuff that was a bit verbose or just seemed a little off (like mixing turnRadarRight and turnRadarRightRadians in the same code snippet). I'd never heard of a "Perfect Lock" as a proper name like that, so I edited that part a little, too. The "wide radar" code could be a lot shorter, but I don't have time to make sure I get it right at the moment. Nice job with the page, Chase, it looks great. --Voidious 14:30, 12 November 2007 (UTC)

I made the first and last bits of the page. AaronR added the first set of snippets, I just added the wide radar and information on the Melee radars (as I don't know a great deal about them). The wide radar could indeed be a lot shorter. I can probably fix that after class. --Chase-san 14:33, 12 November 2007 (UTC)

Code location/turn skip

In robots that do a lot of processing, it is best to place the radar code near the beginning of the processing loop for each tick, as this will allow the radar to avoid slipping if the robot skips a turn due to too much processing.

While I realize I was the one that wrote this originally, this was before we discovered that a robot, that went it goes over the time allowed, skipped the next turn, and did not get tis current turn simply cut short. So I suggest removing this entire paragraph. --Chase 23:40, 22 April 2009 (UTC)

So anyone agree/disagree with this, has this been changed in the code or what? --Chase 19:06, 21 July 2009 (UTC)

Yeah, I say remove it, as it won't help with skipped turns. (I misunderstood how skipped turns worked for the longest time!) --Voidious 19:15, 21 July 2009 (UTC)

Hi, I have a strange problem. I was playing around with linear and circular targeting. I always used (earlier on, but also last week) the narrow lock described here. It works fine alone, but as soon as I add some other code, like for example the linear targeting code from here, to the onScannedRobot method, it's slipping all the time! Does anyone have an idea why this could be the case? I thought of those mysterious "skipped turns", but even if I multiply it with a factor 2 as described, it slips quite often.
Plus, last week I had a robot who used 2 guns at once in that method with the narrow lock (without factor) and it worked fine. I'm kind of depressed right now, hope you can help me. It has to be something rather trivial that I'm not getting right now. Greetings, --Kenran 17:37, 29 November 2009 (UTC)

If the only thing you changed is your targeting, which now is causing your radar to not work, it sounds like somehow that's changing your radar system. Do you have setAdjustRadarForGunTurn(true)? if you don't have that, then whenever you turn your gun, it will cause your radar to move a bit too, possibly causing the radar to fail. Spinnercat 17:46, 29 November 2009 (UTC)

Hi, too bad you answered, I was just about to delete my posting, since I found out that I really forgot to write that *g* As always with stupid things, I solve them just after having asked. Very embarassing indeed... Thanks for your answer! --Kenran 17:58, 29 November 2009 (UTC)

Renaming 1v1 Perfect Locks

I suggest the two perfect 1v1 radar locks be renamed in the following way:

• Narrow lock ⇒ Factor lock. The code behaves rather differently depending on what factor you multiply by. Narrow lock is just a special case when you multiply by 1. We could also move all the explanation about slippage and calling scan() further down, since most people will just choose a factor of 2.0 and never think about their radar again.

• Wide lock ⇒ Area lock. This code ensures a certain "area" (as in a certain distance to either side of the robot) is covered by the radar whenever possible. You could choose any distance to either side, the value used in the sample code is just the most common. This lock isn't necessarily "wider" than the narrow lock—you could choose a factor of 2.1 to get a really wide "narrow" lock. It also creates a nice effect of widening the scan area as the enemy gets closer—which looks cool if nothing else.

—Duyn 13:12, 25 January 2010 (UTC)