Talk:Waves/Precise Intersection

From Robowiki
< Talk:Waves
Revision as of 16:52, 20 October 2009 by Voidious (talk | contribs) (→‎Wave Surfing: reply)
Jump to navigation Jump to search
Credits - Waves/Precise Intersection
Old wiki page: Rednaxela/SuperBotwidth
Original author(s): Rednaxela
Credits - Waves/Precise Intersection
Old wiki page: Garm/BotwidthCalculation
Original author(s): Krabb
Credits - Waves/Precise Intersection
Old wiki page: Skilgannon/PreciseIntersect
Original author(s): Skilgannon

Wave Surfing

So far I know a few robots use Precise Intersection in their wave surfing. Unfortunately their code is either too messy (Wintermute) or too granular (RougeDC) that I don't know which class to look. So I asked here. (Diamond is too new to look into for this)

Normally you surf waves 'till the wave passed centre of the robot. But with precise wave intersection, in order to gain pixel-perfect surfing, you need to surf the wave until they passed the robot. So if anybody does this or the other way? --Nat Pavasant 11:20, 20 October 2009 (UTC)

I was planning to add all 3 to Wintermute, ie, branch when the wave first strikes, branch when the wave passes midway, and branch when the wave exits, but after adding in a stop branch for every tick on the second wave it was too slow to do that without skipping turns. I think it now branches at the mid-point only...--Skilgannon 13:21, 20 October 2009 (UTC)

My experience, precise intersect or not, is that I've seen a measurable decrease in performance any time I try surfing waves any longer than I do now. I surf until they are less than one bullet velocity away, meaning they will pass my center before I can move again. I have some thoughts on this. If you weight by distance or by time to impact, the weight of the wave after it passes your center will be very high, while the chance of it hitting you if it hasn't already is very low. Giving it less weight somehow might help. Also, be careful not to give it negative weight, since your time to impact or distance calculation may give a value less than zero. --Voidious 13:32, 20 October 2009 (UTC)

If you guys surf the wave only half-way, then how are you calculating precise botwidth in the danger calculation? --Nat Pavasant 14:33, 20 October 2009 (UTC)

In Diamond 1.47's bot width calculation, I start with the first tick the bullet will cross my front bumper and go until the tick where it will cross my center. I tried until it crossed the rear bumper and it performed worse. Again, it's probably because it's so rare you will be hit there that weighting all the ticks evenly is just inaccurate, probabilistically. The next iteration of my precise intersect experiments doesn't have that issue, and I will again try considering all possible intersections. --Voidious 14:52, 20 October 2009 (UTC)

You cannot post new threads to this discussion page because it has been protected from new threads, or you do not currently have permission to edit.

Contents

Thread titleRepliesLast modified
Bot width and GuessFactors220:20, 26 November 2012

Bot width and GuessFactors

When GuessFactor normalize angles based on MEA, doesn´t it distort the edges of the bot?

Looks like bots with distances farther away than when the wave was collected are calculated as being wider than they really are. Similar distortion happens when bullet power changes.

Am I missing something?

MN17:55, 26 November 2012

In the gun, I only ever collect/project the center angle. I only use precise bot width in my gun to find the exact center angle in the range. I use an imprecise bot width as the bandwidth in my kernel density when aiming.

In movement, the precisely predicted bot width is also the bandwidth in my kernel density. I still ignore it whenever collecting angles.

Voidious19:54, 26 November 2012

Using only the center of the range makes sense.

I wonder how much improvement is due to precise calculation, and how much is due to distortion (imprecise/unpredictable calculation).

MN20:19, 26 November 2012