_foley

A randomly generated compound or even a town would be cool.

Wow, impressive! I love procedurally generated stuff

I think managing fog in a script is the way to go considering you want to have both a long term fog forecast and an option to dynamically override it. A minimal example (server-side): initialFogIntensity = 0.1; finalFogIntensity = 0.7; finalFogTime = 24 * 3600; // 24 hours overrideFogIntensity = nil; // you can set this in trigger to temporarily overwrite fog intensity, set to nil to use the long-term forecast again 0 setFog initialFogIntensity; [] spawn { while {true} do { private _fogIntensity = linearConversion [0, finalFogTime, time, initialFogIntensity, finalFogIntensity, true]; if (!isNil "overrideFogIntensity") then { _fogIntensity = overrideFogIntensity; }; 60 setFog _fogIntensity; sleep 60; }; }; This example assumes you don't change time multiplier or skipTime. If that's the case, you can use a combination of dateToNumber and missionStart instead of plain time to calculate _fogIntensity. It also assumes you only need to change fog intensity. If you want to control [fogValue, fogDecay, fogBase], then you can use linearConversion three times (once for each value in the array).

If you use setDriveOnPath, AI ignores obstacles

It's a wild guess but I think what's happening is that when you call getUnitLoadout in onPlayerKilled.sqf, the player is already missing their main weapon (it drops at the moment of death). I'm sure there was a topic on this, maybe someone can link?

The trouble is that "_canRearm" is a local variable and it's only evaluated once, at the beginning of the script. Try this, first define a function that checks if player can rearm: fnc_canRearm = { _mrkr = "TowerPost1"; _mrkrcolor = getMarkerColor _mrkr; _color = switch (side player) do { case west: { "ColorBlufor" }; case east: { "ColorOpfor" }; case independent: { "ColorIndependent" }; default { "ColorGrey" }; }; (_color == _mrkrcolor) } then in the addAction set the condition to "call fnc_canRearm" instead of "_canRearm". Keep in mind that this condition will be checked on every frame. It's fine in this case but if the function were more complex then it could affect performance.

Did you consider using the "condition" parameter of addAction to check if player can rearm? You can't really update an action, you'd have to delete it and create again when needed but I think using the condition is cleaner.

It sounds to me like you want to store a "preset" of some group types. If that's the case then you wanna use a hashmap: _presets = createHashMapFromArray [ ["sniper_team", ["classname_unit_1", "classname_unit_2"]], ["scout_team", ["classname_unit_1", "classname_unit_2"]], ["fireteam", ["classname_unit_3", "classname_unit_4", "classname_unit_4", "classname_unit_4"]] ]; Then if you want to do something with each preset then you can use forEach: { private _teamType = _x; private _unitClassnames = _y; systemChat format ["Team %1 is made of %2", _teamType, _unitClassnames]; } forEach _presets; This lets you differentiate between "sniper_team" and "scout_team" even though they are made of the same unit types. But again, I'm guessing here. Share some context 🙂

If you run it straight from init and the problem was just alarmToggle then your original version should work fine. In this case remoteExec will do more harm than good.

If that loop runs on server only, then you're almost there. You need to replace: ship1 say3d ["shipAlarm", 500, 1]; with: [ship1, ["shipAlarm", 500, 1]] remoteExec ["say3d", 0, false];

_x != player isn't gonna work, try this instead: !isPlayer [_x]

ACE has this cool event you can hook into: [ "ace_explosives_place", { params ["_explosive", "_dir", "_pitch", "_unit"]; hint str _this; } ] call CBA_fnc_addEventHandler; Can't remember whether it fires on each machine or just for player placing the explosive.

It's ugly cause you put it all in one line 😄 I think HandleDamage is the best way to handle this.

If these loadouts are for player slots only, you want to run your script from init.sqf (or initPlayerLocal.sqf). You need to make sure the code runs only for players and awaits until the player object is available. Simple example goes like this: // init.sqf if (hasInterface) then { waitUntil { !isNull player }; [player] execVM "scripts\loadout_a.sqf"; } Here's a battle-tested example with different loadouts for different unit types. https://github.com/foley-dev/arma3-close-quarters/blob/master/init.sqf#L25 https://github.com/foley-dev/arma3-close-quarters/blob/master/scripts/player/loadout.sqf I used setUnitLoadout here but your approach with addItem/removeItem is perfectly valid too.

Have you tried selectPlayer in trigger activation?

Love the latest additions, smoking craters especially. Your script could easily become a basis for an EOD mission.

I suggest a little sanity check before you spend a lot of time on optimization. Make a blank mission on Tanoa with only a couple of vehicles for the players and drive the same route. That's as good as it gets, so if that doesn't give you desired framerate, then you should consider using a less busy part of Tanoa or a different map entirely. Otherwise, it means there is room for improvement and a good place to start are pages linked by @pierremgi

It doesn't work because whatever you put in trigger condition needs to return true or false, whereas forEach doesn't return anything. You're looking for this: {alive _x} count [target2,target3,target4,target5,target6,target7] == 0

Not really because it runs during briefing (before the game) and if it isn't finished by the time you go ingame, it will show everyone a loading screen. That said, on the first attempt I tried running the whole thing in unscheduled context which crashed the server catastrophically 😅

Hey I've been experimenting with setTerrainHeight to move areas of the map under the sea level in order to create a flood. Here's the script and a few screenshots from the mission playthrough. https://github.com/foley-dev/arma3-frogmen/blob/master/scripts/server/flood.sqf https://github.com/foley-dev/arma3-frogmen Tested on dedicated server, seems to work pretty well except for some minor misalignment of terrain objects.

You'd need an addon, I don't think you can change this config in mission. Hooking into the AnimDone event seems like the natural way to do this in Arma. If you're looking to have some ambient animations, take a look at BIS_fnc_ambientAnim. You can open it in Functions viewer to find out how Bohemia devs tackled this problem.

I think what you're looking for is closures but sadly this concept doesn't exist in SQF. One workaround is to set the variable in unit's namespace: _unit setVariable ["loopedAnim", _loopedAnim]; and then retrieve it inside the event handler: _loopedAnim = _unit getVariable "loopedAnim"; Works fine as long as you don't run multiple handlers simultaneously on the same unit.

I've no clue about CfgMoves but I'm thinking maybe you wanna use a gesture (as in playAction) as opposed to the "full body" animation as in "AmovPercMstpSrasWrflDnon_gear". From my experience they blend okay into different stances. Also, this mod features door opening animations though funnily enough the door animation part has been broken for a few month now 😄 Maybe you can reverse-engineer something useful from it.

Lovely solution, elegant code 👍

The lobby screen is empty when the mission has a dependency on an addon that the server doesn't have installed (3Den Enhanced perhaps). Check the server log for errors related to missing addons for confirmation.