Solar commissioning internals

A four-stage commissioning puzzle owned by the server: assign return lines by XOR syndrome, set active-low control flags, then hold four coupled voltage dials inside tolerance for a continuous dwell.

FF_Utils 5 related functions

1. Registering a console

// server
["arrayCommission", mySolarConsole, createHashMapFromArray [
    ["title", "Array commissioning"],
    ["power", {missionNamespace getVariable ["myBootstrapReady", false]}],
    ["access", {params ["_unit"]; (_unit getUnitTrait "engineer") isEqualTo true}],
    ["dwell", 6], ["heartbeat", 1.5], ["tolerance", 1]
]] call FF_utils_fnc_solarRegister;

// separate grid transfer that depends on the result
["arrayGrid", myGenerator, myTransfer, createHashMapFromArray [
    ["input", {["arrayCommission"] call FF_utils_fnc_solarIsSolved}]
]] call FF_utils_fnc_powerRegister;

Register, solarIsSolved and solarUnregister are server-local APIs and reject remote execution. IDs must be unique and at most 128 characters, at most 64 consoles may register, and one object cannot belong to two native sites. Every new registration gets a new generation and a freshly generated solvable challenge.

2. Configuration

Key	Default	Bounds / meaning
`title`	Site ID	String up to 256 characters, may use a `$STR_` reference
`range`	3 m	0.5–10 m
`dwell`	6 s	1–60 s of continuous valid calibration
`heartbeat`	1.5 s	0.5–10 s maximum operator-contact gap
`tolerance`	1	0–10 absolute voltage error per matrix row
`power`	`{true}`	Server callback `[ID, console]`
`access`	Engineer trait	Server callback `[player, ID, console]`
`onSolved`	`{}`	`[ID, solved, console]` on initial level, completion and unregister
`matrix`	`[[3,1,-2,0],[-1,3,0,1],[0,-2,3,1],[2,0,-1,3]]`	Four rows of four integer coefficients, each -16–16

onSolved is mirrored as the server-local CBA event FF_utils_solarSolvedChanged. Re-check solarIsSolved whenever you authorize a downstream service instead of trusting a client variable. Commissioning stays solved across later power loss; unregister ends that site's solved signal. Destroyed consoles remain registered so a mission can repair them.

3. The four stages

Parity — stage 0

Four return selectors must form a one-to-one assignment matching every row's XOR syndrome. solarParity performs the check; partial edits never verify.

Flags — stage 1

Eight active-low control lines. Their weighted word accounts for inversion and must match the target word; this stage only exists after parity passes.

Calibration — stage 2

Four coupled voltage dials, integers -8–8. All rows must stay within tolerance for the full dwell. A changed dial resets dwell even when the new position is also inside tolerance.

Commissioned — stage 3

Set by the server only. Clients cannot assert completion, and a lost role, position, power, body or contact resets the dwell and does not resume it on return.

The generator picks distinct input and return words, a return permutation, permuted bit weights, active-low lines, a nontrivial target word and in-range dial solutions, then builds syndromes and voltage offsets from them. Solvability is preserved by construction; never hardcode a generated solution.

4. Request protocol

// intended interface client
private _sequence = ["arrayCommission", _generation, "parity", [2,0,3,1]]
    call FF_utils_fnc_solarSend;

Operations and payloads:

Operation	Payload
`inspect`	empty
`parity_edit` / `parity`	four values -1–3 / four values 0–3
`flags_edit` / `flags`	eight 0/1 values
`tune`	four values -8–8, taking over the operator immediately
`sample`	empty heartbeat; carries no dial values so two open panels cannot overwrite each other

The sender assigns a monotonic per-client sequence and supplies its real player body. The server validates owner, generation, primitive bounds and physical eligibility, then defers mutation and re-checks the body and site. Admission is 20 requests per second per owner. An exact sequence/operation retry returns the cached acknowledgement without mutating; older sequences can never restore old dial positions. Acknowledgements arrive as the local event FF_utils_solarAcknowledged with [ID, generation, sequence, operation, accepted, reason], where the reason is accepted, access, stage, parity, flags or invalid.

5. Public state

FF_utils_solarSites — [ID, generation, console, title, range, dwell, tolerance].
FF_utils_solarState on the console — [generation, revision, challenge, matrix], where the challenge keeps the source layout: stage, input words, return words, syndromes, target word, weights, inverted bits, voltage offsets, accepted/edited pairs, accepted/edited flags, dials, dwell.
Changed state and stage publish immediately; dwell-only snapshots are quantized to tenths and limited to 5 Hz.
Callback code and authoritative operator/contact records are never published.

6. Native panel

A registered console gains a localized Commissioning action on interface clients, including late joiners. The server checks power, access, body and position before opening it, and the panel closes only itself when you leave range, die, respawn, fall unconscious, lose access, or when the console is removed. Return wiring shows input, required syndrome and live XOR per row; flags show weights, target and preview; calibration shows coupled errors, dials, tolerance and the server's dwell progress. Local previews never mark the puzzle complete — only the shared server stage does, after an acknowledgement.

Edits are debounced and queued separately from heartbeats; newer local edits survive delayed replies; verification never advances optimistically. Public revision, registration generation, page generation and request IDs prevent stale state or replies from replacing a newer page. A browser reload increments the page generation, clears its queue and pushes a fresh snapshot. For restricted policies also allow FF_utils_fnc_solarClientEnable (server to client); solarOpen and solarClose are local interface APIs.

7. Limits

Verified offline: the native generator, XOR/parity, stage reducer, matrix checks and dwell logic, all six original parity cases, the source solar fixture, contact loss, short dwell, stale dial heartbeats and 32 varied solvable seeds. Chromium tests cover the real panel controls and stale-state handling in EN and CZ. Not verified: Arma objects, network authority, the compositor, hosted and dedicated races, late join, operator handoff and cleanup.

Related functions

FF_utils_fnc_solarRegister — Registers a solvable commissioning console with explicit power and role prerequisites.
FF_utils_fnc_solarSend — Sends monotonically sequenced primitive commissioning operations from the local player.
FF_utils_fnc_solarIsSolved — Queries authoritative commissioning completion for downstream power/services.
FF_utils_fnc_solarOpen — Requests server authorization before displaying one native commissioning console.
FF_utils_fnc_solarUnregister — Removes a console and ends its solved signal without changing mission story state.

↑ Back to top