Not a member yet? Why not Sign up today
Create an account  

  • 3 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
Solved the projectile aiming calcs with drag

#91
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.
Reply

#92
(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).
Reply

#93
Well, there needs be some way to turn vector correction off to avoid slow firing guns always missing
Reply

#94
It corrects error of range table or something, I used it when I made satellite cannon code.
However I dont thing it works against zig-zag target.
Reply

#95
Yup no zig zagers and it should calculate closest aproach to target block
Reply

#96
Hey guys

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!
Reply

#97
(2017-03-10, 12:02 PM)Nick Smart Wrote: I have implemented a solver for the "whole hog". Proper drag equations (velocity squared, air density, drag coefficient, area)..
what!? how was it done?

I'm surprised at you are interested in internal ballistics.
Reply

#98
http://www.mindspring.com/~sfaber1/Coppock.htm

Working through that at the moment^.. thoughts welcome.


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!
Reply

#99
That seems to have worked well... muzzle velocity replicated for a bunch of small firearms up to large calibre WWI deck guns...

Now I have everything complete and just need to integrate it all!
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!
Reply

(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!
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)