(2017-03-08 01:03 PM)T3hJimmer Wrote: I don't see any need for a GUI, or for the player to even know it's happening. It is a way for the AI to be more accurate in situations where it currently misses more than it should.

I was more thinking about the player configuring the aimpoint card to fire with a vector shift (so you can choose to fire on the front part of a target for example).

Using an automated vector is better as it will adapt in real time, but that involves some calculations to find the point where the projectile was the closest of the target (using the CoM or nearest block?).
That's possible, but that would have to be profiled in roder to check that it's not taking too much CPU (and probably not doing it for every shell, but only once per second).

I'm sorry I have just skimmed pages 7 to 10. If I missed anything meant for me then quote it below.

So big update on this..

I have implemented a solver for the "whole hog". Proper drag equations (velocity squared, air density, drag coefficient, area).. relying on ballistic coefficient, relying on form factor of shell... varying drag coefficients at different speeds based on the G1 projectile calibration.. varying air pressure at different altitudes, varying gravity at different altitudes... ability to shoot out of water or into water and still hit.. it does everything and should be extremely realistic.

It still aims at a target assuming the target is moving in a straight line and I don't wish to reopen that conversation at the moment.

The only piece of the puzzle left is the "internal ballistics" calculations to determine muzzle velocity given calibre, mass of propellant, mass of shell, barrel length. I've found a few papers on it but not managed to derive a decent equation from them. Any help on this would be appreciated.

Reviewed FtD on steam yet? It's the #1 thing you can do to help FtD (and future games by Brilliant Skies!), so please take the time!

Regarding how it was done... it is reasonably easy to get pretty accurate if you change your reference frame to just point directly at the target, (so gravity is now no longer just "down") and solve for when "projectile travel" exceeds "current range to target" (both measured from firing point / origin).

It's basically one solve (the solve is for altitude difference at point when projectile travel exceeds current range to target).. then you rotate your solved velocity to point at the point in space where the target is supposed to be at the time of intercept.

Reviewed FtD on steam yet? It's the #1 thing you can do to help FtD (and future games by Brilliant Skies!), so please take the time!

(2017-03-10 02:15 PM)Nick Smart Wrote: Regarding how it was done... it is reasonably easy to get pretty accurate if you change your reference frame to just point directly at the target, (so gravity is now no longer just "down") and solve for when "projectile travel" exceeds "current range to target" (both measured from firing point / origin).

It's basically one solve (the solve is for altitude difference at point when projectile travel exceeds current range to target).. then you rotate your solved velocity to point at the point in space where the target is supposed to be at the time of intercept.

It solves for altitude difference of as a function of what, exactly? What is the variable being varied?

If gravity no longer points just down and thus also has a component in the direction of travel begin calculated, can't the shell exceed "current range to target" and at a later pont return back into "current range to target"?

How would this take the movement of the firing vehicle into account? Wouldn't that screw up the circular symmetry?

Or alternatively, would you mind sharing your code? It might be easier than answering a bunch of poorly formulated questions and would surely be an interesting read!