True artillery

[seedhe 0]

I have been messing with dialog controlled artillery, It is in the form of a very basic demo mission.

You use 2 sliders to give the direction and distance and fire a marker round if you are happy with the settings you fire for effect.

The artillery isnt actually fired from the location of the gun but I have attemtped to simulate it.

I did find a piece of code on the net, to calculate the trajectory of a baseball allowing for wind resistance and height differences. The calculations are nightmarish and so I took the wimps way out. I'll see if I can dig up the url if anyone is interested and has a stomach for heavy duty math

[Fangie 0]

I'm quite new to scripting and stuff, but you don't have a 20 second limit to shells. You could create your first shell, and after 20 seconds, you copy speed, direction and position into variables, and then you create a new shell, with the same

speed, direction and position. You could repeat this, so you can make a trajectory over 2 minutes. I'm not sure this will work, it's just an idea.

[uiox 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Try to imaginate an interface (with dialogs) which permits player to set azimuth and elevation of artillery, then fire<span id='postcolor'>

Some little game does this... since 1985...

OR in a MP mission a real artillerie....

But u give only a location on the map with radio....

OR u are God and play evrything evrywhere.

A problem of many dude with OFP.

Joyeux Noel

[MAsta_KFC 0]

All I want to say is Keep Up The Good Work guys!!

I'm an absolute maths dummy, but you guys are opening up a whole new world of oppurtunities in OFP!!

[whisperFFW06 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (uiox @ Dec. 16 2002,00:09)</td></tr><tr><td id="QUOTE"></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">Try to imaginate an interface (with dialogs) which permits player to set azimuth and elevation of artillery, then fire<span id='postcolor'>

Some little game does this... since 1985...

OR in a MP mission a real artillerie....

But u give only a location on the map with radio....

OR u are God and play evrything evrywhere.

A problem of many dude with OFP.

Joyeux Noel<span id='postcolor'>

Uiox...

Heu....

J'ai rien capté

I juste wanted to point that it would be possible to fire artillery, not ask for artillery fire by clicking on a map.

[benreeper 0]

This is nice. I have a script that fires 12 of the NamPack2's mortars and they land where I want (approc 2 kliks away).

No scripting involved other than to tell them where and when to fire. At ground zero you hear the whistling of the shells in the air just before impact. I used a similiar technique with the rifle mortars (range approx 300 meters).

Ben

[uiox 0]

[Wick_105 0]

ok since it seams you guys are in this pritty heavy right now I would like to add a bit of info for you guys.

traj is nothing to worry about since 105 and 155 nato standard can change propellant, in the 105mm there are 7 charge bags and the 155mm has different types of charge bags, red, green, and white.

what this means is if your only firing 3k away the barrel dont need to be level, drop the charge in 105 to a charge 2 elevation between 450 600 mils and you drop the sucker in

and another thing charge 7 in 105 depending on barrel length is usually around 9-13k at optumum traj

but chances are after looking at the junk you guys have come up with you allready know

[on the battlefield there are two types of people, targets and other gunners]

[SSG Plazmoid 0]

- UPDATE -

Well, I decided to go out and enjoy some time away from the computer but I kept this problem in the back of my mind. Had an idea on the way home and gave it a try just now. To scale the values of x and y so that a ratio that atan can handle is calculated I just needed to make use of pi/2 and -pi/2. So, here are the formulas for horizontal direction/offset with the result in degrees. This will give the direction your gun needs to face to hit a target anywhere on the map.

_x0 = getpos _gun select 0

_y0 = getpos _gun select 1

_x1 = getpos _target select 0

_y1 = getpos _target select 1

_xx = (_x1 - _x0)

_yy = (_y1 - _y0)

_xx1 = pi/(2 * _xx)

_yy1 = pi/(2 * _yy)

?(_xx1 > 0 && _yy1 > 0):_offset1 = atan(_yy1/_xx1)

?(_xx1 > 0 && _yy1 < 0):_offset1 = (atan(_yy1/_xx1)) + 180

?(_xx1 < 0 && _yy1 > 0):_offset1 = (atan(_yy1/_xx1)) + 360

?(_xx1 < 0 && _yy1 < 0):_offset1 = (atan(_yy1/_xx1)) + 180

I created a loop in a script and drove around in a tank in a circle from my "gun" and verified the values atan was giving. When I crossed a 90 degree boundary (90,180, 270,360) I watched the values that atan was creating and adjusted them accordingly so that I finally got a smooth transition around the circle from 0 - 360. The only other thing that's needed is to account for when _xx1 = 0. If _yy1 > 0 and _xx1 = 0 we know it 0 degrees and if _yy1 < 0 and _xx1 = 0 we know it's 180 degrees.

In my travels looking for answers to this question I came across some cool sites that might be of interest to some of you.

http://hyperphysics.phy-astr.gsu.edu/hbase/ttrig.html

http://www.technion.ac.il/~orenh/proweb/

The 2nd one mentions some forces acting on an artillery shell that I didn't remember and some I didn't know. Drag people have been talking about here but I hadn't considered lift and wonder if it's modeled. Also gravity is generally expressed as 9.8 m/s^2 but it's actually closer to 9.78. Unsure with the distances possible on the island if either of these will affect the flight of the shells.

- END UPDATE -

I'm trying to work through the formulas and the method of getting the horizontal offset angle (direction) is giving me fits.

the formulas is arctan (y/x) where y = y1 - y0  and x = x1 - x0 (the start/end vector components).

however this formula expects values of -pi/2 <= y/x >= pi/2 (or -1,1 are close enough) and in our usage this will only be true on the 4 diagonals (45 degrees, 135, etc). As the direction deviates from those diagonals the result of the formula is more and more wrong with the result blowing up to 360 as you approach multiples of 90 degrees.

the solution is to somehow scale the ratio down to be <=1 or >= -1. but I'm not sure how. the angle will stay the same if the x and y legs are scaled down right? I understand that you need to add 180 or 360 to the resulting angle depending on which quadrant the angle is in (0:90 = quadrant I, 270:360 = quadrant II, 180:270 = quadrant III, 90:180 = quadrant 4). If angle theta is in quadrants II or III you add 180 to the result. If theta is in quadrant 4 you add 360 to the result.

Anyhow, I'm not sure how to feed values I want to the arctangent function that will give real results. I know my ratio needs to be between -1 and 1. So if y = y1 - y0 = 10000 and x = x1 - x0 = 5 how do I scale them to fit atan?

thanks,

Plaz

[Doolittle 0]

Plazmoid, I hate to say this, but try atan2 function.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Code Sample </td></tr><tr><td id="CODE">

;Code by Doolittle

;Use of the words SINE, COSINE, and ARCTAN copyright Doolittle 2003

;pos is target

;src is artillery

_dx = ((_pos select 0) - (_src select 0))

_dz = ((_pos select 1) - (_src select 1))

_dist = sqrt ((_dx ^ 2) + (_dz ^ 2))

_dir = _dz atan2 _dx

_angle = 20

_muzzle = sqrt (9.8 * _dist / sin (2 * _angle))

_vy = _muzzle * sin _angle

_hyp = _muzzle * cos _angle

_vx = _hyp * cos _dir

_vz = _hyp * sin _dir

_shell = _type createVehicle [_src select 0, _src select 1, 2]

_shell setVelocity [_vx, _vz, _vy]

_shell setDir (90 - _dir)

<span id='postcolor'>

This works but there is the drag problem as mentioned.  The longer the shell is in the air, the more it's slowed down, the more it falls short.

Doolittle

[SSG Plazmoid 0]

hehe ah well, it was fun working through the math anyhow. As for drag we just need to figure out what the coefficient of drag they are using is and then compensate with our muzzle velocity? It should be possible to compare the difference between expected and actual impact. The difference will be larger as distance increases so we can multiply by some compensation in the muzzle formula so we would have 9.8 * _dist * something that increases with distance?

[KeyCat 131]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (benreeper @ Dec. 18 2002,23:43)</td></tr><tr><td id="QUOTE">No scripting involved other than to tell them where and when to fire.<span id='postcolor'>

Benreeper...could you please elaborate a bit more? I've got the mortars firing by using the "DoFire" instruction but they stop firing as soon you are out of their sight or take cover...

How do you tell them where to fire if you are using only the "Fire" instruction? Do you just set their direction or what?

/Christer (a.k.a KeyCat)

[Wick_105 0]

you guys ever think of using mills instead of deg???

[Doolittle 0]

Well the script commands take degrees.

[SSG Plazmoid 0]

I'm trying the trick of using triggers or markers to get height above sealevel. However I'm either doing it wrong or it's not giving me what I expected.

suggestion 1)

place a marker on the map where you want to see elevation above see level. Move marker out to sealevel

"marker_name" setmarkerpos [0,0]

height above sealevel is getmarkerpos "marker_name" select 2? Gives some random negative number close to -1.5 (maybe it changes every time I do it cause the sealevel is raising/lowering?).

suggestion 2)

place a named trigger on the map. Using trigger_name setpos [getpos object select 0, getpos object select 1, 100] should put the trigger 100m ASL so you could see the difference at that point between ASL and AGL. However it just puts it AGL :/

I looked in elevation.sqf for coc_mines:

_elevation = (acos (_range/_distance))*((({COCMinesWidget distance _subject > _distance} count [0])*2)-1);

I don't understand some of the syntax of the forumula (the 2nd part).

Anyhow, suggestions or personal results from trying either of the methods would be helpful.

thanks,

Plaz

[dinger 1]

@Wick: yeah, OFP wants degrees. In my artillery stuff (written for 1.46), I do translate that to mils for the readouts.

@SSG:

Method 2:

To measure sealevel with a trigger, do this:

name the trigger say "MyTrigger"

then

MyTrigger setpos [getpos MySpot select 0, getpos MySpot select 1]

ASL = -1 * (getpos MyTrigger select 2)

RE: This bit of code that I wrote:

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">

_elevation = (acos (_range/_distance))*((({COCMinesWidget distance _subject > _distance} count [0])*2)-1);

<span id='postcolor'>

what's going on:

I have a subject and an object in this relation. The subject is, in this case, a mine (usually a claymore). The object is a gamelogic called CoCMinesWidget. I setpos the widget to the targeting position.

_range is the two-dimensional distance between the subject and the object (sqrt (x^2 + y^2))

_distance is the three-dimensional distance between the two units (subject distance object)

(acos (_range/_distance)) will give you the elevation in degrees, but it won't give you relative position up or down.

so what I do in the previous lines there is I determine the Z component of the difference between range and distance (sqrt(_distance^2 - _range^2)), and I setpos the Widget to [currentx, currenty, +zcomponent]

now, if the elevation is negative, adding this zcomponent will make distance = range; if it's positive, adding the zcomponent will double the effective distance. so

((({COCMinesWidget distance _subject > _distance} count [0])*2)-1

this effectively uses a trick to translate a boolean value into a number (0 or 1) and then to a sign (-1 or 1)

enjoy

Dinger

[SSG Plazmoid 0]

I played around with different values for muzzle velocity at increasing distances with the gun angled up at 45 degrees.

In the formula:

_muzzle = sqrt (4.9 * _deviate * _distance / ((sin _elevated) * (cos _elevated)))

where _elevated = 45 degrees gun angle up

the columns (shown below the formulas) are the _deviate value on the left and it's associated range on the right.

For example, for a target at 250m the _muzzle velocity formula would be:

_muzzle = sqrt (4.9 * .75 * 250 / ((sin 45) * (cos 45)))

which = 47.87m/s and should hit your target dead center.

for a target at 2000m the _muzzle velocity =

_muzzle = sqrt (4.9 * 2 * 2000 / ((sin 45) * (cos 45)))

which = 197.99

0.75     250

0.76     375

0.8     500

0.855     625

0.925     750

0.99     875

1.05     1000

1.11     1125

1.18     1250

1.25     1375

1.33     1500

1.415     1625

1.51     1750

1.61     1875

1.6675     1937.5

2     2000

I've plotted the values and there is a curve but it flattens in the center (750m-1500m) and then angles sharply up as you near 2000m. The shells either timed out at ranges beyond 2000m or they disappeared for some other reason.

I'll work on the altitude above sea level example dinger offered.

[Doolittle 0]

Shells explode if 20 seconds have passed, which is why they disappear.  Or maybe they're hitting a poor bird.  

Where did you get your equation?  sine * cosine??  I'm using _muzzle = sqrt (9.8 * _dist / sin (2 * _angle)). Same result?

I was doing tests with how long the shell is in the air and how far it traveled and then comparing that to how long it should have been in the air and actually travelled (on paper).

Doolittle

[)=Obi=( 0]

Just a word as i remember ....

Drag factor is a direct function the speed (MV) as far as the structure does not modify (or melt).

The higher MV the more drag.

There's something like V^3 in the formula (AFAIR) .

I just thought you might want to keep the MV constant to keep it simpler ...

So either you include the full equation (and have to include lift and other joyfull things ) either you try to keep it to a more stable coefficient in which case I think you should try to keep the MV constant and work with angle for distance.

Although, IRL, there are different loads (as Wick said) for different distances and/or payloads.

I also wanted to say that it's already an impressive job you've done here and it's already fully usable.

[SSG Plazmoid 0]

had been using sin (2 * _elevate) but an engineer friend of mine brought over a physics book and for balistic motion the formula given used (cos _elevate) * (sin _elevate)

at 45 degrees the two formulas are the same. however as we move farther away from 45 degrees the sin and cos of the angle diverge so in angles approaching 0 and 90 degrees the result from the two formulas will differ. I haven't tested with any other angles but 45.

As for shell timeout I think my next experiment will be to recreate the shell at the top of the parabola halfway along it's journey to double the range (as someone suggested earlier in this thread).

Also was considering moving a game object along with the shell and attaching a local sound to it. Can you do this with game objects or the sounds are actually on triggers? Haven't played with it much but I think this is a way to get a nice sound going over as the shell passes.