The multi-function display framework, developed by myself along with advice from the team at Worst Case Scenario (WCS), along with some good feedback from ceo_of_bacon (sorry for log spam!), is intended for use in modern vehicles — helicopters and ground vehicles alike. MFDF comes with multiple prebuilt pages designed for the H-47 Chinook but also includes a fully configurable widget system that allows dynamic control of text, progress bars (percent tapes), images (rotation, position, color), and custom handlers (VSD attitude indicators, fuel burn calculators) — all driven by vehicle signal values and configurable entirely through prefab attributes.

Preface

The purpose of MFDF is to provide the ability to display vital information virtually within world space, originally developed for the H-47 Chinook mod. The MFD relies on scripting to gather signal information (generated for vehicles via game code - or by other scripts), and updating GUI layout files with that information. The framework handles several pain points relating to replication - which ensures that displays are synchronized between players. This was a relatively easy hurdle to tackle through the use of RplProps - which are essentially replicated variables which are updated for players within streaming range. The most important feature of the framework is through understanding how script components work within Arma Reforger.

graph TD
    %% Main Vehicle and Component Relationship
    Vehicle["Vehicle Prefab"] --> ScriptComp["ScriptComponent Instance"]
    
    %% Server-side Flow
    subgraph Server["Server Instance"]
        ScriptComp --> ServerLogic["Server-side Logic"]
        ServerLogic --> RplProps["Replicated Properties (RplProps)"]
    end
    
    %% Client-side Flow
    subgraph Client["Client Instance"]
        RplProps --> ClientLogic["Client-side Logic"]
        ClientLogic --> LocalState["Local State Updates"]
        LocalState --> Display["Display Updates"]
    end
    
    %% Streaming Range Mechanics
    StreamRange{"Player in Streaming Range?"}
    StreamRange -- Yes --> ClientLogic
    StreamRange -- No --> Inactive["Component Inactive"]
    
    %% Player Actions
    PlayerActions["Player Actions (Turn On/Off, Change Settings)"] --> RplProps
    
    %% Global State Sync
    RplProps --> GlobalSync["Global State Synchronization"]
    GlobalSync --> |"Updates All Players"| Display
    
    %% Styling
    classDef server fill:#f96,stroke:#333
    classDef client fill:#9cf,stroke:#333
    class Server server
    class Client client

<aside> 💡

If you are familiar with Optional Dependencies, this framework uses #define AG0_MFDFramework.

</aside>

Architecture

The framework supports two distinct component approaches. Both are fully multiplayer-compatible and coexist in the same mod without conflict — a vehicle uses one or the other, not both.

Legacy System — AG0_MultiFunctionDisplayComponent

The original approach. A single component on the vehicle root manages all MFD slots. Slots are referenced by their SlotManager slot name via AG0_MFDSlotConfig entries. All screens share a common Available Pages pool.

Use when: Setting up a modern glass-cockpit helicopter or ground vehicle with uniform digital displays.

Slot-Based System — AG0_MFDManagerComponent + AG0_MFDSlotComponent

The newer, modular architecture. A lightweight manager component sits on the vehicle root, and each physical MFD slot entity carries its own AG0_MFDSlotComponent with an independent page set and default page index. Slots self-register with the manager during initialization — there is no fixed screen count limit.

Use when:

• Your vehicle has non-uniform displays (e.g., a mix of steam gauges and a digital MFD)
• You need more than 5 MFD screens on one vehicle
• You want per-display page configurations independent of one another (e.g., a Vietnam/D-model Chinook with dedicated steam gauge panels)

The legacy AG0_MultiFunctionDisplayComponent is preserved for backwards compatibility. Existing vehicle prefabs do not need to be migrated.

Set Up

<aside> ⚠️

Please do not create modded overrides for the component script, as it will affect all vehicles with the MFD ScriptComponent. For custom display behavior, use the Custom Handlers system (see the Custom Handlers section below) — you can create your own handler classes that inherit from AG0_MFDCustomHandlerConfig and override the UpdateHandler method.

</aside>

As of this point in time no screens are included with the mod (eventually will come with some). To make a screen in Blender, add a mesh (plane) and assign a material to it. After manipulating screen size, unwrap the UV map onto the material/texture. You can use texture editor to draw a smiley face on the screen to ensure that it shows up properly on the texture. Collider is necessary if you have a destruction component on the screen’s prefab - you can add one to future proof and prevent issues down the road. Due to game limitations for render targets - using SlotManager is a requirement.