Terminals internals

1. Registering a terminal

// server
["station", myTerminal, createHashMapFromArray [
    ["title", "Field station"],
    ["power", {["grid"] call FF_utils_fnc_powerHasSupply}],
    ["mediaItems", ["Item_FlashDisk"]],
    ["grants", [["research.key", "Copy research credential"]]],
    ["channel", "operations"], ["callsign", "Field station"],
    ["services", [
        ["tower", "Tower lights", "lights", [myLampA, myLampB]],
        ["uavPower", "UAV standby", "dronePower", myUAV],
        ["uavOperator", "Follow operator", "droneOperator", myUAV],
        ["uavPatrol", "Patrol route", "dronePatrol", myUAV]
    ]]
]] call FF_utils_fnc_terminalRegister;

Registration fails for duplicate IDs or objects, invalid configuration, overlapping terminal-owned light groups, or more than 64 registrations. Supply, access, phase, service and export callbacks are local server code and are never sent to clients. Native state, operator identity and target objects are never supplied by a browser.

2. Configuration

3. Lifecycle and services

Phases are closed, opening, off, booting, online and released. A default terminal is closed. Opening reserves its interval even without supply; boot requires an open case and live power, and cannot finish early or survive power loss. Supply loss takes an online terminal offline and turns off mapped light, UAV-power and watch outputs. Explicit shutdown latches automatic boot off until a boot command re-enables it. Nothing starts merely because Utils loads.

Service kinds are lights (explicit object array), the native UAV kinds dronePower, droneWatch, droneOperator, dronePatrol and droneHold (which delegate to the registered UAV owner), and a custom target: server code receiving [player, site, previous, requested] and returning [accepted, nextValue]. UAV references are validated against their actual server registration.

The same payloads are published as the server-local CBA events FF_utils_terminalPhaseChanged, FF_utils_terminalServiceChanged and FF_utils_terminalExported.

4. Credentials, exports and archives

Credentials, authentication and completed-archive flags attach to a live player body and identity: a surviving-body reconnect keeps them, a replacement body starts clean, and a different identity cannot inherit cached private replies. terminalGrant lets mission code grant or revoke a scope. An issuer terminal grants only its configured scopes and requires configured media presence; removing media or revoking a scope makes protected operations unavailable immediately, even if the recorded unlock persists.

Exports reserve one session per actor across all terminals. The server stores site, generation, file, token, start, earliest, deadline and network owner, and continuously re-checks access, supply, media, scope and authentication. Cancel requires the exact token; finish requires the original site, generation, file, token, owner and the minimum time. The session clears before the completion event, so a second commit is impossible. Query results afterwards with [player, site, file] call FF_utils_fnc_terminalHasExport, which survives a terminal replacement.

5. Shared channels

Ports sharing a channel share one bounded server log with server-supplied callsigns; the client sends only text. Station messages need physical online access and that port's credential policy, while HQ transmit and view require a currently assigned curator and re-check that role after queueing. Text keeps Unicode, pipes, quotes and newlines, strips ASCII controls, trims whitespace and caps at 600 characters; a per-actor cooldown stops port hopping from evading the delay. Seed mission lore with [channel, [[timestamp, callsign, text], …], history] call FF_utils_fnc_terminalSeedChannel and clear with terminalClearChannel. Logs are delivered privately through authorized views, never as a global public chat variable.

6. Protocol and state

The player panel calls [site, generation, operation, data] call FF_utils_fnc_terminalSend, which assigns an owner-bound monotonic sequence. Operations: view/inspect (empty), open, boot, shutdown, unlock (empty), issue ([scope]), service ([serviceID, bool]), download ([file]), finish ([file, token]), cancel ([token]), chat ([text]) and the curator-only hqView, hqInspect and hq. Full views always return data; inspect views return empty when unchanged, so a new UI must begin with view/hqView. Admission is 20 requests per second per owner and acknowledgements are idempotent for an exact retry.

• FF_utils_terminalSites — [ID, generation, object, title, range].
• FF_utils_terminalState — [revision, generation, phase, powered, serviceValues].
• Acknowledgements arrive as FF_utils_terminalAcknowledged with the private view; a receiver must match its own context and a monotonic sequence.
• Scopes, media and authentication state, archive descriptions, personal exports, transfers, callbacks and chat history are deliberately absent from public state.

7. Player interface

terminalOpen(site, generation, hq) asks the server for authorized access before any browser exists; terminalClose releases it. The server answers with terminalClientEnable(active, generation), and terminalClientTick maintains the actions, the private view and the page's own bounded request queue. terminalLoad, terminalRefresh and terminalUnload manage the embedded page.

• terminalLabels supplies the localized label pairs; terminalTranslateView localizes trusted metadata and callsigns while leaving player-written message text literal.
• Only the requesting body can drive a panel: requests carry the site generation and are dropped when the registration is replaced or the player leaves range, dies or loses access.
• HQ mode uses the same panel through FF_zeus_fnc_terminalHQ and requires an assigned curator.
• Battery-driven sites reserve one authenticated transaction per activation, so a panel cannot spend the same battery twice.

8. Validation

Verified offline: command, authorization, phase, text and transfer helpers, including phase ordering, power interruption, public-service versus USB requirements, revoked scopes, timing and token/owner/file mismatches, and Unicode-safe text. Panel layout and request queueing are covered by browser tests. In-engine multiplayer behaviour remains a manual check.

Related functions

• FF_utils_fnc_terminalRegister — Registers explicit terminal services, media/scope prerequisites, exports and a shared comm
• FF_utils_fnc_terminalSend — Sends one sequenced local-player terminal request.
• FF_utils_fnc_terminalGrant — Grants or revokes a server-owned credential scope without modifying mission inventory.
• FF_utils_fnc_terminalHasExport — Checks a completed body-bound archive flag after server commit.
• FF_utils_fnc_terminalOpen — Requests authorized normal or curator-only terminal access before creating a browser.
• FF_utils_fnc_terminalSeedChannel — Seeds configurable archive traffic without any built-in mission lore.

↑ Back to top