frontlineops/flops_flo

1. Project shape

FLO is an Arma 3 mission framework, not a conventional app. The runtime is split between server-owned mission logic and client-side UI/actions, with persistence across sessions through save/load. The core gameplay loop is a dynamic frontline campaign rather than a fixed scenario.

2. Startup and authority boundary

The authoritative boot path is the server-side phase manager in Functions/Init. It runs a staged initialization pipeline: save detection, mission config restore/setup, faction loading, objective indexing, virtualization seeding, then mission systems startup. Clients do not drive campaign state directly; they wait for mission-ready and then finalize local UI and interaction layers.

3. Persistent campaign state

Saved state spans mission config, objective ownership, virtual groups, logistics state, and commander/runtime data. That persistence boundary is important for the diagram: the server restores a campaign world, rather than recreating one each launch. Fresh-start lobby parameters alter whether the mission resumes or rebuilds from scratch.

4. Faction and composition layer

Mission setup feeds a runtime faction catalog built from custom faction scripts and optionally auto-generated compatible Arma config data. The faction layer supplies unit/vehicle pools, composition defaults, and objective template values used downstream by commanders, virtualization, logistics, and civilian spawning. Root files like CUSTOM_PLAYER_FACTION.sqf and the Scripts/factions presets are the main authoring boundary.

5. Objective graph and frontline model

Functions/Objective builds and maintains the world’s territorial structure: objective indexing, graph links, clustering, ownership flips, and respawn markers. This subsystem is the spatial backbone for the campaign; it informs frontline pressure, rear areas, capture growth, and where forces are seeded or reinforced.

6. GTN command-and-control layer

Functions/AI/GTN is the strategic brain. It includes side commanders, world-state maintenance, planners, executors, monitors, intel aggregation, combat resolution, alerts, and player support integration. The command loop consumes objective state and logistics availability, then produces attack/defend/garrison orders, support requests, and tasking for each military side.

7. Strategic decision flow

The commander does not directly “spawn enemies”; it evaluates world state, classifies combat zones, computes pressure and reserve needs, and allocates limited strategic orders over time. That makes the main data flow: objectives and combat events feed commander world-state models, which then drive virtual group orders and logistics demand.

8. Virtualized battlefield subsystem

Functions/Virtualization is the large-scale simulation boundary. Groups exist in a persistent registry and spatial index, move between virtual and real states based on player proximity and mission needs, and preserve orders, transport links, mission locks, and runtime state across activation cycles. This subsystem covers spawning, deactivation, route updates, patrol logic, and transport carrier behavior.

9. Logistics and resource economy

Functions/Logistics implements side resources and supply chains. The network chooses HQ/rear objectives, builds delivery and replacement paths, records dispatches, and refreshes supply chains. Side resources gate replacements and growth, so the campaign’s force regeneration is economically constrained rather than free-respawn based.

10. Civilian simulation and missions

Functions/Civilian models a separate population system with behavior, routines, missions, intel gossip, protests, and detainment reactions. Civilians ingest nearby combat events and local control signals, then adapt behavior and produce mission/intel opportunities. This is a distinct AI subsystem from the military commanders, but it shares the same world and objective context.

11. Player-facing support, intel, and arsenal

Player interaction is mediated through support-request flows, intel pickups, commander-side markers, and a restricted arsenal/economy layer. Support requests go through the commander systems, not directly to effects; intel pickups reveal temporary side-only information; the arsenal uses funds, purchases, and crate finalization. These are the main client-to-server interaction boundaries.

12. Embedded UI, tooling, and reusable modules

The repo also contains mission UIs and embedded support modules: UI, IDS_Logistics, IDS_Notifications, and LARs/spawnComp. These provide dialogs, notification presentation, build/placement workflows, and composition spawning. Static assets in Compositions, Screens, and Sounds feed mission content and presentation, while include/ and CfgFunctions.hpp-style files wire Arma’s config-driven function registration.