Grumpy Old Man

The camfeeds are fine, the issue of those weird black jagged lines is caused by HBAO ambient occlusion, setting AO to disabled or HDAO should resolve this. Cheers

Unless you actually tried that out I'd be surprised, since bool and scalar are different data types, at least in .sqf. Cheers

You can simply place traffic cones and name them (cone1,cone2, etc.) then use the following to spawn an ammocrate on a random cones position: //init.sqf for SP _cones = [cone1,cone2,cone3,cone4,cone5]; _pos = getPosATL selectRandom _cones; {deleteVehicle _x} forEach _cones; _crate = "B_CargoNet_01_ammo_F" createVehicle _pos; _crate setPosATL _pos;//just in case createVehicle doesn't place it properly Cheers

Unless you're more specific this might do: Small snippet that only shows specific units if thermal is equipped and active, otherwise they're invisible. Cheers

Why remoteExec? setPos is global. Cheers

Arma seems to be weird regarding settings, I also never noticed any performance difference when changing AA and other settings, only draw distance, supersampling and amount of active AI on the map seem to visibly influence fps. Just buy a current gen CPU and overclock it, 5.5ghz on a 9900k will send arma flying. Cheers

You're not really giving much information about what you want to do exactly. Do you need to get all nearby building types into the clipboard or is the hint sufficient? onEachFrame { _stuff = (nearestObjects [player, [] , 5]) apply {typeOf _x}; copyToClipboard str _stuff; hintSilent str _stuff }; Cheers

All projectiles except propelled ordnance and bombs follow a simple trajectory formula (ignoring glide, coriolis force and air resistance). To get the max height you need launch angle and muzzle velocity like this: _muzzleVelocity = 300;//in metres per second _angle = 45; _height = (_muzzleVelocity^2 *sin _angle^2) / (2 * 9.80665); hint str _height //prints 2294.36 You can get the muzzlevelocity from config and the angle from some modelToWorld wizardry using gunBeg and gunEnd config entries of the respective weapons. Cheers

You can use this to make a vehicle fire faster, setting the value to 1 means 100% rechambering time, set to 0.75 will make the vehicle fire 25% faster. Needs to be applied for every shot fired so a fired EH is needed: test addEventhandler ["Fired",{ params ["_unit", "_weapon", "_muzzle", "_mode", "_ammo", "_magazine", "_projectile", "_gunner"]; _reloadTime = _unit getVariable ["TAG_fnc_fireRate",1]; _unit setWeaponReloadingTime [_gunner, _muzzle, _reloadTime]; }]; test setVariable ["TAG_fnc_fireRate",0.75];//will fire 25% faster At this point it's strongly advised to visit the wiki and check the script commands page individually, since, as you can see, the naming convention is absolutely bonkers (setWeaponReloadingTime actually changes the rechambering time, go figure). You can easily go from there and filter only certain weapons on the vehicle to receive the increased firerate (simple if _muzzle = check should do). Cheers

Shh let him struggle with the outdated one for a bit... Cheers

Am I in the wrong forum? What's wrong with a 12 gun missile battery barrage? Since all muzzle flashes are particle effects (same as smoke and fire effects) there's most likely no way around it, unless you want to make your own stuff using custom texture objects and whatnot. This has served me well to goof around with particle effects, easy enough and you can export those effects. As far as I can recall you need to fix some errors that show up in the beginning but nothing ctrl+f can't handle. Cheers

Even a 1ms execution time should be fine if nothing much else is happening, since at 60fps one single frame runs for 16.67ms. Without any examples hard to tell, simple animationstate checks and playmove should be fine for quite some units as long as it's a single eachFrame EH handling this, and not individual eachFrame EHs per unit. Animation related eventhandlers might be the better bet though. Cheers

You'll gain more performance by deleting a single AI from the mission. Cheers

When an object gets deleted, so should its namespace as far as I know. setVariable even on thousands of objects within one frame shouldn't cause any issues, unless you broadcast them all. Unless you run into performance issues and can pinpoint it to setVariable, I wouldn't worry too much about it. Not really sure what you mean with having to use setVariable instead of an array. Cheers

The == check doesn't accept bool. It's nonsensical anyway since you can simply use !_isCaptured. Cheers

Add it? Maybe? Cheers

Why stick to triggers in the first place? You can easily define a more abstract function that does what you want and applies what you want on any game object. Cheers

Returns the following just fine: [7100,25000,0] Cheers

There is, it's a little weird though, might still do what you need. Place a unit that will serve as camera, set it as player, name it cameraUnit (in case you need to switch back) Place another unit you wish to control Run this: player remotecontrol remoteunit Might also work with spawning a camera first, then using remoteControl. Then you'd need most likely an eachFrame eventhandler to keep the camera hovering above the remote controlled unit. Weird thing is even though you control the remoteunit, when using the fire button the camera unit will shoot, so depending on what you want to do this might cause issues. Talk about programming patterns, huh? Cheers

From grid to pos for 10, 8 and 6 digits: GOM_fnc_gridToPos = { params ["_grid"]; _count = count _grid; _banana = _count / 2; _multis = [1,10,100]; _counts = [10,8,6]; _multi = _multis select (_counts find _count); _posX = (parseNumber (_grid select [0,_banana])) * _multi; _posY = (parseNumber (_grid select [_banana,_banana + _banana])) * _multi; [_posX,_posY,0] }; Pos to grid: GOM_fnc_posToGrid = { params ["_pos",["_gridSize",6,[0]]]; _divisors = [100,10,1]; _gridSizes = [6,8,10]; _divisor = _divisors select (_gridSizes find _gridSize); _gridResolution = _gridSize / 2; _pos params ["_posX","_posY"]; _posX = str round floor (_posX / _divisor); _posY = str round floor (_posY / _divisor); while {count _posX < _gridResolution} do { _posX = "0" + _posX; }; while {count _posY < _gridResolution} do { _posY = "0" + _posY; }; _posX + _posY }; Usage: _grid = [getPosATL player,10] call GOM_fnc_posToGrid; systemchat str _grid; //prints something like 0843103263 You can easily add finer granularity if needed. Cheers

What/how were you testing? Cheers

It's also possible to use a fired eventhandler and reveal the firer to every unit within a certain distance, changes things up a bit. Cheers

Vanilla AI with .50cal rifles can engage up to 2km. Static weapons might engage even further. Unless you further elaborate on the specific situation where you want an engagement to happen one can just speculate. A typical engagement range of 300m at most seems more authentic. Most factors that affect AI engagement range are daytime, weather and of course target knowledge, can't shoot something you haven't spotted yet. Cheers

To simply check stuff while in the editor you can use the editors monitor lines (with open menu below the "Watch:" entry), perfect for keeping an eye on up to 4 code snippets. Healing with a first aid kit will reduce all damage (i.e. from 0.95) down to 0.25. To fully heal a unit to 0 damage you need a medikit. Might be a possible oversight (if you check for <0.25 and heal with a first aid kit the check returns false, since it's exactly 0.25, no less). Cheers