Grumpy Old Man

Any reason why you're using outdated BIS functions? There's already a mission eventhandler for eachFrame, same goes for cinema border. You're not passing the cam object to the scope of the onEachFrame eventhandler. Since the Hawkins variable is already global, set the cam as a variable on the player, something like this could work: _test = [] spawn { player switchMove "Acts_MHCargo_JumpToWater_all"; detach player; _cam = "camera" camCreate (eyePos Hawkins); Hawkins setVariable ["TAG_fnc_cam",_cam]; _cam cameraEffect ["internal", "BACK"]; _cam camSetTarget LookAtObject; showCinemaBorder true; _cam camCommit 0.5; sleep 0.5; TAG_fnc_cancelCam = false; addMissionEventHandler ["eachFrame",{ _cam = Hawkins getVariable ["TAG_fnc_cam",objnull]; _cam camSetPos (eyePos Hawkins); _cam camCommit 0; if (TAG_fnc_cancelCam) then { removeMissionEventhandler ["eachFrame",_thisEventhandler]; _cam cameraEffect ["terminate","back"]; camDestroy _cam; player switchMove ""; }; }]; sleep 3; TAG_fnc_cancelCam = true; } Cheers

Never got any errors when deleting units mid-mission, do you have a .rpt or screencap of the error? Cheers

You could create a camera, hide the player and make the camera do the movement from first person view, just set the camera position to the eyePos of the player on every frame, should do the trick. There are no functions/script commands to manipulate where the regular player camera is pointing towards. Cheers

Well you can auto reveal everything in front of a unit: GOM_fnc_autoReveal = { params ["_unit","_distance","_fov"]; //we don't want to use a units direction, but rather the direction he's looking at, big difference eyeDirection _unit params ["_dirX","_dirY"]; _eyedir = _dirX atan2 _dirY; if (_eyedir < 0) then {_eyedir = 360 + _eyedir}; _distance = _distance ^2; _enemySides = side _unit call BIS_fnc_enemySides; _enemies = allUnits select { side _x in _enemySides AND {_x distancesqr _unit < _distance} AND { acos ([sin _eyedir, cos _eyedir, 0] vectorCos [sin (_unit getDir _x), cos (_unit getDir _x), 0]) <= _fov/2} }; _enemies apply {_unit reveal [_x,4]}; _enemies }; [sniper,viewDistance,120] call GOM_fnc_autoReveal; This will reveal every enemy in front of a unit, at a certain field of view (i.e. 120°) and within specified distance. The return holds all revealed units. _revealedEnemies = [sniper,viewDistance,120] call GOM_fnc_autoReveal; Cheers Cheers

Well doTarget makes the unit look straight at the targeted unit. If nothing is blocking the sight and an appropriate scope is mounted, the sniper will see he's looking at an enemy, reveal value almost immediately jumps to 4 at 1100m using the vanilla opfor sniper unit. Cheers

No reveal needed, a simple doTarget is enough. At pitch black night the sniper will fire the lynx at 1km+. It all depends on the scope, put a nightstalker on, should do the trick. Cheers

Something like this might do it, if you want to know the distance to the nearest hostile player: //grab all enemy players, sort by distance ascending then return nearest enemy player _enemyPlayers = allPlayers select {side _x in (playerSide call BIS_fnc_enemySides)} apply {[_x distance player,_x]}; _enemyPlayers sort true; _nearestEnemyPlayer = (_enemyPlayers apply {_x#1})#0; Cheers

I'm sure the folks editing the wiki would appreciate any suggestions on how to make the wiki more 'clear'. Cheers

It basically boils down to setPylonLoadout. You have to call it twice, once to remove the currently installed pylon weapon, then to add a new one. _veh = yourAircraft; _mag = yourPylonMagazine; _pylonNum = "pylon1";//named index of the pylon, check the vehicle config for this [_veh,[_pylonNum,"",true]] remoteexec ["setPylonLoadOut",0]; [_veh,[_pylonNum,_mag,true]] remoteexec ["setPylonLoadOut",0]; Could have been done more user friendly, seeing how the "dynamic" loadout can only be changed upon mission init without scripting, I doubt the devs intended to make this user friendly at all, heh. Cheers

This basically. It's impossible to influence AI decision at the core, how AI decides when to fire one, burst or full auto, when to switch to sidearms or toss Mr. Handgrenade towards hope and a new friendship. BI don't seem to be reluctant to add user made configs to the core game, seeing @oukejs suggestion about PIDs, wonder why nothing similar happens for AI brains. Cheers

Oh yeah, those were the days, taking the abrams downhill at 160km/h, achieving escape velocity after hitting a pebble. Cheers

Regarding the view distance you can retrieve it using viewDistance, add 100m to it and the player will never see units spawn. About performance it's trial and error mostly. Depends on how many units are going to be killed, if you track everything you spawn and take care to remove it when no player is around and a certain time has passed. Never ran any mission for longer than 8 hours tops but didn't notice anything out of the ordinary. The question is, is it absolutely necessary for the mission to run 24 hours or more? It's enough to simply delete stuff, no need to destroy it first, if I understood right. Use isKindOf and check your brackets. Also added apply so you'll get the config class names instead of config paths: _allINDEPCars = "(getNumber (_x >> 'scope') >= 2) and {getText (_x >> 'faction' isEqualTo 'IND_F')} and {configName _x isKindOf 'Car'}" configClasses (configFile >> "CfgVehicles"); //returns ["I_Quadbike_01_F","I_MRAP_03_F","I_MRAP_03_hmg_F","I_MRAP_03_gmg_F","I_Truck_02_covered_F","I_Truck_02_transport_F","I_Truck_02_ammo_F","I_Truck_02_box_F","I_Truck_02_medical_F","I_Truck_02_fuel_F","I_Truck_02_MRL_F","I_APC_Wheeled_03_cannon_F","I_UGV_01_F","I_UGV_01_rcws_F"] You can search for factions and sides in the config, as long as the addon makers configure this properly it should work fine. Only buildings (most static weapons are buildings) and some objects are civilian side. Cheers

Hello, players, look at Arma 3, now back to Arma 2, now back at 3, now back to 2. Sadly, Arma 3 isn’t Arma 2, but if the devs stopped mangling the AI brains here and there and switched to proper programming procedures, Arma 3 could smell like it’s a more polished Arma 2. Look down, back up, where are you? You’re playing Arma 2 with female civilians, furniture, battlefield clearance modules, a huge asset variety, everything you liked. What’s on your screen, back at me. I see it, it’s Arma 3 MP where players are carrying 20 FAKs each. Look again, the FAKs are now armed Satchel Charges. Anything is possible when your game doesn't gather to pvp kiddies. I’m on a horse. Cheers

Well you can track an item, who had it, in what container did that unit put the item, etc. Things get odd when there's multiple items of same type in the same container, but other than that it's doable without an ID. Unless the thread starter elaborates further it's mostly assumptions at this point. Cheers

Could you give a less abstract example? Cheers

A sleep won't save you in most cases since it will take longer the more units you want to spawn, if you sleep for 0.1 per unit that's still 10 seconds, which can be an eternity if you want stuff to happen fast. I'd also say it's better to write your own functions instead of using BIS_fnc_spawnGroup, since you have more control about how you want to tackle performance. As an example consider spawning 100 random unit types on random positions 100m around the player: _spawn = [] spawn { sleep 3; _types = "getNumber (_x >> 'side') isEqualTo 1 AND configName _x isKindOf 'CAManBase' AND getNumber (_x >> 'scope') >= 2" configClasses (configFile >> "CfgVehicles"); _types = _types apply {configName _x}; systemchat "Starting spawn"; _initTime = diag_tickTime; for "_i" from 1 to 100 do { selectRandom _types createunit [player getpos [100,random 360],creategroup west] }; _endTime = diag_tickTime; systemchat format ["Spawn finished in %1",_endTime - _inittime]; copyToClipboard format ["Spawn finished in %1",_endTime - _inittime]; }; oneachframe {hintsilent format ["FPS: %1\nUnits: %2", round diag_fps,count allUnits]} This takes 1.28 seconds the first time I run it, fps dropping from a steady 60 down to 40-44. On the second run it only 0.89 second with stable 60fps. Weird huh? Let's take a look. What actually happens is, the first time you spawn some unit, the game has to load textures, models and whatnot into memory. This leads to an fps drop and increases the load time by more than 40% in this case. Fortunately there's a command that can handle the data loading when combined with a simple waitUntil check, so you can spawn in anything without a performance loss. Adjusting the above snippet looks like this: _spawn = [] spawn { sleep 3; _types = "getNumber (_x >> 'side') isEqualTo 1 AND configName _x isKindOf 'CAManBase' AND getNumber (_x >> 'scope') >= 2" configClasses (configFile >> "CfgVehicles"); _types = _types apply {configName _x}; systemchat "Starting spawn"; _initTime = diag_tickTime; { waitUntil {100 preloadObject _x}; } forEach _types; systemchat "Preload finished"; for "_i" from 1 to 100 do { selectRandom _types createunit [player getpos [100,random 360],creategroup west] }; _endTime = diag_tickTime; systemchat format ["Spawn finished in %1",_endTime - _inittime]; copyToClipboard format ["Spawn finished in %1",_endTime - _inittime]; }; oneachframe {hintsilent format ["FPS: %1\nUnits: %2", round diag_fps,count allUnits]} This will let you spawn anything without having an fps drop. Now the downside is the waitUntil loop. preloadObject most likely finishes way faster than it takes to render a single frame, which is 16.6667ms. waitUntil runs once each frame, so you'll have a most likely guaranteed delay between every spawn of around 16ms. This is the reason spawning 100 units took around 3 seconds on the first run, and 0.8 seconds on the second run, on my rig. Now what's faster than waitUntil? A while loop. While loops run as fast as possible, that's what you want: _spawn = [] spawn { sleep 3; _types = "getNumber (_x >> 'side') isEqualTo 1 AND configName _x isKindOf 'CAManBase' AND getNumber (_x >> 'scope') >= 2" configClasses (configFile >> "CfgVehicles"); _types = _types apply {configName _x}; systemchat "Starting spawn"; _initTime = diag_tickTime; { while {!(100 preloadObject _x)} do {}; } forEach _types; systemchat "Preload finished"; for "_i" from 1 to 100 do { selectRandom _types createunit [player getpos [100,random 360],creategroup west] }; _endTime = diag_tickTime; systemchat format ["Spawn finished in %1",_endTime - _inittime]; copyToClipboard format ["Spawn finished in %1",_endTime - _inittime]; }; oneachframe {hintsilent format ["FPS: %1\nUnits: %2", round diag_fps,count allUnits]} Using a while loop took took the same time on the initial run, roughly 3 seconds, but every run after that a mere 0.4 seconds for 100 units. Twice as fast compared to the waituntil example above, since wile isn't locked to every frame. Looks like a winner here, no sleep needed, runs as fast as possible without affecting fps. Note that to properly test this, you need to restart arma between every test, since stuff loaded to memory, like models and textures, stays even when leaving the editor/changing missions. Cheers

Well it doesn't lag out, it's just how modelToWorld works. Using modelToWorldVisual provides a more fluid experience. _3DMEH = addMissionEventHandler ["Draw3D",{ _unitArray = allUnits; { _curObject = _x; { _curSelectionName = _x; _posIcon = _curObject modelToWorldVisual (_curObject selectionPosition _curSelectionName); if !((_curObject selectionPosition _curSelectionName) isEqualTo [0,0,0]) then { drawIcon3D ["\A3\ui_f\data\map\markers\military\box_CA.paa",[1,0,0,1],_posIcon,0.5,0.5,0,""]; }; } forEach (selectionNames _x); } forEach _unitArray; }]; The entire snippet is still pretty darn expensive, on my rig 1.17ms for 2 units, the drawIcon3D command being the least expensive bit. Cheers

Groups don't have classes like units/vehicles have, which you can return using typeOf. CfgGroup only holds group templates containing unit/vehicle type and spawn position offset, nothing you can get using vanilla commands. You can use setVariable/getVariable on a group and store/get its type after spawning it. Cheers

Check this out: Seems to be 2 praetorians on the centermost positions, and the spartan next to the rear landing pad. The front markings in front of the hammer seems to be for unloading crates/ammo for the hammer. Cheers

So you're saying the broken convoy with wedge formation in safe behavior is totally fine and nothing to worry about? Column formation has never been mandatory for groups in safe mode. Entry for Careless and Safe behavior: Just as a reminder, ever since, putting a group in safe mode automatically put them in column formation. Place an infantry group, wedge formation, safe mode. Give them a waypoint. For convoys this is broken and evidence of a huge mess somewhere in the AI brain. Cheers

In Arma 2 the time spent setting up a convoy was a mere minute at most. In A3, 9 out of 10 times trying to place a convoy it'll simply not work, and that's being optimistic. Go to Altis Salt Lake or VR map or any similar barren area, place a convoy there, limit the speed of the lead vehicle to 30, set the group to SAFE behavior and give them a waypoint. Watch how at least 1 vehicle gets stuck, with not one single obstacle in the vicinity. This is basically just placing a convoy and making them move. There are no obstacles, no combat going on, no other scripts or mods hooking into the AI. That's the most barebones scenario, not some weird edge case that'll happen once in ten years. Wonder how this got past QA. Cheers

I get it that the modern society can be extremely confusing for most, especially how to search for stuff on the internet. Lucky for most breathing and other basic bodily functions aren't too complicated and have been automated by mother nature. Since I'm in a good mood I will help you find a conclusion to your problem. Three questions followed by their answers will lead you to a store where you can purchase something like this: What is printed on the bandana? Teeth. What word could also be used to put into google search? Bandana. So what's the final phrase to put into google search? Teeth Bandana. Cheers

Wondering about intended layout for those weapon systems, looks like the positions of hammer and VLS are clear, maybe the spartan too, that leaves 2 slots for the praetorian I assume? In front of the hammer there's also some markings, any idea what could possibly go in front of the cannon, if anything at all? https://imgur.com/y2M10km Any ideas/suggestions or other unmarked weapon placement spots I missed? Cheers

Thanks, it's a bit watered down, since I'm also using different reveal values for different weapons and distances, also taking suppressors into account, but something like this is easy to build upon. Cheers

This is what I'm using, works for all units and takes speed of sound and average reaction time into consideration: //reveal all firing units to nearby units, no distinction between friend or foe { _x addEventHandler ["Fired",{ params ["_firer"]; _nearbyUnits = allUnits select {_x distance2D _firer < viewDistance};//change viewDistance as needed { _reveal = [_x,_firer] spawn { params ["_unit","_firer"]; //take speed of sound into consideration and add an average reaction time of ~0.17-0.21s for audible input _delay = (_unit distance _firer) / 343; sleep _delay; //reaction time sleep random [0.15,0.17,0.21]; _unit reveal [_firer,0.5];//increase this number if you want a more immediate reaction }; } forEach _nearbyUnits; }]; } forEach allUnits; //to test _rnd = selectRandom allUnits; _rnd fire currentweapon _rnd; Comments basically got it covered. Adjust the values to your liking, the reveal value at 4 will result in an immediate response (after speed of sound and reaction time has been applied). Cheers