Flying spheres and massive emissions internals

1. Flying spheres

sphereControl(action, id, positionASL, settings) creates, updates or removes a sphere on the server. Actions are create, update and remove; at most 16 spheres may exist. Creation assigns an ID when the supplied one is empty. An update keeps the stored position and raises the epoch so clients rebuild their local copy instead of interpolating across the change. Remote execution is rejected.

The server publishes the whole array as FF_horror_sphereState. Each client renders every sphere locally: a Sign_Sphere200cm_F simple object, a pulse light and a soft ambient light, with no per-frame network traffic and no client timer. sphereClientEnable accepts monotonic activation and sphereClientClear releases every owned visual, wave, sound and post-process.

2. Settings schema

sphereSettings returns the wire schema. The array index is the wire position; the UI labels and bounds come from the same table.

sphereValidateSettings returns a complete bounded array or an empty array. Missing and wrong-typed slots are rejected before anything is broadcast, so a client can never receive a half-valid sphere.

3. Waves, contacts and audio

The server walks each sphere's shared schedule and evaluates contacts once per player per wave. The front grows as radius * sqrt(progress) and a player counts as reached within 5 m of it. A player closer than a quarter of the radius also has both firearms faulted through the Utils weapon-fault service. A player is recorded even outside the close tier, so walking inward behind a passed wave cannot cause a repeat hit. Client rendering reconstructs still-travelling fronts after a JIP or a frame stall.

sphereAudioProfile selects one of three distance bands (close, medium, distant) and alternates two hit variants on the shared cycle. Medium layers reuse the close or distant sample with reduced config volume, so close and distant never play at full gain together. Each layer gets its own local emitter, because an object can only say one sound; sphereStopAudio deletes owned sound objects rather than numeric engine IDs.

4. Zeus authoring

ZEN registers FF: Horror > Flying sphere and Flying sphere / edit or remove. The create dialog uses three pages (timing and range, wobble and hover, pulse and player effects), keeps the position in Zeus ASL coordinates and sends nothing until the last confirmation. sphereZeusRequest authenticates the curator before dispatching the server-local mutation; the manage dialog chooses the nearest sphere and can update or remove it.

5. Massive emission

A massive emission is a single server-owned pulse started by the FF: Horror > Massive emission Zeus module. emissionRequest validates the curator, then emissionStart reads FF_horror_emissionConfig and starts one sequence. Only one emission may exist at a time.

Targets are living player bodies inside the radius, excluding headless clients and virtual bodies. On contact the emission faults both firearms and queues the Utils vehicle aftermath: every selected vehicle near the reached player is evacuated on its occupants' machines and receives its effect only after all player occupants have left, within a ten-second deadline. The shared barrier and recovery then run through the Cinematic pulse sequence.

6. Horror recovery profile

The local profile adds aftermath only when FF_horror_emissionProfileEnabled is true (default). It chains mission callbacks instead of replacing them, adds soundHold and soundFade only when the mission left them unset, and is configured by:

• FF_horror_emissionConsequences (default true) — drain the active filter and apply bounded ACE injuries on recovery.
• FF_horror_emissionBeacon (default true) — request a timed PASS alarm after wake.
• FF_horror_emissionConfig — the server-side option hash map read by Zeus.

pulseAftermath owns the red impact and recovery grading; pulseProfileClear releases aftermath audio, grading, the music hold and delayed callbacks. Curators are exempt from consequences and the beacon.

7. Limits and state

• FF_horror_sphereState — replicated sphere array; FF_horror_sphereServiceGeneration is the monotonic activation epoch.
• FF_horror_emissionRecords / FF_horror_emissionSerial — server-owned emission registry.
• FF_horror_emissionRecoveryHooks and the FF_horror_pulseProfile* keys — local callback bookkeeping for the recovery profile.
• At most 16 spheres, one emission at a time and 128 vehicles per emission call.

Code-level guarantees: settings bounds, schedule maths, contact tiers and callback chaining. In-engine rendering, audio mix and multiplayer contact timing remain manual checks.

Related functions

• FF_horror_fnc_sphereControl — Creates, updates or removes an opt-in flying sphere on the server.
• FF_horror_fnc_sphereSettings — Shared schema: [label, minimum, maximum, default, decimal places]. Indices are also the wi
• FF_horror_fnc_sphereZeusRequest — Authenticates curator sphere configuration requests before dispatching server-local mutati
• FF_horror_fnc_emissionStart — Starts an opt-in, server-owned massive pulse at an explicit ASL origin. [origin, options]
• FF_horror_fnc_emissionRecoveryConfigure — Add the themed profile to this emission without replacing mission callbacks.
• FF_horror_fnc_pulseRecoveryOptions — Returns an opt-in Horror profile for Cinematic pulse recovery.
• FF_horror_fnc_pulseAftermath — Applies or clears the local pulse's owned red impact and recovery grading.

↑ Back to top