Bases and equipment / UAVs, ready room, weapon faults, power, solar, terminals

UAV automation and live feeds

One airframe per registration: follow a player, escort a vehicle, run a patrol, hold, or watch an area and turn toward contacts. Nothing moves until the server registers the UAV.

// initServer.sqf
[_uav, createHashMapFromArray [
    ["route", [[100,200,0],[300,400,0]]],
    ["distance", 25], ["height", 5], ["interval", 3],
    ["enemySides", [east]]
]] call FF_utils_fnc_droneRegister;
[_uav, "operator", player] call FF_utils_fnc_droneAssign;
[_uav, "watch", true] call FF_utils_fnc_droneAssign;

// live feed, audience-aware
["survey", _uav, _objective, "players", true] call FF_utils_fnc_droneFeedSet;

• The UAV must already exist and be a UAV (isUav = 1). Duplicate registrations and vehicles already flown by another registered UAV are refused.
• Player-camera feeds are a per-client singleton — do not run a second live-feed controller in the same HUD slot.
• With ZEN, the curator gets Drone automation / Live feed modules so you never have to write the calls above.

Full keys, status values and cleanup rules: UAV internals.

Ready room

A briefing and assembly screen for the start of a session: literal briefing text, up to eight private questions, per-player readiness, an optional skip vote, team chat and an optional music bed. Headless clients are always excluded.

// initServer.sqf
[true, createHashMapFromArray [
    ["title", "Operation briefing"],
    ["briefing", ["Read the task, then mark ready."]],
    ["questions", ["What is your role?"]],
    ["countdown", 8], ["voteEnabled", true]
]] call FF_utils_fnc_readyRoomStart;

Release your own intro from a client callback — the room never moves a player or starts a scene by itself:

// initPlayerLocal.sqf
FF_utils_readyRoomClientConfig = createHashMapFromArray [
    ["onRelease", { params ["_skip", "_participants", "_participating", "_epoch"];
                    [] spawn my_fnc_playIntro; }]
];

Policy keys, vote maths and privacy rules: Ready room internals.

Weapon faults

Deliberate firearm malfunctions that only a configured specialist can clear, plus an expanding pulse that jams weapons over an area. Nothing is random: the service only reacts to your calls.

// initServer.sqf
[true, createHashMapFromArray [
    ["duration", 10], ["traits", ["engineer"]]
]] call FF_utils_fnc_weaponFaultStart;

// later, from a trigger or a scripted event
[getPosASL _emitter, serverTime, 500, 50, false] call FF_utils_fnc_weaponFaultPulse;

Repairs are server-owned timed reservations, so two medics cannot both "finish" the same jam. ACE's own jams stay independent; ordinary ACE jam clearing does not remove a native fault.

Power, solar and terminals

Three building blocks for bases and installations. All are server-registered, all are opt-in, and none of them assumes object names or coordinates.

["campPower", _generator, _panel,
 createHashMapFromArray [
    ["limits", [0.1, 0.65, 0.9, 0.98]]
]] call FF_utils_fnc_powerRegister;
["campPower", true]
    call FF_utils_fnc_powerSetInput;

["array", _console,
 createHashMapFromArray [
    ["dwell", 6],
    ["access", {params ["_u"];
        (_u getUnitTrait "engineer")}]
]] call FF_utils_fnc_solarRegister;

["station", _terminal,
 createHashMapFromArray [
    ["power", {["campPower"]
        call FF_utils_fnc_powerHasSupply}],
    ["services", [["lights", "Tower",
        "lights", [_lamp]]]]
]] call FF_utils_fnc_terminalRegister;

// initServer.sqf
["radio", "operations", [
    ["HQ", "Move up to the ridge."],
    ["Squad", "Copy, moving."]
], [20, 40]] call FF_utils_fnc_terminalTrafficLoop;

Details: Power, Solar, Terminals.