I've been wondering about this for a while. I'm immensely curious as to the logical programming of the auto aim. It seems to me that you'd first have to retrieve the position, velocity, and orientation of the targeted ship, and then calculate based on the chosen weapon's velocity, etc. That seems an awful lot to do, every tenth of a second or however often it updates. Do you use some sort of sophisticated algorithm to predict the movements of the player based on PAST movements? I don't even know whether that's possible. Or do you use simply an efficient inline function? I have no idea how networked programs go about doing those type of things.

-rc

Well, the calculation is relatively simple compared to, you know, rendering a scene full of textured polygons.

It's just linear algebra, with a square root or two. It doesn't take acceleration into account, nor past movements, which is why it's so easy to fool by barrel rolling, etc.

The fact that it's networked doesn't matter. The position, velocity, and orientation of the targeted ship are already available to the client because the client has to show it moving smoothly on your screen.

Is it possible to make it more sophisticated? Sure, it could take past movements into account and try to predict acceleration, etc, but it would probably be less accurate overall if it did; it'd basically be speculating rampantly rather than following a trend.

a1, it completely makes sense to me why a more complicated algorithm isn't used (it would always be possible to confuse it, but it might be less likely to work), but why not take turboing into account? The client already knows weither the target is turboing (since the engine's rendered differently) and it would bring better balance between energy and rockets as viable weapons to use on a running target.

:-)

That's fancy. I actually had to get my older brother, who's in a higher math than me, to explain it to me. But I think I get what you're saying. The word 'differentiate' was thrown about several times.

-rc

It's not even about derivatives, it's just this:

find position vector of target
find the distance to that position vector from player position vector
divide by the speed of the gun
multiply the x and y component of the acceleration vector of the target by this speed to get a new vector
add this vector to the target position
calculate the angle between the player vector and this vector (trigonometry)
find the current look angle
get the difference between the two angles
if the difference is less than a certain number, change the look angle to be the angle between the player position vector and the corrected position of the target vector

That's close. It's actually not correct. To solve it properly, you have to solve a system of equations to find the intersection of a) a sphere of all possible positions the projectile you fire could take, expanding at the speed the projectile moves; and b) the relative velocity of the target going in a straight line, or whatever predicted path. Once you've found the intersection in time and space (it involves solving the quadratic equation) you back-solve for the direction and shoot that way.

By the way, we aren't doing that now; we're doing successive approximation like panic says; if you repeat his procedure a few times it converges to the above one, except in the case where the above one isn't solvable; then it just returns the wrong answer.

That's why the leadoff target goes nuts when you turbo at someone; you can't actually hit them. I want to fix this in the next client release, but Ray and Waylon are complaining that the leadoff target would disappear, which is confusing.

Waylon's main complaint is that the leadoff target is useful in determining relative velocities even if you don't care whether your weapon can actually hit the target. The solution is probably a separate relative velocity indicator and a proper leadoff indicator for each weapon. I'm not sure how to make this less confusing than what we have now, which I think sucks (you only see the leadoff of the first primary weapon selection...)

I agree with Waylon's assertion. The leadoff target is extremely helpful in 'cutting the corners' while persuing a target. You devs can turbo infinately but us mortals have to pulse our turbos to maintain high speed and conserve battery. in those moments of no turbo, the leadoff target corrects and gives us the vector to take to intercept.

a1k0n, I've found that the auto aim doesn't find a correct solution when there is one.
Example: Person A turbo's straight towards person B. Person B is not moving. If person A fires without autoaim they hit person B, with auto aim the shots miss.

It isn't that it doesn't find a correct solution, it's that it finds an incorrect solution, because it's an approximation. In cases like that, it seems to diverge from the correct solution. Anyway, yes, I want to fix it.

hmm maybe on the hud you cold have something like speed and a small arrow showing the direction the target is travelling in. This would appear right under the targetting box.

We had discussed something along those lines.

Maybe some of these little doodads can help:

http://www.xflight.de/f16/original/parts/center_console/hud/hud.gif

I've been playing flight sims for quite a while, and as cluttered up as that may look I think it's still very effective. It just takes getting used to. I'd have no problem with an additional reticule. As long as they're color-coded or easily distinguishable between each other.

You know what'd be cool? An altimeter, just like that one, on all ships! :p

-rc

An altimeter...good one, rc!

The addition of a 'position/vector indicater' like in the HUD Arolte shows should be fairly simple based on the information now used in the current 'leadoff target'.

Well, we don't need to track things like altitude, etc. However, direction would be nice (granted we need to track in 3 dimensions). A more Flight sim type hud would be nice though yes.

I like how the space debris sort of helps track your direction, but I think it's a tad too distracting and excessive. Maybe if they were rendered as tiny dots and farther apart and faded in and our more smoothly. Sort of like the plankton you see in deep sea diving expeditions.

I'd still rather have the second reticule (more accurate) for aiming though. I agree that the current one is helpful in tracking the motion of your enemy, but I hate how it misleads you sometimes. One more reticule for accurate aiming won't be too confusing IMO.

We should definitely fix the situation where you can't hit a ship turboing right at you with auto-aim... as Eldrad said it would really help energy users fend off rocketeers.

Changes to the aimbot should be minimal, though, since we don't want to take all of the artwork out of energy dueling. Could the aimbot be made to understand acceleration from turbo but not sub-turbo dodging maneuvers?

And as far as the HUD goes, why not make it customizeable? You could choose the "simple" version we have now with one reticle for lead and relative velocity or choose the "complex" version with relative velocity, primary weapon lead, secondary weapon lead and tertiary weapon lead reticles; each with an on-off checkbox in an option menu somewhere.

Asp

The devs said that the HUD will be customizable eventually.