Search the Community

DAP is an Arma 3 script that allows the Mission Editor (you) to create real (or virtual) artillery/mortar fire-missions faster and smarter for one or multiple sides, using Eden marker’s positions and an external fire-missions list where you plan the caliber, ammo type, rounds, cycle of repetition and more. DAP doesn't change any original Arma AI behavior, saving server performance, and preserving the Arma integrity and compatibility with any mod. Why use DAP to manage artillery: unlike other scripts, DAP does not require the editor to specify artillery-pieces for each fire-mission. As soon as a fire-mission is triggered, DAP searches for artillery-pieces available at that time that fit the requested caliber, the requested ammunition-type, and have range to the target. This means that for the same target, DAP can use different pieces on the map; just as the same an artillery-piece can be used for multiple fire-missions with different targets. And DAP is absolutely scalable. How to install / Documentation: https://github.com/aldolammel/Arma-3-Dynamic-Artillery-Pieces-Script/blob/main/_DAP_Script_Documentation.pdf What you set for each fire mission with DAP: Real or virtual fire mission; The side that owns each fire-mission; Potential target sectors (Eden markers); How many artillery-pieces you want in each fire-mission; What caliber these pieces will be (Light, Medium, Heavy, Super Heavy or Combined); Ammunition type (HE, Cluster, Smoke, Flare etc); Control the volume of rounds per piece; How many repetition cycles does a fire mission have; Triggers will release the fire-mission (trigger activation, timer, kill/destruction). What you set globally with DAP: Custom callsign for each artillery side; Which piece calibers can use CommandChat to report (On/Off); Infinite ammunition (On/Off); Prevent artillery-pieces self-propelled to change position (On/Off); Prevent artillery-pieces from starting match with no magazines (On/Off); NEW! Fire-mission areas visible on the player map (On/Off); Custom cooldown by caliber among cycles of fire-mission repetition; Pre-defined whitelist of pieces working (Arma, DLCs, CDLCs, RHS, CUP, etc); Pre-defined whitelist of ammunition working (Arma, DLCs, CDLCs, RHS, CUP, etc); Pre-defined blacklist of currently bugged vehicles/static turrets; Pre-defined blacklist of currently bugged ammunition; Debug mode with simple or deep detailing; Etc… Automatically DAP Library supports content from: Arma 3; Expansion Apex; DLC Tanks; DLC Contact; CDLC Western Sahara; CDLC Reaction Forces; CDLC Expeditionary Forces; CDLC Global Mobilization; Mod RHS; Mod CUP. How DAP works technically: Before installation for advanced editors’ valuation, there's a workflow in the first pages of the documentation. Video demo: Soon! Check the file above on GitHub. Check the file above on GitHub. Documentation, link on this post header. Dependencies: None 😉 Download: - On GitHub: https://github.com/aldolammel/Arma-3-Dynamic-Artillery-Pieces-Script - On Steam Workshop: https://steamcommunity.com/sharedfiles/filedetails/?id=3371824030 Missions using it: - Soon. - - - - - - - - - - - Changelog: Dec, 6th 2024 | v1.5.2: news, fixes and notes. Known issues: - If you delete some original artillery crew (the driver, for example), it will print out an error (WIP). So, use the original crew of vehicles you want to use; - - - - - - - - - - - Video tutorials (playlist): - Soon in my secret YouTube channel hehe

Hi ! During my elimination games I noticed that mortar kills do not count as a kill, you just earn 50 points and the number of kills remains the same. Could you change this thanks.

Hello ! I was wondering if someone know how a simulate the explosion of a smoke shell from a trigger or even a mortar. Conventional smokes are too small or even ineffective... I'm making several missions with Vanilla assets where this would be very useful, like a tank which just suddenly appears from the smoke, or even several huge smoke fired from mortars to allow some soldiers to advance covered etc. I have been looking for this command/script for some time but I haven't found any solution yet. Here is a command i tried but which doesn't work: bomb="8Rnd_82mm_Mo_Smoke_white" createVehicle (getPos this); So if any of you have any ideas, don’t hesitate. 🙂

Hi there! I need a non-damaging repeating mortar or artillery fire for a beach assault. I currently am using on a repeatable trigger: bomb="M_Mo_82mm_AT_LG" createVehicle (getPos ied1); deletevehicle ied1; That is just my basic idea for an explosion. Either will work for me. But if there is a way to just spawn the shell dropping in WITHOUT damage, I would like that too. Just need the special effect. And without a .sqf file preferably. Just using triggers on repeat. Any help is appreciated. Thank you

How to reproduce : Normal behavior with HE shells 1) place a mk6 mortar with gunner 2) place a target at azimut 0 (for simplicity) and (for example) 700 m. away 3) set turret elevation to 75 deg (40/50 m. too long) and azimut 0 4) fire 3 shells : one with the mortar range finder on the target, the other one with the range finder looking at the ground, even just in front of the mortar and the third one, high in the sky. -> result : all shells land approximatively at the same distance, with the normal dispersion Wrong behavior with laser guided shells 1) Place a darter and give the gunner a drone terminal. For the test, I place the drone at a 90 deg angle between the target and the mortar, 100 m. on the right. Fly (alt. 50 m. or 100 m.), take turret control, lock on target (ctrl + t) and illuminate the target with the laser (LMB) 2) load guided shells : <mortar> addMagazineTurret ["8Rnd_82mm_Mo_LG", [0], 5]; in the debug console 3) set turret elevation to 75 deg and azimut 0 4) fire first shell with mortar range finder on the target -> result : the shell heavily corrects its trajectory and hit exactly on target 5) fire a second shell looking at the ground -> result : the shell falls 50 m. in front of the mortar 6) fire a third shell looking at the sky -> result : the shell falls far far behind HE impacts. To visualize shell trajectories : [player, 3] call BIS_fnc_traceBullets; in the debug console It clearly seems that the mortar range finder is used to acquire target coordinates. Feature or bug ? How to use laser guided shells on indirect fire in these conditions without artillery computer ? Arma 2.08.149102, no mod. Same problem with 8Rnd_82mm_Mo_guided shells (IR guided)

Hello everyone! Can you please tell me if there is a script for calling artillery by clicking on the map for multiplayer? I need that the map interface in the window be called up and that you can click on the target and that the action of calling an artillery strike can be tied to an object (for example, to a radio station lying on the table) and, if possible, a limited number of times. Thanks everyone and sorry for my english.

I've been doing some work with mortars and I have come across a very strange ( and I would suggest broken) behaviour with the MK6 mortar and the use of the command magazinesTurret and I wonder if anyone can throw some light on this as it appears that the command isn't working ( at least with the MK6) Place a MK6 mortar ( w or w/o gunner) - name it mortar1 In attributes make sure its fully armed mortar1 magazinesTurret [0] - Result > array including the 8Rnd Mo shell magazines, and flares and smoke as expected. All good. {_x=="8Rnd_82mm_Mo_shells"} count (mortar1 magazinesTurret [0]) - counts the number of 8Rnd magazines and produces the answer 4 if Mk6 is fully loaded. Now set Ammunition to 0 in attributes ( you can check that there is indeed zero ammunition if you are in the MK6.) Now run the same two code snips again. mortar1 magazinesTurret [0] - Result is array ["8Rnd_82mm_M0_shells"] !!!!!! and {_x=="8Rnd_82mm_Mo_shells"} count (mortar1 magazinesTurret [0]) - gives the result 1 !!!!!! In other words when the MK6 is completely empty of ammo the magazinesTurret command is still reporting a magazine of shells! (Note I've checked the turret path and it's correct) Anyone any ideas? Is this command broken for the MK6? It seems to be. Does it produce erroneous results for other vehicle turrets like this? Anyone trying to run rearm scripts on the MK6 or checks of ammo is going to run into significant problems with these sorts of erroneous results. Interestingly mortar1 ammo "8Rnd_82mm_Mo_shells" always seems to produce a zero 0 result even when the MK6 is fully ammoed up. I assume the ammo command just doesn't work with the MK6 or turrets? I'm looking to auto rearm mortars and this very odd behaviour is making it really hard to test ammo levels for the mortar. Ideas?

I am currently working on implementing a M224 mortar into game, I have all the basics working, rotation, elevation, rounds firing in the correct direction and all splashing within about 50m, when using the artillery computer it shows 450m > 499m. Can anyone suggest what is causing this narrow range and how to rectify it, this is currently what I have https://www.youtube.com/watch?v=dmUCX2n2MOE The current config I have is simply there for me to get the model in game to test and is inheriting from B_Mortar_01_F as I know that currently works class cfgVehicles { class B_Mortar_01_F; class 506th_weap_m224mortar : B_Mortar_01_F { scope = 2; displayname = "M224 60mm Mortar"; model = "\506th_weap_m224\models\506th_m224_mortar.p3d"; hiddenSelectionsTextures[] = { "506th_weap_m224\data\mortar\mortar_co.paa" }; }; } model.cfg When I use the Virtual Arsenal I can use the projectile tracking lines to see what the rounds are doing, By the way the rounds are going and based on the basic config I have used I am guessing that it is something wrong with the model. If there is anyone who is able to help it would be greatly appreciated

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.

Looking to make AI fire on random preset markers. I have ripped and tinkered with some bits and pieces of code. Most come from GOM's posts and replies. Here is what I've come up with: [] Spawn { while {true} do { _arty = mortar1; _target = ["target1","target2","target3"] call BIS_fnc_selectRandom; _artyAmmo = getArtilleryAmmo [_arty] select 0; _artyETA = _arty getArtilleryETA [getPosATL _target, _artyAmmo]; _inRange = (getPosATL _target) inRangeOfArtillery [[_arty], _artyAmmo]; systemchat format ["In range: %1",_inRange]; if (_artyETA > 0 AND _inRange) then { systemchat "Cleared to fire!"; systemchat format ["Impact ETA: %1s",_artyETA]; _arty commandArtilleryFire [getPosATL _target, _artyAmmo, 5]; sleep 45; } }}; But as far as I can tell, the target cannot be randomly selected. This bit here seems to break it: _target = ["target1","target2","target3"] call BIS_fnc_selectRandom; It works to fire on one position with it as this: _target = target1; The artillery fires nicely with the Do While loop and the sleep x; bit. But one other issue is that arty doesn't start firing until the sleep x time has passed. Which is a small issue in itself. Even with sleep being at the end of the code, it waits the full amount of time before firing. I thought these scripts ran top to bottom. TL;DR: Code works only for single target. I want to fire 5 shots, then pick another random preset target (target1,target2,target3,etc.) then fire 5 more with a sleep delay between barrages. Huge bonus: If someone can post a separate bit of code to fire on players current position. Once it fires, I just want it to hit where it was supposed to. As if players are running from the arty fire and if they stay still, RIP. I looked into getRelPos for players, but had no luck. Just errors.

What is CODI_MORTAR? CODI_MORTAR adds an Artillery Computer that calculates firesolutions using mortar coordinates, target coordinates and adjustments. Youtube Should I try CODI_MORTAR? If you like the basic Artillery Computer provided by Arma 3 then you might not want to try this. If you like realism and like to give indirect firesupport without line of sight then you might try this. Is it complex? It is as easy as it could be made. But there is no MapClickShit. How do I use it? There are 2 modes of operation. One for GRID mode where target location is known and a POLAR mode where a forward observer tells you his position and you adjust the target from his position. In each mode the mortar position need to be entered or you click on the first "me" button to automatically fill in the correct values of the current position of the player. GRID: By opening the map and interpolating the position of the enemy to ~10 m you enter its coordinates and aproximate height in meters into the computer. The computer calculates the firesolution which can be used in the mortar to shoot at the target. Adjust your mortar and fire. POLAR: By opening the map and interpolating the position of the forward oberserver to ~10 m you enter its coordinates and aproximate height in meters into the computer. The forward observer needs you to give the azimut to the target in degree as well as the elevation to the target also in degree and the distance to the target in meters. You need to enter all those values into the computer. If you dont, you will shoot at your forward observers position! The computer calculates the firesolution which can be used in the mortar to shoot at the target. Adjust your mortar and fire. Yeah you got me, the mortar aims 1 MIL beside and 1 MIL to low (It is the same image as in the GRID mode) If you missed your target due to wrong aiming or positions and the forward observer saw the impact he can give you an adjustment like "45° 100m". If you enter those values you might hit your target on the second attempt. YOU DO NOT NEED TO PRESS THE "Adjust DST" BUTTON!!! If your Observer has multiple corrections you can click the button to change your DST values so you can use the adjustment again relative to the last adjustment if wanted. If you are fast enough you can remember Time On Target (TOT) after shooting with charge 2 then recalculate with charge 1 (will be faster due to lower angle) and time the shots using TOT to have simultaneous impacts. The computer ignores wind. AFAIK ACE also ignores wind for large calibers. What Speed do I need to enter? Depends. Default Mortar shoots with charge 0: 70 m/s, charge 1: 140 m/s and charge 2: 200 m/s Am I high? Normally you can hit a target with 2 different angles: a low one and a high angle. Mortars have a very high minimum angle so you will probably never need the low firesolution but just in case... How to setup a mission using the script? Copy the "CODI" folder into your mission. init.sqf: [] call compile preprocessFileLineNumbers "CODI\MORTAR\preInit.sqf"; enableEngineArtillery false; if (hasInterface) then { waitUntil{!isNull player}; private _mortar = ["Open MortarComputer", "Open MortarComputer", "", {createDialog "CODI_Mortar_GUI";}, {true}, {}, [], "", 10] call ace_interact_menu_fnc_createAction; [player, 1, ["ACE_SelfActions"], _mortar] call ace_interact_menu_fnc_addActionToObject; }; description.ext: #include "CODI\MORTAR\dialogs.hpp" What weapons are supported? All that you enter in the CODI\MORTAR\preInit.sqf in the variable CODI_Mortar_weapons Keep in mind you need to enter the WEAPONclass not the VEHICLEclass! I Like Artysupport but no one likes to play Arty... Change CODI\MORTAR\preInit.sqf CODI_Mortar_fireEnabled to true. Then you can click FIRE as often and fast as you like and a shell will be created at the specified artillery coordinates. Download: Dropbox Required Addons: ACE License This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-nd/4.0/.

Hey. I am clueless. I want to make a loop for an AI mortar. The goal is to have the mortar shell a specific place every 30 seconds om e activated by a blufor present trigger. And it has to work in mp. Needless to say, as a very fresh recruit in arma I'm pretty lost. I understa d coding fairly well but this, I don't even know where to start... Thankfull for ideas or help, Ernst Alfred

Hey guys and gals, I've been working on an 120mm mortar of the german armed forces (modified Soltam K6). And I got two problems I hope your guys can help me to fix. 1. I can not get the mortar to have a firerange of min 450m to max 6350m. I tweaked around with the minelv and maxelv values but I only get strange results. Are these the right values at all? 2. As soon as I change the elevation (in game) by pressing the page up or page down keys the mortar wobbles around through the backblast - sometimes it even flips. How can I fix that? Many thanks in advance. CfgVehicles: cfgWeapons config.cpp

So after a few more tests, I'm happy to release this mod, although there are still some little errors that will pop up, in terms of the part where you may try to use math commands, everything else should be working as expected. Documentation has been included in the file, if that does not seem to help feel free to pm me or post on the thread. Feel free to post any feedback or any changes. Description and Usage Notes: Pictures Changelog Download V0.51 Dropbox Armaholic