# Precise MEA

← Thread:Talk:Gilgalad/targetingStrategy/Precise MEA/reply (5)

You do not have permission to edit this page, for the following reasons:

You can view and copy the source of this page.

Return to Thread:Talk:Gilgalad/targetingStrategy/Precise MEA/reply (5).

1 - It may not be perfectly accurate, but it's a heck of a lot closer than Math.asin(8 / bullet speed). ;) And if your gun is capable of learning GFs > 1 there's really no danger in that.

2 - I think the only assumption it makes about walls is that enemies can't move through them. :-P

1 - Well yeah, I wasn't saying "precise MEA" is bad, just that one has to not forget that it still has error

2 - I disagree. It assumes they use wall smoothing, and don't react to walls in a significant other way. If those assumptions don't hold, then scaling-style "precise MEA" introduces an unpredictable error. I haven't tested but I suspect that if you compared "precise MEA" and "classic MEA" data against SpinBot, you'll get a sharper (and more predictive) image with "classic MEA" ;-)

Well, neither would hold a candle to Play It Forward against SpinBot... ;)

Precise MEA's advantages are certainly strongest against wall smoothing movements, but I still don't feel it assumes that any more than traditional MEA assumes there isn't a wall at all. If they just bounce off the walls and end up at a negative GF, wall distance segments will cover it just as well either way. If they just run into the wall and stop, you're right that a traditional MEA might be more accurate, but a raw bearing offset would be even more accurate (orbital wall distance would map exactly to firing angle) and I doubt anyone's advocating that.

I prefer Circular targeting to Play It Forward against SpinBot :P. But then, Circular targeting only performs better (instantaneous learning) because it makes different assumptions which happens by luck to be right.

The power of GF with (precise) MEA is its assumptions hold true to a greater number of competitors in RoboRumble than Circular targeting. If everyone in RoboRumble used circular movement, GF would suck.

Talking about efficient MEA calculation and Play It Forward guns, Displacement Vectors can easily adjust for walls using trigonometry only, without the need for precise prediction.

DV simplification in relation to PIT also applies to walls. So, in some sense, DVs consume less CPU than both PIT and GFs.

It scales differently, though. The precise MEA is calculated once (in each direction) no matter how many data points you're aiming with. If you're trying to use 500 data points and aiming with DVs, that's 500 projections for out of bounds checking.

Diamond's 1v1 gun used to use DVs, but I saw a big jump in accuracy when I finally caved and switched to GFs. Still use 'em in melee, though, and think they're very cool.

What if we mix together ideas from DVs and non-iterative wall smoothing to calculate a more accurate MEA than simply using asin(8.0/Vb)?

Imagine 2 DVs, one trying to go as far as possible clockwise and the other counter-clockwise. Ignoring walls, the resulting angles will match asin(8.0/Vb). But when near walls, if we adjust those 2 DVs, like wall sticks are adjusted in wall smoothing, we get a more accurate MEA, using non-iterative trigonometry only.

I looked at this, the problem it has is that it doesn't take into account that as the angle changes the wave will hit sooner. You could account for this I guess, but the iterative predictive methods are fast enough, I think.

Something like non-iterative linear targeting can account for varied bullet travel times. But the resulting code will probably be very bulky, like most non-iterative methods.

Well, I didn't use a noniterative method and I actually don't know how I could, but I now use a "binary search" for attack angles to get a precise MEA that doesn't take heading or velocity into account. I may make a page for it with diagrams, but for now you would just need to look at the code to see what I mean.

I tried a non-iterative MEA in Combat and it is working quite well. It doesn´t take velocity and heading in account, but it does take walls into account.

I modeled the problem as 2 intersecting circunferences (bot moving and bullet moving) and 1 intersecting line (wall). There are at most 2 points where the 3 intersect. Then repeating it for all 4 walls for 8 escape points. Add the 2 escape points from classic MEA (ignoring walls) for 10 escape points. Do some out of bounds checking on all points and then find which remaining 2 gives the widest MEA.

There are some loops but they are fixed and independent from bullet travel time. Making it very cheap to calculate.

I can post the algorithm later.

I don't iterate to find the bullet flight time. By iterate I meant for my binary search.

I'll try to get a better answer with diagrams soon, but I will be gone over the weekend so it may not be ready until Monday. One thing I was thinking about was Bearing Offset Normalized by Reasonable Travel Path Index targeting (an excellent name right?) where the bins would be scaled non-linearly. So, if I started wall smoothing at GF 0.5 then 0.0 through 0.5 would all be bins of similar size, but 0.5 through 1.0 would be a different size. However, I haven't tried it yet because I have had other things to do and I don't think it would be much of an improvement on precise MEA. However, the main issue I have, with all GF targeting algorithms, is basically that a robot going forwards 0.5 GF's and then back as far as it can will not necessarily end up at GF 0 due to wall smoothing. I cannot think of any solution to this problem (besides simulating the enemy's movement with the same algorithm from an identical list of random numbers) but I think that changing the bin size might make the problem worse.

That being said, I have to admit that my imprecise MEA didn't seem too bad. However, I think this was because the wallsmoothing approximation that I used will work as long as the enemy starts facing a certain range of directions. Because wallsmoothing is so common and this range of directions was basically that a robot would use while wallsmoothing, that wasn't a bad assumption, but I don't like making it.