Directly Artillery Module (of shotShell)

[CTI player IF 32]

In this topic I will display a simple design of Artillery Module. The "directly" in the topic means the artillery support is created by vehicles' directly shooting and the trajectory of shell strictly follows OFP original rule (namely airFriction is -0.0005*v^2 and gravity is 9.80665m/s^2). The "shotShell" in the topic means the CfgAmmo objects applied in this module have same "simulation" value: "shotShell".

 

The (physical) rule (simulated in OFP) of "shotShell" is simple and totally known by now (August 17th, 2020), while rules of "shotRocket" or "shotMissile" are more complex and still remain unknown parts. See

for more information. By motion equations one can solve the final range basing on initial data (direction and length of velocity vector and difference in height. The topography should be taken into consider when necessary, remain to readers), but the ODEs don't have elementary function solution, and I failed to build an appriximately one. The problem is "Cauchy Problem", we solve the final data basing on initial ones. And it's hard to solve conversely problem, like that we've known the range and difference in height between shooting position and the being attacked position, it's hard for us to solve the initial velocity, especially when we're still lacking of analysis solution of the ODEs.

(Actually we can solve converse problem as an "Cauchy Problem" as well. If we know the final velocity and position, we can take converse velocity as initial velocity, and solve the ODEs whose form is totally same as 

while the coefficient shoult take "minus airfriction", namely if airFirction is -0.0005, the coefficient in converse problem should be +0.0005. However, mostly the final velocity is unknown. We might wish to solve the initial velocity basing on known range, which, however, provides only position information but not velocity.)

 

I thus applied the numerical method in 2 aspects:
1. Use RK4 (Runge-Kutta-4-order) method to solve the ODEs and obtain final position/velocity. The time step is set as 0.05. This value is accuracy-and-efficiency-balanced one, with few meters' error. If set 0.1 then error will reach more than 10 meters with only half time cost, and set 0.01 can obtain precise result with no more than 1 meter error, but cost 5 times computation.
2. The relationship between elevation difference and range difference is locally linear (see figure below, which is a graduation of a initSpeed 180m/s weapon on elevation 15°~30°),

and "Newton method" can thus be applied. Given Proper initSpeed and elevation, one can obtain precise enough range with no more than 4 meters' error by at most 5 iterations.

The Proper elevation is provided by OFP vehicles in my Artillery Module. Roughly speaking, I designed a model for "target" object, and ask AI vehicles aiming at it. OFP will provide a predicted elevation when aiming, this elevation is precise only when initSpeed high and distance low, but it's enough as a "initial value" in iterating. The "Newton method" calculates the range basing on this initial elevation, and plus 1° (or -1° , depending on whether the range is less or more than actual distance between the vehicle and target. Mostly the range given by initial elevation is less) then calculates another range. Due to the locally linear relationship, a new elevation can be calculated by these 2 elevations and ranges, following a new range obtained again by RK4, which ends the first iteration. The terminate condition can be either that error no more than a threhold (like 4 meters) or having iterated 5 times (5 times is enough if initSpeed and elevation is proper, at least in OFP for shotShell). The error is defined as the absolute value of difference between iterated range and actual range.

3 videos displaying its effects:

 

 

 

 

See more details below.

Edited August 18, 2020 by CTI player IF
Fill a picture.

[CTI player IF 32]

Target Object

The target object should have actual model. Game Logic, Trigger and Invisible Heli H don't have model and are thus improper.
Self-defined target model should consist of 3 parts: Resolution LOD, Geometry LOD and Memory LOD. In Resolution LOD we can use "data\clear_empty.paa" to make it invisible. In Geometry LOD we can set vertices' z-coordinate few meters less than 0 to make it stay below the land. In memory LOD we can define the "zamerny" selection to make AI aiming it more precisely, but the more important function is the object can be better detected if we define vertices far from the center in Memory LOD, which won't have visible and colliding significance but will make AI spot it much more easier.

Another related example is "gun-recoil" animation applied in some tanks of AddOns. In OFP there's no "transparent" but only "rotation" type of animate, thus the "gun-recoil" is realized using long axis whose center is away from model in memory LOD. Such a design will make the tank easier to be detected comparing with BIS tanks. More precisely, these tanks will be detected in the distance few hundreds meters more than BIS tanks. This design applying to target object will make vehicles able to reveal the target within viewDistance. In the out of viewDistance case, it requires other units belonging to same group of vehicles to help spotting the target.

 

And it's important as well to keep the target "alive". In 2.01 ArmA:Resistance one can apply "allowDammage false" command to make it invincible, and in 1.99/1.96 we need to use scrpits keep on set its damage 0. Readers might have noticed that in OFP destroyed objects won't appear in 2-target list, and actually destroyed objects can't provide precise "target" for AI to aiming at.

 

Target Assigning

A convenient method assigning target position is via onMapSingleClick. It'll be visible-friendly if prepare some markers as well, in 2.01 the "createMarker" is supported and thus markers can be dynamically created in-game, but in 1.99/1.96 we must place markers in mission.sqm.
In my sketchy artillery module the "dispersion" is supported as well. The center position is provided by target object/marker, and a script-local target object is created and place randomly near the center position. Local target's position will change as analogue of "dispersion" and will be removed when script ends.

 

(Fired) Event Handler
As introduced in the first floor, the initial data of shell is required, and a corrected data is then calculated and should be applied on the shell to reset its data.
As far as I know, the only method catching the shell is the Fired EventHandler. Editor may try to add the EventHandler on the beginning of the script, and remove it in the end. However, in OFP the index of EH dynamically added/removed in-game is clumsy. If we remove No.3 EH, then all EH whose index more than 3 will minus 1, namely EHs can be treated as elements of a Dynamic Array and the index coincide to the element index, which is changeable in-game and will lose control if several scripts execute the "removeEventHandler" command.
Thus the EH should better be designed as immediately-discard one, like AT4 launcher. My method is:

1. Use "addEventHandler" to add an empty EH to obtain its return value, the index.
2. Immediately remove the EH.
3. Immediately add actual executing Fired EH whose index is same as just obtained one. Such index is contained in the code of this EH. In the beginning of the EH script the EH will be removed at once.
4. The "fire" command will be executed right after the "addEventHandler" command.

Such a design make "removeEventHandler" command appear only in Fired EH script but not main artillery module controlling script. Editor thus don't have to worry about problems caused by plural artillery scripts. However there're still a defect. Although the "fire" is executed right after "addEventHandler" command, vehicle won't shoot in some cases, which still remain possibility of EH index errors.

The EH will catch the shell, obtain initial data and do some calculation. Below is its content, for reference. The "RK4_Range.sqf" accept vx, vy and different in height to calculate the range (meters).

Spoiler

; args: [Fired EH Array, actual target <object>, EH index]
_vehicle = _this select 0 select 0
_ammo = _this select 0 select 4
_posTarget = _this select 1
_ehRev = _this select 2; _vehicle removeEventHandler ["Fired", _ehRev]
_shell = nearestObject [_vehicle, _ammo]; _posShell = getPosASL _shell; _velShell = velocity _shell; _speed = (speed _shell) / 3.6

_distX = [_posShell, _posTarget] call funcDistH
_deltaY = (_posTarget call funcHASL) - (_posShell select 2)
_vx = sqrt ( (_velShell select 0)^2 + (_velShell select 1)^2 ); _vy = _velShell select 2; _theta0 = _vy atan2 _vx
_range = [_vx, _vy, _deltaY] call loadFile "Common\SQF\RK4_Range.sqf"; _error0 = _range-_distX

? abs _error0 > _distX*0.5: _vehicle groupChat "Improper initial speed/direction. Shell deleted.", deleteVehicle _shell, exit

_step = [-1, +1] select (_range < _distX); _theta1 = _theta0 + _step; _vx = _speed * cos(_theta1); _vy = _speed * sin(_theta1)
_range = [_vx, _vy, _deltaY] call loadFile "Common\SQF\RK4_Range.sqf"; _error1 = _range-_distX

_theta = (_error0*_theta1 - _error1*_theta0) / (_error0 - _error1)
? _theta > 90 || _theta < -90: _vehicle groupChat "Improper initial speed/direction. Shell deleted.", deleteVehicle _shell, exit

; ? dev: player globalChat format ["%1, %2, %3, %4", _range, _error1, _vx, _vy]

_i = 0; _try = 5
#Newton_Loop
_vx = _speed * cos(_theta); _vy = _speed * sin(_theta)
_range = [_vx, _vy, _deltaY] call loadFile "Common\SQF\RK4_Range.sqf"; _error = _range-_distX
; ? dev: player globalChat format ["%1, %2, %3, %4", _range, _error, _vx, _vy]

? abs(_error) > 8 && _i < _try: _theta0 = _theta, _theta = (_error*_theta1 - _error1*_theta) / (_error - _error1), _theta1 = _theta0, _error1 = _error, _i = _i + 1, goto "Newton_Loop"

? abs(_error) > abs(_error0): _vehicle groupChat "Improper initial speed. Shell deleted.", deleteVehicle _shell, exit

_angle = (_velShell select 1) atan2 (_velShell select 0)
_velShell = [_speed * cos(_theta) * cos(_angle), _speed * cos(_theta) * sin(_angle), _speed * sin(_theta)]
? !bool_TZK_199_Mode: _shell setVectorDir _velShell
_shell setVelocity _velShell; _shell setPosASL _posShell

Iteration data:

Fire command

The format of this command is <vehicle> fire <muzzle>. This command will work once the vehicle does have assigned muzzle, but it won't "shoot" if it hasn't gunner or the muzzle isn't loaded, and will "shoot" immediately once has gunner and muzzle has loaded. More important, this command isn't cancelable, and if the condition improper on the moment when the code is executed, AI gunner will aim at the minimum elevation until having "shoot".
Thus the main artillery script should manage the delay of "fire" command. The reload time is decided by reloadTime of MODE and reloadTimeMagazine of MUZZLE, and is affected by the skill of gunner as well. In 1.96/1.99 we can only assign some constant in script or as global variable defined by mod or mission. In 2.01 it's possible for us to know more about weapon/magazine parameters, but still no commands to know whether a muzzle is "loaded". Maybe such functions have been supported by FWatch, not verified.