cfgweapons Grades in CfgWeapons

[CTI player IF 32]

The author summarized this article when researching the way make Mortar weapons(both for soldiers and as structures) work well. The complete file is PDF.

Chapter 1 The grade of Classes in CfgWeapons

A class in CfgWeapons(and an available weapon in OFP) owning 4 grades: weapon, muzzle, magazine and mode. In the class Default, muzzles[], magazines[] and modes[] are all defined as {”this”} (which is a special design and will soon be discussed below), thus all subsequent classes, if no overriding the muzzles[] and modes[], will have indistinguishable weapon/muzzle and magazine/mode grade, namely one can hardly distinguish whether it is a weapon or a muzzle, neither do magazine and mode. Futhermore, with the help of scopeWeapon and scopeMagazine, a class can be used as both weapon and magazine, moreover it can use itself as its own magazine.
Knowing better about the difference among these 4 grades can help editors making better(well) defined and functional weapons. The best way to learn how these 4 grades being divided is referring to original CONFIG\BIN of OFP. GreandeLaunchers(e.g.M16GrenadeLauncher) show the way defining muzzles[] and basic rifles(e.g.AK74) show the way defining modes[]. But one must be aware not to omit some inheritance, or misunderstandings will emerge.

1.1 Priority Order

The priority order is: Weapon ≻ Muzzle ≻ Magazine ≻ Mode. We'll illustrate their relationship and introduce how "this" works.

1. A weapon can have multiple muzzles, defined in muzzles[]. The default value, {"this"}, indicating the weapon's class itself is one of its muzzles (and since there's only one element, this", in the  muzzles[], the weapon thus has only one muzzle). For"this" muzzle, all of its properties is gained from the weapon's class. Even though a subClass whose name is same as the weapon's defines a muzzle, it'll be ignored by "this". Very few weapons override this parameter. Pressing spacebar(the default Toggle Weapons key) to switch muzzles. By the way, the {”Throw”} weapon will appear after having scrolled through all muzzles if it has loaded a magazine like handgrenade.
2. A muzzle can load multiple magazines, defined in magazines[]. The default value, {"this"}, indicating the class itself is its specific magazine. The author call attention here that, if the magazines[] is defined under a muzzle's subClass of the weapon, then in this case the {"this"} indicate the muzzle's subClass but not the weapon's class. Many (but not most, at least in CONFIG\BIN) weapons override this parameter. It’s necessary to use the Action List to switch different magazines of same muzzle(e.g.Reload Mortar).
3. A magazine can have multiple modes, defined in modes[]. The default value, {"this"}, work similar as mentioned about muzzles, because there aren't such a definition "muzzle-magazine-mode" like "weapon-muzzle-magazine" does. Many weapons override this to gain various mode(i.e.Single, Burst, FullAuto, etc). Pressing spacebar to switch modes. Muzzles’ switching will happen when having scrolled through all modes of the magazine loading by the muzzle now(one can recall the way M16GrenadeLauncher works).

1.2 Parameters

Parameters are mostly available to one of the grades. Because of being defined as {”this”}, parameters for weapon in a class is also available to its muzzle(s), magazine(s) and mode(s), so be parameters for muzzle and magazine, if no overriding.
Referring to original CONFIG\BIN of OFP one can clearly know about the grades whom the parameter is working for. Here lists some parameters that are representative or hard to recognize their employer by just reading CONFIG\BIN.

1.2.1 Mode Parameters

1. ammo
   Although ammo seems to be the parameter to the magazines[], it’s mode’s parameter. Mode inherit ammo from its class via {”this”} if no overriding.
   A magazine can shoot different bullets They share same ammunition of that magazine. One can learn how different bullets works for multiple modes in one magazine(e.g.AK74).
2. sound[]
   It is the mode’s sound that decides the shooting sound.

1.2.2 Magazine Parameters

1. InitSpeed
   Deciding the initial speed of bullet it shoots.
2. count
3. modes[]
   The modes is magazine’s parameter deciding its modes. Those no override modes classes using themselves as their own mode and some parameters(e.g.ammo and sound mentioned above) are used as mode’s parameters.

1.2.3 Muzzle Parameters

1. aiDispersionCoefX, aiDispersionCoefY
   Deciding the aiming accuracy requirements. The higher value, the more roughly aiming accuracy will AI shoot at.
   Big aiDispersionCoef value can be applied for those situation unnecessary to ask AI aiming accurate enough(e.g.artillery support via MG or Shell, or guided missile launcher).
2. reloadMagazineSound
   The reloadMagazineSound is neither parameter of weapon nor of magazine. Muzzles ofen inherit from existed weapons hence inherit their reloadMagazineSound[],
   thus in no muzzles of CONFIG\BIN can one see the override of reloadMagazineSound[], however they’ve been defined in those base class.
   Both M16GrenadeLauncher and Kozlice are good example for this.
3. optics(...) and modelOptics
4. drysound[]
5. magazines[]
   The magazines is muzzle’s parameter deciding its magazines. Those no override magazines classes using themselves as their own magazine and some parameters are used as magazine’s parameters
   An example of overriding muzzle’s magazines[] is M16GrenadeLauncher, whose M16Muzzle’s magazines[] isn’t including ”Mortar” thus can’t use Mortar.

1.2.4 Weapon Parameters

Those parameters displayed in M16GrenadeLauncher class are weapon parameters. Those Greande Launchers, besides with Kozlice, don’t inherit from the class Default, thus it must defines all necessary parameters not included by muzzles. The muzzles[] is weapon’s parameter and those no override muzzles classes using themselves as their own muzzle and some parameters are used as muzzle’s parameters.

1.2.5 Some General Parameters

1. displayNameMagazine, shortNameMagazine and displayName
   The displayName is effective to mode, muzzle and weapon. Name shown in the left upper corner are mostly mode’s name. Muzzle’s name will be seen if one drop all magazines of some muzzles(or, using ”removeMagazine(s)” command to remove magazines. Exhausting all bullets will still remain the last magazine in weapon thus won’t effect in this case). As for weapon’s name, it’s shown in the Action List in the bottom right-hand corner(e.g.Drop M21 or M21 on back) or in notebook.
   The displayName is invalid to magazine. The magazine has its own parameter displayNameMagazine and shortNameMagazine.
2. picture
   If a class don’t override the picture, namely its picture = ””, then OFP will search picture from DTA\DTAEXT by class’s name, for weapon’s and magazine’s picture shown in notebook. Since fles in DTA is unique, compatibility will be bad if editors customize the DTA\DTAEXT for their weapons in AddOns in their MOD.
   Thus it’s necessary to override picture for weapon and magazine, and define weapon and magazine respectively, unless you don’t care how their pictures shown in the Gear page of the notebook.

Chapter 2 Application on Mortar and GreandeLauncher

2.1 Infantry Mortar

The main purpose of this research is trying to solve the infantry Mortar’s problem. AI SELDOM shoot Mortar after player(as group leader) having asked them reload the Mortar and targeted an enemy, and NEVER reload Mortar autonomously. According to the author, there’re two incomplete design of OFP resulting in this.

1. AI will switch weapons, muzzles and modes to respond actual requirements of the battlefeld, but they only won’t select appropriate magazines. However the Mortar is one(but not only one) kind of magazines to M16, M4 and XMS.
2. The way AI use Mortar is in common with tank gun(decided by ammo’s simulation, ”shotShell”. Actually all subsequent class of GrenadeLauncher in original OFP using ammo whose simulation is ”shotShell”), the arc trajectory is owing to low InitSpeed. However the calculation of low-InitSpeed-shell’s trajectory in OFP is inaccurate.
   For example, M60 is easier to miss the target than M1A1, the former using Shell105 whose InitSpeed is only 900 while the latter using Shell120 with 1500 InitSpeed. And, the InitSpeed of GrenadeLauncher and Mortar is respectively 60 and 70, hence although AI aiming a target, he probably thinking he hasn’t readied to fire;
   Some players may have noticed that AI will shoot Mortar when lying down or standing up. Here is a hypothetical raised by author, that AI can hardly thinking himself ready to fre, but in the progress he lying down or standing up the position of his muzzle changes continuously, thus there exists a position that the end of trajectory coincide with the target(intermediate value theorem) and AI hence fire.

Hence the corresponding solution are respectively making a weapon using the muzzle, not the magazine, to shoot mortar, and reduce the difficulty for AI to be ”Ready to fire”.

1. Simply referring to M16GrenadeLauncher to write a M16MortarLauncher. Define a MortarMuzzle for it, inheriting M16.
2. Set MortarMuzzle’s aiDispersionCoefY = 2(default value for GrenadeLauncher), define another Mortar magazine whose InitSpeed raise to 200 and set it as MortarMuzzle’s magazine.
   High InitSpeed may cause AI miss the target. But at least they’ll shoot, and the accuracy isn’t so bad.
   Keep InitSpeed unchanged and raising aiDispersionCoefY only to a big value can let AI shoot mortar too, but the accuracy is terrible.

Note: There’s an unknown phenomenon. The Mortar class override its modes[] to {”this”,”this”}. If change modes[] to {”this”}, like the definition in class Default, then AI won’t shoot default OFP Mortar(magazine), and the MortarMuzzle above will crash the game.

Raising InitSpeed will make the mortar able to fly far. The range AI will attack is limited by maxRange, a parameter of the ammo, hence unnecessary to worry about that this modifcation will affect the range AI using Mortar. But player surely know how to utilize the high InitSpeed and how to gain those special MortarLauncher from AI. Luckly in 2.01 by [4RTech] there are the createShell and setVectorDirAndUp command. Editor can hence set a Fired-EventHandler on player, detecting the high-InitSpeed-Mortar-Magazine and gaining MortarShell’s position and velocity, then create a MortarShell with classic InitSpeed(70) instead.

Here is a videw show the way mortar used by soldiers.  Soldiers using M16 muzzle when mission start and will select the Mortar muzzle to attack. They will also use M16 muzzle shooting at enemys alone and not too far away(00:01:01).

2.2 Infantry Greande, Structure Grenade/Mortar Launcher and Vehicle Grenade/Mortar Launcher

The maxRange of Grenade is 150, while MortarShell is 450. The way raising AI’s utility of Greande is similar to Mortar while the InitSpeed unnecessary to use 200.
In addition, last section only discussed infantry weapons up till now. There exists a Mortar structure used in XR CTI mission and a Grenade structure in TZK SE mission. Structures can’t move or standup /lie down like soldiers do, and it looks like that the aiDispersionCoefY almost meaningless to structures. As a conclusion, the only way for Grenade/Mortar structures is to raise the InitSpeed(verifed), and to adjust corresponding Structures’ Fired-EventHandler and minElev parameter in class Turret.
As for vehicles, since they can move freely and their weapons don’t have to perform ”reloadAction” when reloading ammos, probably simply raising aiDispersionCoefY for moveable vehicles would be a better choice, without changing the InitSpeed(not verifed yet! If proved infeasible one may imitate the way how to adjust structures mentioned above).

Here is a video show the way mortar used by structure. Not accuracy enough, though, but the shell is actual, not created by script.

Edited April 11, 2020 by CTI player IF
Correct some info and adjust the link.

[CTI player IF 32]

On 12/24/2019 at 3:19 AM, CTI player IF said:

modes[]
The modes is magazine’s parameter deciding its modes. Those no override modes classes using themselves as their own mode and some parameters(e.g.ammo and sound mentioned above) are used as mode’s parameters.

On 12/24/2019 at 3:19 AM, CTI player IF said:

Note: There’s an unknown phenomenon. The Mortar class override its modes[] to {”this”,”this”}. If change modes[] to {”this”}, like the definition in class Default, then AI won’t shoot default OFP Mortar(magazine), and the MortarMuzzle above will crash the game.

It's necessary to state modes[] in a muzzle. Elements ofmodes[] in muzzle can be {"this",...}, that is, unnecessary to assign an actual name, and classes of those modes[] isn't required here. However the number of modes[]'s elements in muzzle's statement here must be no more than the elements' number of anyone of its magazines, or game will immediately crash when someone shooting at extra mode. On the other hand, if elements' number of modes[]'s statement in muzzle less than some magazines' modes, extra modes of magazines won't be used by that muzzle. Thus it's necessary to matching muzzles and magazines according to number of modes[]'s elements.

 

It is seems possible for editors to design an “Inferior” muzzle which has less "modes[]" than some of its available magazines. For example, design an muzzle for AK74 magazine but with only 1 element in modes[], then this muzzle can only shoot AK74 single, the burst and full-auto mode are invalid for that muzzle. However a muzzle seems unable to reload a magazine whose modes is more.

[CTI player IF 32]

Quote

However the calculation of low-InitSpeed-shell’s trajectory in OFP is inaccurate.

The 60 InitSpeed is suitable for GreandeLauncher, within Grenade's maxRange 150 meters. So do HandGrenade. However the 70 for Mortar is awkward, AI can hardly shoot it in close range and can't shoot so far as set in MortarShell's maxRange, which is 450 meters. AI will shot the InitSpeed-60 Mortar when close, but since the InitSpeed is the magazine's parameter, not mode's, editors aren't able to define different Mortar muzzles/modes with different InitSpeed and sharing same magazine.

 

[CTI player IF 32]

There is a new command GetWeaponParamArray in 2.01 Arma Resistance by [4RTehch]. With the help of this command (and another command magazinesArray) it's possible to check more precisely whether a unit is out of ammo for a specific weapon. One can gain available magazines first (by picking up magazines with some ammunition from magazinesArray), and check whether some of them are in the magazines[] of that weapon.

However not all weapons having a "magazines[]" parameter (e.g. GrenadeLaunchers and other weapons defined in some MODs). But all weapons must have muzzles, and all muzzles must have magazines. Thus one should gain muzzle list by GetWeaponParamArray first, and gain their magazines then. Be cautious, the magazine parameter of muzzle probably reuqiring using GetWeaponSubParamArray, because of most muzzle won't keep its name same as the one which it derived from.

 

More applications can be found in the topic of the author's CTI project.

Edited April 11, 2020 by CTI player IF
Add link to the TZK topic.