Inkompetent

INKO Disposable Version 1.2 is out! Information: I have attempted to replicate all basic functionality found in INKO Disposable 1.2 for ArmA2. This addon for ArmA3 Alpha makes the NLAW man-portable anti-tank launchers disposable as it is in real life. After one shot the tube is spent and cannot be reused in any way. The spent tube can be thrown away after firing simply by switching weapon (default key: F). AI throws it away automatically shortly after firing. DUE TO LACKING SCRIPT FUNCTIONALITY I HAVE LIMITED CONTROL OVER THE WEAPON'S INTERNAL AMMUNITION BOTH FOR PLAYERS AND AI. PLEASE VOTE ON THIS TICKET TO HASTEN PROPER FUNCTIONALITY FOR MANY ADDONS: http://feedback.arma3.com/view.php?id=4853 The addon has full Extended Eventhandler support (and requirement). Purpose: Aside from being a simple addon for a slightly more realistic game it is in great part designed for other addon-makers. The code has been kept as simple and as modular as I have the wits to make it for the simple functionality it has now. It is fully possible to make this work with disposable launchers in other addons by adding a few variables to those launchers's config and should require no tinkering with INKO Disposable at all. Version history: v1.2 (2014-01-11): - Fixed "undefined variable _unit" error spamming RPT - Fixed AI selecting pistol over rifle after firing due to what seems to be a bug in selectWeapon command v1.1 (2013-04-02 [Alpha]): - Automatic ammunition management: No longer need to pick up missiles from boxes or the like. If you have an unused launcher you have ammunition. (Thank you Ohally!) - Code cleanup: Should use a little less resources and be more reliable. Probably not noticeable for end user. v1.0 (2013-03-15 [Alpha]): - Disposable NLAW: One use only. Throw it away when you want to by switching weapon. - Thrown tube is physical object in the world (thank you ArmA3 physics for not making it a bounce-machine!) !!! IMPORTANT !!! This addon requires the Extended EventHandlers found in CBA! Download CBA here DOWNLOAD MIRRORS: DevHeaven

Thank you, Foxhound!

Updated to 1.2! Due to Dropbox errors DevHeaven is the one alternative now: http://dev.withsix.com/projects/inko-disposable-a3/files Changes: - Fixed "undefined variable _unit" error spamming RPT - Fixed AI selecting pistol over rifle after firing due to what seems to be a bug in selectWeapon command

Dang, Dwarden! You are dangerous in that Zero!

Neat :) Wish I could help with the bouncing though, but models really ain't my thing, so no idea if anything at all can be done without new modelling tools. I'm just delighted the NLAW worked from the start.

Any link to those issues/conflicts? As for adding an AT4 I will not do it. I only plan to support weapons native to ArmA3. Then it is up to other people to either add support for this addon in their weapon-addons, or if someone makes their own compatability-addons for other weapon-addons to make use of this, despite lack of official support from that addon-maker.

The weapon is not field-reloadable like a Carl Gustav, RPG-7, or SMAW. It is however factory-reloadable, like the AT4, although I do not know how many firings a tube is expected to last for.

Thank you, Foxhound!

Apparantly the download refused to work at Filefront, so I am using Dropbox for now. This time the download should work!

Version 1.1 is out! See the main post for changelog and updated download link! This is the 'old' 1.1 that I was working on. The new changes that I am working on are over my head (an area of modding for ArmA that I've not touched before) and it'll take a while until I manage to get that to work, so until then you'll get this one to enjoy!

New release will be delayed because I will attempt to reduce the script load caused by the addon. Should hopefully be much lighter than the current version, and potentially free of the CBA/XEH requirement.

Never heard of VAC. That I need to try!

Thanks to Ohally there might be a partial solution to the ammo-problem. He seems to have found a way to load the weapon like in ArmA2 thanks to changing the config for the magazines. Doesn't make the linked tracker ticket in the OP less valid though! Edit: Having tested his solution everything seems to be working as good as it could right now. Still waiting for some additional testing before releasing 1.1.

Loyalguard's post is generally good, but please, do not under ANY circumstances whatsoever, ever, use 'null' or 'nil' or any other existing variable/value as script handles. It is terribly bad practice. Instead make up something else. For example 'foo' is a common variable name for dummy-variables.

Been trying to get BIS_fnc_taskSetState and BIS_fnc_taskHint to work, but to no avail. I can't find any functions module in the module mode/placer/browser, and I cannot find any other way I'm supposed to initialize the BIS functions module. Is it always on, or is there something that need be done to activate it?

Please post an example of the code you are trying with. Will make it easier to understand your problem.

Also the earthen walls or what they are called work well as ramparts. Those that have one side with thick wooden boards, and an earthen slope on the other.

Very sleek and nice solution. Good one.

It's actually 100x100m 'ponds' placed in a grid to cause the flooding as I've understood. Got no details on the exact way to cause it though.

Gorgeous model! Looking forward to it!

Aaaaaaawesome, BIS! Bandwidth-hogging that's always been a problem for many complex mods and mission scripts! Two of the best commands ever made!

Outright FANTASTIC! Lovely new script commands! Just getting better and better!

PURPOSE: INKO_SFS.SQF (Simple Firing Script) is designed for script-controlled fire sequences from one or more units towards the area of a specific target. Either to be used just for fixed or pre-planned fires, or just as cosmetica with anti air batteries firing into the air, etc. It is to be an all-around script that is as easy as possible to use while being as versatile as possible for the mission-maker, functioning for any kind of fires that the mission designer would want to control through script. Instead of making multiple scripts for different units depending on what and how they fire I have intended this as a one-solution-for-all time-saver. FEATURES: The script allows for the mission designer to choose what vehicle(s) are to fire, what the target (or reference point) is, in what radius around that target they should fire, and at what altitude relative to the target they should aim. In addition to that one can choose if the firing sequence should be done just once, multiple times, or infinitely, and what the delay in seconds should be between both each burst shot within a sequence, and between each repetition of the sequence. It is now also possible to decide with which muzzle the unit(s) should fire. KNOWN LIMITATIONS: At the moment mostly suitable for burst-firing weapons. Very limited burst length. Not suitable for units where you want to mix the muzzle used. FUTURE Planned additions are as follows: Make the delay more directly dependant on the weapon's reload speed/rate of fire. Create ability to fire longer salvos with automatic weapons. Dynamic (as much as possible) parameter array, making it more user friendly. VERSIONS: 1.1 Beta (2009-08-12): Added possibilty to use groups as well as units simultanously as parameter. Added choice of muzzle. Added additional variables to decide number of bursts/shots per salvo and the delay in between, 1.0 Beta (2009-07-29): First release DOWNLOAD: Fetch it here CREDITS: Written by Inkompetent. Inspired by SUPR3ME KILL3R's flak.sqs script that was released on the BIS forums. SCRIPT INSTRUCTIONS /* ========================================== = INKOMPETENT'S SIMPLE FIRING SCRIPT = = 1.1 BETA = ============================================= PURPOSE: The script is designed to let the mission maker control and simulate fire from any unit on the battlefield. It is mainly designed with AAA fire as that from ZSU-23/4 Shilkas or alike in mind, but can be used for practically any PRIMARY WEAPON in the game. This makes it unsuitable for firing with for example coaxial machineguns on AFVs and tanks, without modifying the script. INSTALLATION: Simply copy the script to the wanted mission folder in "My Documents/ArmA2/missions". USAGE: The script requires a number of parameters when executed to achieve the desired effect. ALL VARIABLES MUST BE ENTERED! All you need is one or more units to do the firing, and then either a marker, trigger, object or unit as reference point for the shooting. Call with: nul=[[obj/group array],string/obj name,[int,int],bool,[int,int],[int,int,int],int] execVM "inko_sfs.sqf"; nul=[[Firing unit(s) name(s)],"target name"/target name,[radius,altitude],refill?,[bursts per salvo,pause between burst],[repetitions,intervalmin,intervalmax],weapon/muzzle] execVM "inko_sfs.sqf"; Example: nul=[[shilka1,shilka2],"shilkaTarget1",[150,100],true,[3,1],[1,0,0],0] execVM "inko_sfs.sqf"; Above example means shilka1 and shilka2 will shoot at the marker shilkaTarget1 within a 150m radius and at 100m above sea level, regain lost ammunition, fire three bursts with one second between every burst, regain lost ammunition, only do this sequence once, and fire with it's primary muzzle. Note that target should only have quotation marks around it if it is a marker. If it is an object it should not. Also note that the main weapon of a vehicle has the index '0'. If using an endless fire sequence (repetitions=0), make sure to name the script handle something else than "nul", for example fire1=[....] execVM "inko_sfs.sqf". This way you can stop the script when you want to with the 'terminate'-command. Note that even for a single salvo you must enter a number for intervalmin and intervalmax! Thanks to SUPR3ME KILL3R for his flak-script, giving me the inspiration to make this. ========================================== */

Well, the 'suppression effect' isn't the issue here. It's calculating what AI is close enough to the bullet path for them to detect the shot. There could be several ways to do it, but I can't really think of anything resource-efficient. If the AI would be forced into Combat mode as soon as someone from the opposing side fires a shot within X meters radius, then they'd be completely broken as far as maneuverability goes, and it's a pretty tough nut to crack. If hear shots that very well could be directed at them, then they *should* indeed react on them, but if they realize they are not engaged they should more or less ignore subsequent shooting from that same area until they actually are under fire. Complex things to code.

Yeah, as Gustaffa says this does most certainly have to with server performance. They *could* make checks to see which AI the bullet passes close to, but it'd require a lot of CPU time and pretty high priority to not 'miss' detections. And when there are dozens and hundreds of bullets in the air at the same time it'd get even more out of hand. Actual bullet impacts makes it A LOT less computing-heavy. Ideally they manage to somehow make a solution that better simulates the AI recognizing being shot at, but for now we'll just have to adapt to how it is.