Search the Community

ADAPT SILENCERS TO COMBAT/STEALTH SITUATION Hi all, Did you remark that AIs don't adapt their muzzle sound suppressor (silencer) with the ordered situation (STEALTH / COMBAT)?. Here is a little code for adding/removing existing silencer on current weapon. Notes: - by "existing", I means the silencer must be on weapon or inside unit's gear. Furthermore, as you can start with an already equipped silencer and no more room in gear, this script will record that in a variable and will be able to re-fit the silencer on weapon instead of losing him due to the lack of room. (a kind of extra pocket). - MP compatible but I intentionally worked at idle for better performance. If your unit's localization (PC owning it) is supposed to change, You'll need to make the variable broadcast (adding true as 3rd parameter). And, that's for the specific case your unit need the "extra pocket". - players are not concerned, but it's easy, for automatic adapted muzzle, to remove the isPlayer condition. - for performance, this script is not "on each framed". It could be. I chose to fire the code using the "animChanged" EH. In some cases, the unit can start to fire without changing its animation. So, try to order the new behavior in advance (Anims often change anyway). - some silencer can be non-removable, hard-coded with model, or simply don't exist! There is nothing to do with that. It's up to you to choose the right weapon. Tested on Vanilla and CUP. For other mods, have your own test. This will depend on how silencer classes are named. version Nov. 20th 2018 parameters: NONE { _x addEventHandler ["AnimChanged", { params ["_unit","","_silencer"]; if (!isplayer _unit) then { if (isnil {_unit getVariable "MGI_silencer"}) then { _unit setVariable ["MGI_silencer",[]] }; _silencers = (items _unit select {["_snds",_x] call bis_fnc_instring}) + (weapons _unit apply {_unit weaponAccessories _x param [0, ""]} select {_x != ""}) + (_unit getVariable "MGI_silencer"); call { if (behaviour _unit == "COMBAT" && {isNull objectParent _unit} && {_unit weaponAccessories currentMuzzle _unit param [0, ""] != ""}) exitWith { _silencer = _unit weaponAccessories currentMuzzle _unit param [0, ""]; call { if (currentWeapon _unit isEqualTo primaryWeapon _unit) exitWith { _unit removePrimaryWeaponItem _silencer; }; if (currentWeapon _unit isEqualTo handGunWeapon _unit) exitWith { _unit removeHandGunItem _silencer; }; }; call { if (_unit canAddItemToBackpack _silencer) exitWith { _unit addItemToBackpack _silencer; }; if (_unit canAddItemToVest _silencer) exitWith { _unit addItemToVest _silencer; }; if (_unit canAddItemToUniform _silencer) exitWith { _unit addItemToUniform _silencer; }; (_unit getVariable "MGI_silencer") pushBackUnique _silencer; }; }; if (behaviour _unit == "stealth" && {isNull objectParent _unit} && {_unit weaponAccessories currentMuzzle _unit param [0, ""] == ""}) exitWith { {_unit addWeaponItem [currentWeapon _unit,_x]} count _silencers; _silencer = _unit weaponAccessories currentMuzzle _unit param [0, ""]; if (_silencer in (_unit getVariable ["MGI_silencer",[]])) then { _unit setVariable ["MGI_silencer", (_unit getVariable "MGI_silencer") - [_silencer]]; } else { if (_silencer in items _unit) then {_unit removeitem _silencer}; }; }; }; }; }] } forEach (playableUnits + switchableUnits);

DynamicCamo (Updated Version 1.5 ) 17/5/19 What does it do? It takes account of players stance, uniform and environmental factors to adjust the players and/or AI unitTrait CamouflageCoef and audibleCoef A low camouflageCoef and audibleCoef gives greater camouflage to the unit and makes it harder for ai to see and hear you. Units appear to be created with camouflageCoef set t0 1 as default. This script dynamically resets this depending on a number of factors. It does this each time player changes stance and at set intervals. This is not just a "stealth" or Ghillie script and will provide camo benefit in all infantry combat. No distinct handling of urban environment at this time. Maybe later. Why? Player may feel AI are not sufficiently impaired in detecting player by factors such as uniform camo, light level, rain, Overcast level, Fog, and Wind, and Trees, Bushes and rocks near player. Script allows player to determine what impact these factors will have on AI ability to detect player or ai unit by sight and sound. It does not alter AI ability to detect movement. When the script is run on an ai unit it impacts the ability of other ai iunits to see or hear that uit depending on environmental factors etc just as for player. What influences the Dynamic Camo? Units stance, units uniform, Fog, Rain, Overcast, light level,wind and bushes or trees and some other objects ( rocks, telephone poles so far) adjacent to unit. Changes happen automatically on change of stance (a minimum 3 second cooldown is built in.) and at scheduled intervals of around five seconds. Can the effect be adjusted ? User can adjust impact of the Dynamic camo by passing the range for the impact for both caounflageCoef and AudibleCoef . These are passed as arguments when calling the script. See guide to adjusting the effect. Installation Copy script as camoscript.sqf to mission folder. In player init ( and/or the init of any other ai unit you want to have dynamicCamo running on) put camo = [this, "DEBUG", 0,1,0,1,5] spawn compile preprocessFile "camoscript.sqf"; will run script in DEBUG mode with a five second recalc delay and a full effect.. Remove DEBUG to turn off and just play. IMPORTANT - the script monitors keys associated with stand/crouch and prone through the use of User1. It will work if you don't do this but you will only get the automatic calculation every five seconds and not the additional stance change triggered recalculation. Go to the menu - controls>custom controls > User1 and ensure you set both the prone key AND the crouch stand key for User1. ( usually z and x keys) If you want to use a different User number select User2... User20 as desired, set keys as stated and change User1 to your desired User,n in script. USE You don't need to do anything other than occasionally crouch, stand up , go prone and watch the different camouflageCoef that is being set for you. Try at night V day, with and without rain, fog etc and watch result. In general I am trying to adjust the impact of the various factors so that they combine together sensibly. User can adjust impacts via linearconversion. If anyone doesn't understand anything please ask. Script prints calculated values when DEBUG on. A BRIEF GUIDE TO ADJUSTING THE EFFECT - NOTE 1- It takes quite low values of camouflageCoef to make detection quite hard so this version comes with the factors and the result scaled towards that direction. 2 - I am tuning the impact of factors as the script develops. If you want to try your own tuning try the graph calculator link below then adjust linear conversion output ranges or specific values ( eg for stance) as required. The values currently in the script give a fairly good out of the box result though. Further Development Plans 1) make specific calculation for audibleCoef- done.2) weighting for unit being near bush(s) - done 3) same for tree(s) 4) parameterise adjustables so that they are supplied by array? done 5) handling of weighting for uniform ( ie ghillie suits etc) done ( may upgrade further) 6) test and weight for inside building 7) useable for squad and other ai. (partly done) 8 ) consider MP and JIP compatibility. Version/ Update Notes This is an annotated fully working version. I trust the annotations make the script self explanatory. Version 1.1 - included setting of audibleCoef. Make unit harder to hear. Separate scaling of effect for audibleCoef to allow user to define how much they want impact on audibleCoef. Version 1.2 - handling of light level significantly improved around dawn and dusk. Light level impact adjustable via linearconversion. Version 1.3 - audibleCoef calculation now uses specific factors which can be weighted separately from those for camouflageCoef. Other tweaks include adjustment of range values Version 1.4 - 1) script now auto recalcs every 5 seconds as well as on stance change. Soldier can keep lower stance camo max five seconds on bob down and up. 2) calculated values shown by systemchat and hint for camouflagecoef , audiblecoef and number of trees/bushes/hides found in 2m radius. Turn of by setting DEBUG to empty string in call ie camo = [this,"DEBUG"] spawn etc. See installation. 3) calculation now influenced by near proximity of trees bushes and hides to player. 4) sleep after stance change calculation shortened to 2s for better responsiveness. Version 1.5 1) script now has parameters which can be passed to it allowing easy adjustment of Dynamic Camo impact. See USE. 2) Script now gives different DynamicCamo depending on uniform type. 3) Script works with ai to ai. Ai running the script benefit from DynamicCamo. 4) Recalc interval can be specified per instance of the script. The Script - The script was starting to clutter up this first post so I have removed it. The script is available via the download link for the test scenario at the bottom of this post. If you have any problems getting it from there let me know. All comments welcome. I set up this graphical calculator to show how the function works - just mess with the sliders. https://www.desmos.com/calculator/buiia4zs2j Test scenario mission with v1.5 https://www.dropbox.com/s/xf6x34963ixjue0/camouflagescript.Altis.zip?dl=0 Watch camo level change on stance change. Watch values change as you move about (script in this version also shows opfor man knowsabout unit value with debug set.) Try to escape across the patrolled fields. For me the effect is a bit strong at this point but you can change values in script call. See adjusting the effect above. Make sure to set User1 keys to x and z as instructed above before playing or recalc on stance change wont work. Sept 2022 - Now available on steam Workshop as a MOD whcih autoruns on player unit at teh start of any scenario, ,mission etc with standard settings giving a reasonable camo impact. THis autorun dynamic Camo can be stopped and mission makers can still use their own parameters or mess with debug mode using the mod.

Two things happen when you kill your own teammates: 1, your team opens fire on you and 2, in most single player missions, BIS_fnc_endMission is called Do you think it would be possible to create an addon that patches out this behaviour? So you can literally do what you want to your own team mates with no repercussions, sort of like how you could shoot marines in Halo?

hey guys, new to scripting. I'm using this in the init for all the waypoints I want the heli to escort the rest of the squad. "_veh setUnloadInCombat [false, false]; thisArray; [_soldier1, _soldier9] allowGetIn false;" but the gorram pilot still lands when the final hold waypoint comes up, wherever he is at the time. any ideas what I'm doing wrong? the mission runs with 6 spartans, 1 playable but not leader. they are in the main ruins on tanoa, they hold for radio, then the pelican overhead with gunner playable joins the squad and they (usually) make their way out of the jungle south without getting stuck, through the four PREDATORS. I cant get the pelican to hover gracefully over the squad providing fire support untill he gets radio to pickup and move on, most times it flies k's away, because of combat, even though I have set fleeing off, and lands to pick up the squad, despite receiving no order to do so.

Everyone starts up in the air with parachutes (units are named flead, fmark, far, fmedic, and fuav) : //Waaaaaay up in the sky: flead setPosATL (flead modelToWorld[0,0,2500]); fmark setPosATL (fmark modelToWorld[0,0,2500]); far setPosATL (far modelToWorld[0,0,2500]); fmedic setPosATL (fmedic modelToWorld[0,0,2500]); fuav setPosATL (fuav modelToWorld[0,0,2500]); They fall, and open their parachutes at default altitude. The next part of the script creates triggers to check each unit to see if it's a player, then opens the player's chute automatically too (I'm just posting fmark's trigger, but there are four - one for each playable unit (flead is not playable)): //Auto open parachute at 350 M: _fmarkChuteOpenTrig = createTrigger ["EmptyDetector", getMarkerPos "dropZoneMarker"]; _fmarkChuteOpenTrig setTriggerArea [2000, 2000, 0, false, 350]; _fmarkChuteOpenTrig setTriggerActivation ["WEST", "PRESENT", false]; _fmarkChuteOpenTrig setTriggerStatements ["(isPlayer fmark) and (fmark in thisList)", "fmark action ['openParachute']; deleteVehicle thisTrigger", ""]; Since the wind blows the AI all around, I have four more triggers to make sure the NPCs make it to their drop zone (again, only posting one of the triggers for you to see): //Make sure AI lands in the drop zone: _fleadDropZoneTrig = createTrigger ["EmptyDetector", getMarkerPos "dropZoneMarker"]; _fleadDropZoneTrig setTriggerArea [2000, 2000, 0, false, 80]; _fleadDropZoneTrig setTriggerActivation ["WEST", "PRESENT", false]; _fleadDropZoneTrig setTriggerStatements ["(!(isPlayer flead)) and (flead in thisList)", "flead setPosATL [getMarkerPos 'fleadDZMarker' select 0, getMarkerPos 'fleadDZMarker' select 1, getPosATL flead select 2]; deleteVehicle thisTrigger", ""]; Once the player is 100 meters from the ground, the script checks to see if all 5 units are still alive. If everyone survived the jump (even using allowDamage false does not keep the stupid AI from dying on parachute jumps), then as soon as they're all on the ground, they get a waypoint (the group _fgrp) was defined already, I just didn't include it): waitUntil {getPosATL player select 2 < 100}; //Go to the next script once everyone's on the ground: if ({alive _x} count units group player == 5) then { waitUntil { (isTouchingGround flead) and (isTouchingGround fmark) and (isTouchingGround far) and (isTouchingGround fmedic) and (isTouchingGround fuav) }; //Waypoint to rally point: _wp = _fgrp addWaypoint [getMarkerPos "rallyPointMarker",0]; _wp setWaypointType "MOVE"; _wp setWaypointSpeed "LIMITED"; _wp setWaypointBehaviour "SAFE"; _wp setWaypointVisible false; The problem: the AI do not treat this waypoint like a LIMITED, SAFE waypoint. They are running around with their flashlights on, and they act like they're trying to secure the area around the waypoint (they take FOREVER) before they finally reach the waypoint. Additionally, all of the successive waypoints (even though identical Speed and Behaviour) act like this. The only way I've found to fix this is to start the player on the ground. If the player doesn't join the rest of the group for the parachute jump, it all works just fine. I would greatly appreciate any help. Thank you in advance.

Hi all! I know that kind of event handler does not exist, but since the "AUTOCOMBAT" AI feature exists, it is definetly something BIS should implement to avoid disabling it and looping around unit current behaviour and switch it "manually". I want to take advantage of some UPSMon feature which orders AI to set in STEALTH, and, in that case, add them a supressor and make them use it. Is there any Smart way to do this avoiding loops? Thanks in advance!

Hello, I am modifying curator interface, and I've run into a problem with AI following waypoints. The curator interface has only friendly units editable. Enemy units are rendered through my script separatedly so they can't be manipulated. To reinvent the functionality of "right-pressing" the enemy units with mouse to attack them, I am using CuratorWaypointPlaced event handler. I tried to modify waypoint passed from event handler, I tried to create new one and set it to waypointType "DESTROY" and delete the passed one. And I tried to set the one event handler gave me. AI just refuses to behave correctly as in vanilla zeus interface What am I trying to do: - Recreate the RMB behaviour in curator interface - Make AI move to and attack units at "DESTROY" waypoint What is actually happening: [when waypoint is attached to enemy] AI just stands on place nothing is happening, except the AI seems to guard more the direction to it's waypoint attached waypoints are offset to units they are attached to even several meters. (the position is different) sometimes attachWaypointVehicle attaches waypoint to nearby objects instead to enemy unit (but waypointAttachedVehicle still returns enemy unit) [when waypoint is spatial on ground] AI moves to position, sometimes attacking the enemy usually doing weird sh** on the way. when friendly units are too close to waypoint, unit may start killing nearby friendly units (nearby to waypoint) instead of enemy sometimes the waypoint survives for about 5 seconds before disappearing (maybe false completion?) when forced waypoint position by setWaypointPosition to position identical to enemy unit, sometimes the waypoint refuses and jumps to a nearby position What vanilla zeus does when creating a waypoint: Type: "DESTROY" Behaviour: "COMBAT" Position: under interface cursor it doesn't attach the waypoint to units, only sets position, type and behaviour. When I do the exact same, my AI's refuses to work properly (identical to vanilla zeus) //Event Hadler: When zeus places a waypoint (context: added when pressed RMB while hovering over an enemy unit - attack order) eh_waypointModifier = zeusModule addEventHandler ["CuratorWaypointPlaced", { params ["","_group","_waypointID"]; //Waypoint created by curator interface _wp = [_group,_waypointID]; //Waypoint array _group reveal cw_var_unitToAttack; //Revealing the enemy to ordered group (not helping) _wp setWaypointType "DESTROY"; //Sets the waypoint as "DESTROY" so AI would know it is going to attack something (Curator interface does the same) //AI usually moves towards the target, sometimes it does nothing. But it won't attack the enemy. //** Method 1 ** _wp setWaypointBehaviour "COMBAT"; //Makes the AI move towards the waypoint more reliably (Curator interface does the same) //AI moves towards the target tacticaly, it sometimes even engages against the enemy. //** Method 2 ** _wp setWaypointPosition [(position cw_var_unitToAttack),0]; //Sets the position of the waypoint so spatial DESTROY can find it's actual target more easily - does quite the opposite //AI usually stays on position //** Method 3 ** //Variable 'sys_unitToAttack' set by logic calling this EH _wp waypointAttachVehicle sys_unitToAttack; //Attaches the waypoint to the enemy unit - actually attaches the waypoint several meters away from unit, sometimes to different object (waypointAttachedVehicle still returns sys_unitToAttack) //AI usually moves towards the target, but won't attack //** Method 4 ** deleteWaypoint _wp; //Removes the waypoint created by curator interface _wp = _group addWaypoint [position sys_unitToAttack, 0]; //Creates a whole new waypoint on enemy's position _group setCurrentWaypoint _wp; //Sets the new waypoint as current so AI can't be confused which waypoint to use //AI just stands on place doing nothing. zeusModule removeEventHandler ["CuratorWaypointPlaced",eh_waypointModifier]; //Not needed anymore sys_unitToAttack = nil; //Not needed anymore }]; I've spend at least 7 hours figuring this nonsense out and trying several AI hacks. I want to have my scenario addon-free, just working with vanilla, so any mods are not usable to me. Only scripting hacks. This is not really a request for help. It is a request for someone from dev-team to give me some insight on how zeus waypoints works so I can successfuly and reliably replicate. Thx.

Hi. I am making a coop mission where 30+ players are acting as civpop that have decided to become rebels. I am looking for simple ways to make the occupation AI act as if it's never sure of whether a player is legit civilian or whether it's something one should engage. So I'm thinking a lot of different conditions that cycle the BLUFOR player through setCaptive true and false. Does anyone have good ideas, or know of others who've tried? I tried a fair bit of searching, but my wording didn't return any good results. Here are some ways I'm going to try to go about it. Help is much appreciated. 1) Crowds can be treated as hostile. In real life some occupation forces disband the freedom of assembly and impose crowd limitations during curfew etc. I'm thinking of each player running a script that checks how close they are to others. If the script finds 3+ players (or AI civs) within a radius of X meters, they get flipped to setCaptive false. If there's civpop AI, those could conceivably be grouped silently with Resistance. For even more complexity, the script could avoid counting players/AI inside buildings. >>> How would I check whether players are inside buildings? 2) Anyone armed is hostile. The script checks for whether they are openly carrying a rifle/pistol, or are carrying a launcher of any kind. >>> How would I script the difference between a pistol in a backpack not being seen, as opposed to a holstered/backslung rifle being seen? 3) Anyone who ends up setCaptive false must then be un-detected by OPFOR before they can be flipped back to civilian. Not sure how to go about this. >>> Should I maybe check whether any units belonging to side==east have a knowsabout higher than 1 or 2? 4) Anyone running or sprinting while AI is within a certain radius. >>> Are there any isRunning commands that I could check?

Regarding the AI Fleeing section of https://community.bistudio.com/wiki/Arma_3_AI_Behavior It reads: Specifically: Does anyone know what a "supply point" is in the given context? I have experimented with the AI fleeing behaviour with ammo boxes and the "Resupply point" location entity to no effect.

If you set a group of Assault boats to move to a waypoint, it works fine.... UNLESS their behaviour is set to 'careless'. If it's set to careless, they either move very very slowly, or not at all. This is on Windows 10, 64-bit, latest version of normal-branch Arma (Eden-update), as of 19/02/2016.