Search the Community

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. 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. 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). 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 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). sound[] It is the mode’s sound that decides the shooting sound. 1.2.2 Magazine Parameters InitSpeed Deciding the initial speed of bullet it shoots. count 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 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). 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. optics(...) and modelOptics drysound[] 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 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. 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. 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. 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”. Simply referring to M16GrenadeLauncher to write a M16MortarLauncher. Define a MortarMuzzle for it, inheriting M16. 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.

Hey,i am new to scripting and changing configs and this is my first try at it.I am trying to add a target lead indicator,like the ones you see in Cheetah and Tigris to other vehicles with electronic turret optics.Now i digged in through CfgWeapons info and saw that i just had to change the value for "ballisticscomputer" in CfgWeapons.But the problem is,......where is the location of CfgWeapons,under what pbo does it exist? I went and opened the config.bin of Prowler and there is nothing called CfgWeapons there either. The "ballisticscomputer" value that i want to change should be under "HMG_127_LSV_01",but can't find the location of it

Gentlemen, I am looking for a way to pull one array each for Uniforms, vests, backpacks, headgear and so on from configfile, similar to below example for weapons. I would like to pull all equipment items, and then pick out all uniforms or vests or.... (whatever group of items that I want to make an array for) by filtering it by the "parent" name. (eg, below example "if "rifle" in _parents) Now I tried to find the correct parents in config viewer by placing an uniform in eden editor and then rightclick + show in config viewer, but i think i get the wrong parents there (maybe just the vehicle for the placed uniform / "groundweaponholder"?) Anyway none of the parents work and i wonder where i am going the wrong way. For backpacks for example, I selected a backpack from the cfg vehicle list in the config viewer and found the parent "Bag_Base" (or something like that) and it would return an array of backpacks, however, many of the backpacks would contain items. Is there a way to avoid this? In the end I only want each array to contain empty vests/uniforms/backpacks. I think my problem is that I use the wrong method to search for an example classname in config viewer and therefore it provides me with wrong parents. I would appreciate any help or guidance in that respect;) Thanks VD

So basically, I am writing my own loot script. It works completely fine, I just have now to populate the loot arrays. I am trying to make this 100% customizable, so every different item type has a different spawn chance. For basic things like Primaries, Handguns or Launchers is simple ie. _launchers = "getnumber (_x >> 'type') isEqualTo 4 AND getnumber (_x >> 'scope') isEqualTo 2" configClasses (configfile >> 'CfgWeapons'); But all items like for example uniform, vest or backpack share the same type 131072 But I would like to filter them out by their ItemInfo, because for example a Vest has ItemInfo >> Type = 701. So I was thinking of doing something like this, but it does not work :/ _vests = "getnumber (_x >> ItemInfo >> 'type') isEqualTo 701 AND getnumber (_x >> 'scope') isEqualTo 2" configClasses (configfile >> 'CfgWeapons'); Any help would be really appreciated, Thanks.

Hello, For some reason, I made an Item and I want to forbid people from dropping that Item As it's a cfg weapon I tried to use canDrop = false : I've also tried to put it outside the iteminfo sub class Am I doing something wrong ? Or is it broken ? Do you know any other way to achieve what I want ? (also, am I allowed to do what I did in the "model" line ?) Thank you

I wonder if it is possible to get the initial speed of a bullet before shooting it. I think about writing an aiming help for moving targets where a crosshair is drawn at the point that u have to shoot at to get a hit.