Artillery

[Soultaker]

I'm sorry if I wrote in the wrong place, but perhaps it's a hardly collocable post.
I've found out a way to find the elevation of the artillery guns in order to hit a target even kilometers away from the firing tank or vehicle.
It's possible to do this procedure with every kind of vehicle ingame, work best with vehicle with ammunition speed slow, like about 200-300 but will work with every speed (increasing speed require increasing precision).
So it's not necessary anymore the simulation of fire and the creation of the munitions on the head of the target of the artillery.
It's a quite complex sistem that requires some curve solving maths, but I'm not an space shuttle designer, so I will keep it simple.
For now I've only seen some kind of calculus that didn't lead of very accurate shots at high disance (over 1500 meters), or the creation of spawned munitions, wich isn't very "realistic".
I don't know if this is innovative, and because I'm not a genius   I don't know if someone thought of that before me.
So before sending it I would like to ask to you if I'm only discovering the hot water   .
So please let me know if this is of some utility...

[Killswitch]

You might be "discovering hot water" ;D. Have you tried the Chain of Command's "Unified Artillery" system?

CoC UA 1.0

Still, this is not to say that your work has no use - perhaps it can be used to have machine guns fire at distant targets (ranges 1000m and up)?

[bn880]

Hi,

sounds interesting, we (at CoC) opted for the very flexible method of calculating this using Neural Networks.  Are you using a form of approximation like Runge-Kutta?

I tried it myself once, and what can I say, not easy if you are not working with numerical methods every day.  By the way, we do not spawn shells in UA because we are incapable of predicting something, we spawn them to overcome a simulation limitation.

Cheers

[General Barron]

If you have a finished product, then by all means, release it to the public. The more the merrier, right? It's always better to have choices, then just one option.

Is it in an addon form, or a script? If it is only a script, then it would be a great alternative to UA, because people could include it in their missions and not have the extra addon requirement. Also, I believe addons have to be made in a specific way in order for them to be "UA" compatible, so your system could be used on addons that are not compatible. Killswitch's idea is also a good one; it would be great to see some actual heavy MG support in OFP.

By the way, we do not spawn shells in UA because we are incapable of predicting something, we spawn them to overcome a simulation limitation.

I didn't even know UA used "spawned" shells...

[bn880]

Haha,  yeah sorry, I was thinking of some past experiments, we just propell the shells these days.

[Soultaker]

I'm really sorry for my press silence, but my adsl broke down due to some cable work  I've done wrong... :-)
I don't wanted to say in any way the other "artillery solutions" aren't goow or that my is better, but it's only another solution of the problem, a simpler solution expecially for addon vehicles. I'ts very precise, even if you use a "not so fitting" equation, see below.
I am writing a text to explain all in details, but speaking of maths is difficult because I must do it in english and I'm italian... :-(
I'll explain it briefly here:
I saw this sistem used by my father wich works with very unpredictable natural phenomena (<--don't know if it is written tight ;-) ).
He proceed in this way:
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).
We can find it placing a unit on the map and make it look certain target and we can try to guess the elevation.
We must this procedure for about ten times, I measure the elevation from 300 to 1300 meters.
After doing that (it takes about 20 min, with a pre-created mission wich I'll post, it will take 5) we will have a table with a x-y coordinates, on the x we will have the distance: 300,400,500,600,700, ecc.
In the y we will have the respective elevation at the various distance.
So, what can you do with this data?
You can use a mathematic process called curve fitting to find an equation (obiouvsly: To make THE COMPUTER find an equation) that after giving it an imput X (distance) it can give you a result Y (elevation of the gun).
Than you could use dowatch or everithing else you want to tell the unit how much elevation it should add to it's weapon.
As far as I saw Ofp don't use normal phisics to calculate the trajectory of the bullets, probably I'm wrong because I don't have access to drag factors of the projectiles and to other details, perhaps you have more experience than I and know where to look for that sort of thing (expecially the people at CoC , when I installed your addons many time ago I was stunned   ;D), but for me usual phisics wasn't a possible solution, so I used this curve-fitting method to find a way to predict fly paths using only distance.
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.

Thanks to anyone who answered and I return to lay down my explaining text

[Unnamed]

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.zip

There 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

[Soultaker]

Thanks for the answer, and very interesting scripts.
This is answer to your right opinions (I made them too)

- The gradient of the terrain the firing unit is sitting
After many tests in various island the error for altitude difference is practically null.
Sometimes anyway the artillery shot about ten meters short, indipendently from the respective altitudes, but I made these tests with the older version, so probably in the new version these problems aren't present.

- Game phisycs
Didn't know of this one, I'll try to check it out. The sure thing is that the normal ballistic equation isn't appplicable (perhaps?)

-Drag Factor
This one is interesting, you say you had come out with a quite good drag factor, but the problem is that the real drag factor can be determined only by  lab experiments, so your drag factor semm more like a constant being used in the equation to make it behave in the way you want, but unless you use the right formula you will have it behave in odd way when you pull it to extremes, so, in fact, you have found the simplest of the curve fitting equation. With this affermation I don't want to say that your method isn't right, and probably it took a long time and hard work, so It is invaluable first of all for that, but, in fact you haven't got the right math tools probably.
With mathematic procedure you can find an equation with an andament (<- hoping this one is right in english) that fit your curve in a very nice way, thus allowing it to behave in right way even beyond limits.

I said this:"I measure the elevation from 300 to 1300 meters"
but only for data aquiring process, in fact after gathering that data the equation is ok for distance up to 2500 meters, I'm sure at 99% beyond (test ongoing)

Hoping to end my explain test shortly (I have little time this days :-\)
I will read your scripts in detail (I hope, time permitting)

[Unnamed]

The gradient of the terrain the firing unit is sitting
After many tests in various island the error for altitude difference is practically null.

This is more to do with gun elevation, if you artillery gun is sat on a 30 degree slope. It will effect it's potential max and min elevations.

This one is interesting, you say you had come out with a quite good drag factor

I came up with a drag coefficient that fits the round fired by the Inv44 mortars. If you where that way inclined, you could use this to see if OFP uses a constant drag coefficient or if it uses the attributes of the specific round being fired. As it happens it works with a few other rounds, I never bothered checking their mass and size to see if they differ. It would be a step closer to deciding if OFP uses different equations for different velocities.

so your drag factor semm more like a constant being used in the equation to make it behave in the way you want

It's a basic equation for plotting the effect of air resistance and gravity. But your correct, the trial and error I referred to, was the coefficient.

I'd be surprised if BIS used real world physics to, if there is a faster way of doing what essentially looks like the same thing in a game environment, why not use it?

in fact you haven't got the right math tools probably

Of course not, I guess only the authors of OFP can tell us the formula. But I doubt we will ever see the correct way of calculating a trajectory in OFP But as far as predicting the trajectory of the Inv44 mortar round within 10 meters (0 config dispersion), for the duration of OFP's shell life, from 0 to 1000m above sea level, mine works perfectly. But with far more scripting than I would prefer

Hoping to end my explain test shortly

Excellent, looking forward to trying out those high velocity rounds. If you have the data in Exel format? post that to please. It's much easier to visualise these things as charts.

[Soultaker]

Mmmmm, I have problems with artillery sitting on high degree slopes, due to the fact that the elevation isn't right, but I don't think this will be a problem, as an artillery sitting in a slope like that in real life shouldn't stay there, neither fire...
I'll try looking for a work-around to this.
The range isn't a problem, as I state in my nearly-complete explaining text, this evening I'll post it :-)

[Soultaker]

Uploaded the tute, you can find it here:

Indirect fire with all kind of vehicles

Edited by moderator, link fixed.

[Unnamed]

Hi,

I downloaded the application, looks like it could be very useful. I wish I'd had the bullet model when I did mine, might have saved me a bit of time searching for an equation I could implement.

Is it possible to download more *.nrl files, in particular to do with aeronautics?

Cheers

[Soultaker]

I'm sorry but I don't know, the program I use is only one of many, don't know if it has more downloadable presets.
I think you will be forced to find equations from areonautics books, or try around until you find an adptable equation that fit your curve quite well,
The problem, in fact, is that nlr doesn't support many constants, so you are limited to the number I used, if you try to add one it say you can't cause the program is running in demostration mode... :-(
anyway, try with other good program, there are many more in internet ;-)
bye

[Dinger]

Ciao Soultaker,

yeah, curvefitting is a good way to go, and in fact I was going to talk to someone about it when Denoir offered to train a neural network to do it.
Here's some tips that might help you improve the accuracy and utility.  They're also explanations for why we did it the way we did with UA.

First, determining gun slope is a relatively simple process: measure the height ASL at the point on which the gun is setting, then again at 10 meters down the line to the target. The distance doesn't have to be 10m, but it needs to be shorter than the terrain resolution.  Use trig to sort it.

Second, DoWatch is good for effects, but its accuracy is not 100% precise, and using dowatch as your primary means of aiming is going to introduce some granular error (ick!) in the results.

Third, the shotshell simulation is limited to 20 seconds, and shotbullet to 3.  After that the shell explodes. BIS hacked their own code to allow for a 120 second life on the LGB, but if you choose that, you get no recoil effects, and velocity out of the barrel -- the shot just drops.

Fourth, the physics model is really goofy.  If you track a shell fired at 75 degrees elevation, you'll see that it actually changes direction on the way back down.  You can reduce the number of parameters to fit for by using a fired eventhandler to grab the shell and do:
_shell setdir getdir _shell

That will zero the angle of attack and eliminate one variable from the mix.

Fifth, if you do zero the AoA, you don't have to limit yourself to 13 data points and test data fired "out of the barrel".  You can create shells, use setvelocity to fling them at the elevation and speed desired, and track where they go; use savegame to make an .fps file and binviewer to read it.

Sixth, Bn880 isn't exactly right. UA 1.0 doesn't spawn any artillery shells; in 1.1 we do create some submunitions, but that's a different story.

So your system seems ideal for shorter-range stuff like MGs, tank main guns, and small mortars. I'm always of the opinion that the OFP world could use more artillery and indirect fire in general, so if I can be of service, mandami pure un messaggio.


Dinger

[benreeper]

I was using doWatch myself and for short range (very) it does work.  With it you can make a tank destroy a certain target irregardless of the fact the target is a threat or not.
--Ben