Post Reply 
 
Thread Rating:
  • 3 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solved the projectile aiming calcs with drag
2017-03-08, 01:03 PM
Post: #91
RE: Solved the projectile aiming calcs with drag
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.

Watch my videos!
Find all posts by this user
Quote this message in a reply
2017-03-08, 01:26 PM
Post: #92
RE: Solved the projectile aiming calcs with drag
(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).
Find all posts by this user
Quote this message in a reply
2017-03-08, 04:08 PM
Post: #93
RE: Solved the projectile aiming calcs with drag
Well, there needs be some way to turn vector correction off to avoid slow firing guns always missing
Find all posts by this user
Quote this message in a reply
2017-03-09, 06:07 AM
Post: #94
RE: Solved the projectile aiming calcs with drag
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.
Find all posts by this user
Quote this message in a reply
2017-03-09, 07:10 AM
Post: #95
RE: Solved the projectile aiming calcs with drag
Yup no zig zagers and it should calculate closest aproach to target block
Find all posts by this user
Quote this message in a reply
2017-03-10, 12:02 PM
Post: #96
RE: Solved the projectile aiming calcs with drag
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!
Visit this user's website Find all posts by this user
Quote this message in a reply
2017-03-10, 01:36 PM
Post: #97
RE: Solved the projectile aiming calcs with drag
(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.
Find all posts by this user
Quote this message in a reply
2017-03-10, 02:15 PM
Post: #98
RE: Solved the projectile aiming calcs with drag
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!
Visit this user's website Find all posts by this user
Quote this message in a reply
2017-03-10, 06:24 PM
Post: #99
RE: Solved the projectile aiming calcs with drag
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!
Visit this user's website Find all posts by this user
Quote this message in a reply
2017-03-10, 10:12 PM
Post: #100
RE: Solved the projectile aiming calcs with drag
(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!
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)