I messed around with tables for indirect fire, which worked fine until you start varying the altitude of the firing unit and the target. Then the amount of data required became to large to be practical. Although I never used any thing as fancy as curve fitting so I'm looking forward to this.
We must know the elevation of our gun, (it's different for any vehicle in ofp, obiouvsly, and this is the problem in this solution).
DoWatch'ing a predefined position will allow you to alter the guns elevation as you said, but you need to get the gradient of the terrain the firing unit is sitting on. You can get an estimate of the terrain gradient with just scripts, but a more accurate way would be to use the game logic method on or with a custom made addon. You can also use game logics to monitor the actual elevation of the gun, handy for detecting when the DoWatch command has completed.
Another problem can be with the addons themselves, some fire projectiles at a different elevation to the gun barrel. Depends on what the addon maker wants, and how they set up the memory LOD's in O2.
As far as I saw Ofp don't use normal phisics to calculate the trajectory of the bullets
I suspect they will use a form of Game Physics. There are books available on the internet, dedicated to Game Physics. I just don't have them
I don't have access to drag factors of the projectiles and to other details
As far as I know there are a few ways of coming up with drag coefficients, I think the simplest (?) is to use the projectiles mass and surface area. It's only recently I found out you define mass in O2, so I never looked into this further with OFP.
I did write a similar system for SEBNAM and Inv44 Mortars, I just used trial and error until I found a drag coefficient that worked with them. It appears to work just as well with other types of projectiles, so perhaps OFP uses quite a basic model for things like drag?
Cant remember the number I came up with off hand, but you could always check out my scripts.
I measure the elevation from 300 to 1300 meters
Yeah this is the problem with low velocity projectiles. I could predict the path of a projectile travelling up to about 500 m/s, giving it a max range of about 2500 meters on level terrain. After that my equations fell apart. But the physics of high velocity projectiles in real life, are different to low velocity projectiles. So perhaps ofp uses a different set of equations for the higher velocity stuff.
There are not than many addons in OFP that fire rounds at those speeds. Mortars and WW2 era Infantry Guns being the obvious ones.
Plus the projectile life span of about 20 seconds will restrict the ranges possible. That's where UA comes into it's own, AFAIK they effectively fire Bomb's not shells. Which live a lot longer than shells in OFP, but behave in the same way? So CoC's UA, can easily exceed the 2500m range limit.
Also the limited life span means you have to return an ETA for the projectile, otherwise the shells can be deleted before they reach the target.
I will explain later how to find this equation, it matter of minutes, but if with an artillery addon the creator includes an equation for resolving it's shots it will be matter of seconds to implement it into an existing mission.
Sounds like I used a different method to yours, rather than compiling a table of pre-mission data, I sample the possible elevations with a standard ballistics equation in game, until I find the one that lands closest to the target. The trouble with my method is it takes about 4 to 5 seconds to range in for every new target, but it took longer than that in real life so I don't mind the delay.
Looking forward to checking out your scripts. If your interested in my estimate of OFP's drag coefficient and ballistics equations take a look at FCTrajectory.sqs in:
http://homepages.gotadsl.co.uk/~gssoft/FCOFPMortars.zipThere is also a function FCLaInterp.sqf, to help adjust for variations in how the addon was made and fires.
And one to estimate terrain gradient, FCGetGradient.sqf. Although like I said, this is not as reliable as it could be. I could write a simple stand alone addon, to return the true terrain gradient, if anyone else could make use of it?
FCTrajectory.sqf is based on two Excel spreadsheets I found here:
http://www.ma.adfa.edu.au/Teaching/ThirdYear/Projectiles.html