Universal Factory Tycoon DOCUMENTATION

Universal Factory Tycoon Framework - Documentation

Reviewed against the UE 5.7 and UE 5.8 plugin copies on 13 September 2026.

Support: https://discord.gg/9Zc4wbwqG9

CONTENTS

1. Purpose and Scope
2. Framework Mental Model
3. Content Organization and Naming
4. Core Player Integration
5. Game Rules
6. Items, Tools, Equipment, and Quickbar
7. Inventories and Storage
8. Recipes, Crafting, and Machines
9. Ports and Component Bindings
10. Factory FX, Audio, and Moving Parts
11. Building, Placement, and Dismantling
12. Conveyors and Junctions
13. Fluids
14. Power
15. Resources, Biomass, and Scanning
16. Vehicles, Truck Stations, and Autopilot
17. Railways, Trains, and Freight Platforms
18. Drones and Drone Ports
19. Quests
20. Multi-Stage Projects
21. Map, Minimap, Compass, and Markers
22. Codex / Encyclopedia
23. User Interface Customization
24. Main Menu, Settings, Sessions, and Chat
25. Save, Load, Autosave, and Player Identity
26. Dedicated Servers
27. Weather and World Presentation
28. Multiplayer Authority and Replication Rules
29. World Partition and Performance
30. Extending the Framework Safely
31. Data Validation and Release Checklist
32. Troubleshooting
33. Shipped Demonstration Content
34. Quick Reference: Common Blueprint Actions
35. Terminology
36. Support Information

===============================================================================
1. PURPOSE AND SCOPE
===============================================================================

Universal Factory Tycoon Framework (UFT) is a data-driven Unreal Engine gameplay
framework for first-person or third-person factory, automation, logistics, and
tycoon games. It supplies the reusable gameplay layer: items, tools, inventories,
building, machines, recipes, power, fluids, conveyors, trucks, trains, drones,
quests, multi-stage projects, map exploration, Codex entries, multiplayer,
dedicated servers, saving, settings, and customizable UI.

UFT is not a fixed finished game. The included factory, world, character, UI,
audio, meshes, recipes, and maps are an editable demonstration of the framework.
You are expected to substitute your own art, balance, game rules, Blueprints,
widgets, and game-specific logic while retaining the underlying C++ systems.

This manual documents how to use and extend the framework inside an Unreal
project. Project setup steps are intentionally omitted.

Current package footprint:

- One Runtime module and one Editor module.
- 153 reflected C++ UCLASS declarations.
- 650 .uasset files plus 2 demonstration maps (.umap).
- Within those assets: 69 Blueprint-family assets and 78 DA_-prefixed framework
Data Assets. The 69 comprise 51 Actor/Object Blueprints, 13 Widget Blueprints,
2 Animation Blueprints, and 3 Control Rig Blueprints.
- Supported engine versions: UE 5.7 and UE 5.8.
- Runtime targets: Win64 and Linux. The supplied Editor module is Win64-only.
Windows is the supported editor/development platform. Linux validation covers
headless runtime/server use; it does not establish Linux editor or rendered
Linux client support.

Required Unreal plugins declared by UFT are Niagara, ACLPlugin, ControlRig,
InterchangeAssets, EnhancedInput, ProceduralMeshComponent, OnlineSubsystem, and
OnlineSubsystemNull.

===============================================================================
2. FRAMEWORK MENTAL MODEL
===============================================================================

Most UFT gameplay is assembled from four layers:

1. Definitions
Data Assets describe items, tools, recipes, buildables, quests, projects,
maps, scans, Codex content, fluids, and visual profiles. Definitions are
reusable data and should have stable, unique IDs.

2. Runtime actors and components
Actors perform production, storage, transport, power, interaction, or world
logic. Components supply inventories, item/fluid/power ports, save identity,
markers, moving visuals, FX, and player-facing features.

3. Catalogs and subsystems
Catalogs decide what content belongs to a game. Subsystems provide shared
authority, registries, save/load, power networks, map state, game rules,
sessions, and other global services.

4. Presentation
Native C++ widgets provide a complete default interface. Blueprint widget
subclasses can replace the presentation while using the same authoritative
data and action nodes.

The intended buyer workflow is composition rather than editing plugin C++:

- Create or duplicate a definition.
- Create a child Blueprint of the relevant general UFT actor.
- Add the exact visual, inventory, port, FX, and helper components needed.
- Bind those components in the actor's Factory categories.
- Add the definition to the relevant catalog.
- Validate the assets and test authority, saving, and multiplayer behavior.

Avoid adding game-specific meshes, IDs, recipe assumptions, or UI casts to the
framework source. Put product-specific work in your own project/plugin content.

===============================================================================
3. CONTENT ORGANIZATION AND NAMING
===============================================================================

The shipped content is organized under these top-level plugin folders:

- Core: building, interaction, and UI foundations.
- Demo: characters, maps, modes, input, audio, Codex examples, and environment.
- Factory: machines, crafting, extractors, structures, and storage.
- Items: item definitions, tools, recipes, and catalogs.
- Logistics: conveyors, vehicles, rail, and drones.
- Networks: fluids and power.
- World: resources, scanning, maps, weather, quests, and staged projects.
- Localization: plugin localization target data.

Recommended prefixes:

- BP_UFT_... for Actor/Object Blueprints.
- WBP_UFT_... for Widget Blueprints.
- DA_UFT_... for Data Assets.
- T_UFT_... for textures and icons.
- SM_UFT_... for static meshes.
- SK_UFT_... for skeletal meshes.
- ABP_UFT_... for Animation Blueprints.
- NS_UFT_... for Niagara systems.
- S_UFT_... for sounds.

For your own product, keep the UFT prefix only when the asset is genuinely part
of the framework integration. Product-specific content can use your own prefix.
Do not rename IDs after saves have shipped unless you also provide migration.

===============================================================================
4. CORE PLAYER INTEGRATION
===============================================================================

UUFTFactoryPlayerComponent is the main player-side integration component. The
demonstration PlayerController shows a working configuration. It coordinates:

- Player inventory and equipment.
- Quickbar assignment and tool fuel.
- Interaction traces and prompts.
- Builder, placement, and dismantle modes.
- Scanner and map tracking.
- Factory, inventory, Codex, settings, and map widgets.
- Crafting and machine actions.
- Vehicle driving and route recording.
- Multiplayer-safe requests for stations, trains, and drones.
- Chat, health-facing UI, game settings, and exit-save recovery.

The component belongs on the locally controlled player/controller arrangement
used by your game. Its inventory, builder, scanner, Codex, and UI references must
point to the catalogs and classes used by that game mode.

Important authority rule:

- Read-only getters may be called freely by UI.
- Mutations marked BlueprintAuthorityOnly must run on the server.
- For multiplayer UI, use the action/request nodes exposed by
UFTFactoryPlayerComponent. These route the request to authority and validate
ownership, range, current state, permissions, costs, and rate limits.
- Do not directly edit replicated arrays or actor state from a client widget.

The framework guards local widgets, viewport work, cosmetic audio, and previews
from dedicated-server execution. Preserve that separation in custom code: do not
create widgets or access a viewport on a headless server.

===============================================================================
5. GAME RULES
===============================================================================

FUFTGameRules provides two principal creative/demo options:

- No Power Mode: systems that opt into the framework power rules bypass normal
grid-power requirements.
- No Item Costs (Build, Craft And Projects): supported building, crafting,
project delivery, and configured fuel/item-cost paths become free.

Use UUFTGameRulesSubsystem to read or apply the active rules. Do not duplicate
creative-mode checks in every Blueprint. Systems such as tools, vehicles, drones,
and generators expose explicit bypass policies where their behavior needs a more
specific decision.

When testing, cover all four combinations of power and item-cost rules. A system
must not divide by zero, require an impossible fuel buffer, or remain visually
unpowered merely because a creative rule bypasses its normal resource source.

===============================================================================
6. ITEMS, TOOLS, EQUIPMENT, AND QUICKBAR
===============================================================================

6.1 Item definitions

Create item content with UUFTItemDefinition. The important fields are:

- ItemId: stable, unique gameplay identity.
- DisplayName and Description: localized player-facing text.
- IconTexture and WorldMesh: inventory and world/conveyor presentation.
- MaxStackSize and MassKilogramsPerUnit.
- AllowedEquipmentSlots.
- FuelEnergyMJ when the item is a fuel source.
- ItemTags for filters and game-specific classification.
- Optional conveyor skeletal/animation/custom visual policy, scale, and Z offset.
- Extensions for product-specific metadata without modifying the base class.

MaxStackSize must be positive. Keep quantities within realistic int32 ranges;
the framework validates economic boundaries, but enormous imported values are
not meaningful game balance.

6.2 Tool definitions

UUFTToolDefinition extends an item with active-use behavior:

- Whether fuel is required.
- Fuel capacity, fuel used per action, initial fill, and auto-refill behavior.
- An allow-list of accepted fuel item definitions.
- Whether No Power or No Item Costs bypasses tool fuel.
- Equipped actor class, static or skeletal visual, socket, and relative transform.
- Tool and character animation settings.
- Use range, damage, cooldown, and trace rules.
- Biomass/resource tag compatibility.
- Sound, volume, loop, aiming, and Niagara impact settings.

Useful nodes include Uses Fuel, Is Fuel Configuration Valid, Get Initial Fuel
Units, and Get Fuel Units For Item. A newly crafted tool can begin full when its
definition requests it. Stateful tool fuel is saved with the player's inventory
and is not merged like ordinary stateless item stacks.

6.3 Equipment and quickbar

Use the UFTFactoryPlayerComponent equipment nodes to equip, unequip, use, query,
and refuel tools. Use its quickbar nodes to assign and select slots. A quickbar
entry references actual inventory state; when the underlying item leaves the
inventory, the framework clears the stale assignment.

Custom quickbar presentation derives from UUFTQuickbarSlotWidget. The complete
HUD owns QuickbarSlotWidgetClass, allowing you to replace only the appearance
of each slot while retaining native selection and inventory behavior.

===============================================================================
7. INVENTORIES AND STORAGE
===============================================================================

UUFTInventoryComponent is a reusable replicated inventory. You can add as many
inventory components as an actor needs rather than relying on hardcoded machine
slots.

Principal configuration:

- MaxSlots.
- Accept any item or an accepted-item allow-list.
- Per-item maximum overrides.
- Optional positive-fuel-only filtering.
- Whether the inventory participates in dismantle refunds.
- Startup stacks.
- Replication audience.

Principal operations:

- Get Stacks, Count Item, Can Accept, Add, Remove, and Clear.
- Atomic add/remove stack operations.
- Move Stack To Index, merge matching stacks, transfer between inventories,
swap unlike stacks, and sort.

Matching ordinary stacks merge up to MaxStackSize before a remainder is left.
Stateful fuel tools are kept distinct so per-instance fuel is not destroyed.

Use AUFTStorageActor for item storage and AUFTFluidStorageActor for fluid storage.
Both support buyer-added storage/port components and explicit bindings. A fluid
storage actor can also act as an extractor when configured with a fluid resource
zone, extraction rate, and power rules.

Dismantling gathers refundable item inventories in addition to construction cost
and travelling conveyor items. If the player cannot hold the full result, the
framework uses its overflow/rejection behavior rather than silently deleting
items. Converted energy is not a physical item and is not refunded; actual fuel
items in refundable inventories are returned. Stored fluids are not converted
into item stacks automatically—design a product-specific fluid recovery rule if
your game requires one.

===============================================================================
8. RECIPES, CRAFTING, AND MACHINES
===============================================================================

8.1 Recipe definitions and catalog

UUFTRecipeDefinition describes:

- RecipeId and RecipeRevision.
- DisplayName, icon, and extension data.
- Item and fluid inputs and outputs.
- CraftingTimeSeconds and power requirement.
- Allowed machine types.
- Behavior policy and optional per-machine timing/output overrides.

Collect recipes in UUFTRecipeCatalogDefinition. The catalog can return recipes
compatible with a machine type. IDs must be unique, quantities valid, timing
positive, and the machine/output combination meaningful.

Select the player-facing catalog on your Player Controller Blueprint:
UFTFactoryPlayerComponent -> Factory -> References -> Recipe Catalog. This is
the catalog used by the shared menu; it is not an inventory on the controller.
A crafting bench can optionally use Recipe Catalog Override. The selected recipe
and allowed machine type still belong to the relevant production actor.

8.2 Generic machine actor

AUFTMachineActor is the main reusable production actor for smelters,
constructors, foundries, assemblers, and custom machines. Prefer child Blueprints
of this general actor instead of creating a new C++ subclass for every machine.

Recommended Blueprint composition:

1. Keep the neutral root.
2. Add your static and/or skeletal visuals.
3. Add the required UUFTInventoryComponent and/or fluid container components.
4. Add UFT item, fluid, and power ports.
5. Bind storage and ports through the Machine Actor detail categories.
6. Add moving-part and Factory FX components as needed.
7. Set machine type, recipe selection, clock speed, and power.
8. Create a UUFTBuildableDefinition that spawns this Blueprint.

Machine storage and port binding rows use a component picker through
FComponentReference. A unique component tag is the fallback for legacy or
dynamically created components. If neither resolves exactly one compatible
component, the binding fails closed and logs a useful configuration problem.
Call the actor's refresh configuration functions after changing bindings at
runtime.

The machine commits an immutable craft batch when inputs are paid. That snapshot
retains resolved inputs, outputs, duration, recipe revision/economic signature,
and machine type until delivery. If output space is full, the finished batch
waits without consuming another set of ingredients. Use Set Recipe and the
validated setters; do not write protected runtime state around those guards.

Set Production Enabled supplies the player-facing start/stop control. Craft
progress, time remaining, waiting state, power state, and input/output stacks are
available to custom widgets.

Ports are connections, not numbered recipe ingredient slots. By default all
item inputs feed the machine's shared Input Inventory and all item outputs draw
from its shared Output Inventory. Selecting a recipe filters inputs to its valid
input item types; it does not assign ingredient 1 to port 1. Additional ports
provide additional connections, not extra production or duplicated output.

Normal crafting consumes the primary Input Inventory and delivers into the
primary Output Inventory. A per-port inventory override does not automatically
merge that separate inventory into crafting. Configure the shared inventories,
or provide explicit transfer/custom processing logic for separate buffers.

The standard machine fluid recipe path supports at most one distinct input fluid
and one distinct output fluid, using shared input/output tanks. Adding more
fluid ports does not turn it into a multi-fluid processor.

8.3 Crafting bench

AUFTCraftingBenchActor supports player crafting, recipe eligibility, craft count,
duration, failure reasons, active progress, and completion delegates. Custom UI
should react to its state/data-change signals and update only changed rows where
possible. Do not rebuild a large inventory every frame.

8.4 Miner/resource extractor

AUFTMinerActor is the general extractor. Add and bind the desired output
inventory, output item port, power port, visual, collision, and FX components.
It can use an assigned resource node or a directly configured item, automatically
find/reassign a node, and exposes cycle interval, items per cycle, output limits,
grid power, pause/enable, and policy overrides.

Use a static collision shell when an animated skeletal mesh has no suitable
physics asset. Keep that shell visible for collision/navigation but hidden in
game if the skeletal visual supplies the rendering.

8.5 Custom production behavior

Where exposed data is insufficient, derive a Blueprint or C++ policy class and
override the intended extension point. Prefer policies, events, and components
over editing the shared native state machine. This preserves saving,
multiplayer authority, output blocking, and UI compatibility.

===============================================================================
9. PORTS AND COMPONENT BINDINGS
===============================================================================

UFT ports are reusable components that you place and rotate on their own
Blueprints.

9.1 Item ports

UUFTPortComponent supports Input or Output direction, filters,
a linked inventory, exposure to transport, and connection/disconnection.

9.2 Fluid ports

UUFTFluidPortComponent supports Input, Output, or Bidirectional flow, a linked
fluid container, and optional simple head-lift data. Junction ports are normally
Bidirectional; the connected network and pressure/availability determine the
actual transfer direction at runtime.

9.3 Power ports

UUFTPowerPortComponent supports Input, Output, or Bidirectional power behavior,
maximum cable connections, optional cable continuation (for poles), generation
and consumption MW, priority/partial-power behavior, and On Power State Changed.
The event performs an initial synchronization and reacts to connection, network,
generation, and game-rule changes. This allows Blueprint red/green lights on
consumers, poles, and generators.

9.4 Physical transform versus indicator transform

Every port has two distinct concepts:

- Connection World Transform: the real point at which a cable, belt, or pipe is
connected and built.
- Placement Indicator Relative Transform: the cosmetic arrow shown during
placement so the direction remains readable outside a mesh.

Moving the indicator must never move the physical snap point. Configure the
component itself for the connection and the indicator transform only for the
arrow.

9.5 Binding rules

Binding fields vary by actor. Named storage/connection roles are used where that
actor needs them; a selected component is not itself a universal Role value.
Machine item-port bindings include direction and optional inventory selection;
fluid bindings have their own container/flow settings. Match the binding to the
selected component and the actor's storage contract.

Select Port Component in the picker when possible. Component Tag is a fallback
for a component that cannot be referenced directly or is constructed dynamically.
Use a unique tag; do not give two compatible components the same fallback tag.

===============================================================================
10. FACTORY FX, AUDIO, AND MOVING PARTS
===============================================================================

UUFTMovingPartComponent is a skeletal mesh component intended for animated
machine parts. A normal UStaticMeshComponent is sufficient for a static moving
visual controlled by your own Blueprint. Neither needs a separate reference when
the host can discover it by configured component/tag; use the relevant binding
when a system provides one.

UUFTFactoryFXComponent supplies reusable Niagara and audio behavior for machines,
generators, extractors, drones, vehicles, and other compatible hosts. It can bind
to body/moving-part components and an explicit power-state port.

Audio playback modes are:

- Loop While Working.
- Play Once When Machine Starts Working.
- Play Once When Machine Stops Working.
- Play Once When Power Is Gained.
- Play Once When Power Is Lost.
- Loop While Powered.

Continuous-loop styles are:

- Use Sound Asset Loop: honors the asset's looping behavior; continuous playback
can restart a non-looping sound. Use the crossfade mode when a seam is audible.
- Crossfade Loop Region: loops a selected region with configurable start, end,
crossfade, and fade durations to hide an imperfect source seam.

Each entry can configure start delay, volume, pitch, socket/offset, and inline 3D
attenuation inner radius/falloff. Multiple entries may be combined—for example a
startup one-shot followed by a delayed powered loop. Start/stop one-shots fire
again on later genuine transitions; silent initial synchronization prevents a
load from producing false transition sounds.

For a sound that should continue whenever a machine has electricity, choose
Loop While Powered. Loop While Working intentionally follows active production
and will pause between recipes or while output is blocked. Drones use their
flight state as working state, so a flight loop stops while docked or waiting.

The Factory FX component handles replication-derived state locally. Do not mark
individual audio components replicated; replicate authoritative machine/vehicle
state and let each client play its local presentation.

===============================================================================
11. BUILDING, PLACEMENT, AND DISMANTLING
===============================================================================

11.1 Buildable definition

UUFTBuildableDefinition connects a build-menu entry to an actor class and its
placement rules. Configure:

- Stable BuildableId, display name, description, icon, and menu placement.
- ActorClassToSpawn.
- Static, skeletal, or composite preview visuals.
- BuildCost and optional length-scaled cost.
- Placement mode: ordinary actor, conveyor, pipe, cable, railway, structural,
drone, or other supported specialized flow.
- Target class/tag filters, resource/drone/rail/fluid-zone constraints.
- Surface/rotation/offset/footprint rules.
- Navigation-obstacle policy.
- Valid and invalid placement materials.
- Default unlocked state and gameplay tags.

Collect definitions in UUFTBuildCatalogDefinition. The builder reads its unlocked
entries from the catalog. Default unlocks are appropriate for the first playable
technology tier; quests or game logic can unlock later entries.

11.2 Runtime placement

Use the UFTFactoryPlayerComponent/UUFTBuilderComponent selection and placement
nodes. The preview predicts locally, but the server validates the final request:
distance and tolerance, line of sight/reachability, requested class and catalog
unlock, port compatibility, collision/footprint, and material affordability.
Remote requests are rate limited. A green local preview is not authority by
itself; custom placement policies must produce equivalent server-verifiable data.

Placement indicators have configurable attraction distances so players can aim
near compatible ports or structure snap points. Specialized builders surface
specific errors such as maximum length, incompatible port, invalid terrain,
missing track, insufficient cost, or changed target state.

11.3 Dismantling

Dismantling is an authoritative transaction. It gathers the exact charged build
cost, refundable child inventories, and travelling conveyor items, then handles
connected infrastructure so cables or segments do not remain floating. Cable
actors can be dismantled directly without requiring destruction of a shared pole.

Factory FX can provide a dismantle sound. Keep it on a locally heard component or
framework presentation path, not a duplicated server audio emitter.

11.4 Custom placement policy

Use a placement-policy class when a product needs a rule the definition cannot
express. The policy should be deterministic, reject non-finite transforms, and
work on both preview and server validation. Never trust an arbitrary client world
coordinate as the final authority.

===============================================================================
12. CONVEYORS AND JUNCTIONS
===============================================================================

AUFTConveyorBeltActor represents a spline conveyor with replicated travelling
items. It supports terrain-conforming placement, data-driven visual profiles,
supports/legs, item pickup, connected-machine backpressure, and character carry.

UUFTConveyorVisualProfile controls mesh mode, forward/up axes, nominal segment
length, support visuals, and related presentation. Support legs follow the belt
inclination and use configurable inset/height behavior to reduce overlap on
slopes and sharp transitions.

Conveyor rules:

- A belt output may continue carrying an item even if the destination machine
currently rejects it; the packet waits at the end under backpressure.
- A full closed loop can halt because every segment waits for space in the next.
This is expected saturation behavior. Add a buffer, consumer, splitter bypass,
or free slot to break the deadlock.
- Dismantling refunds travelling item stacks.
- Pickup traces use packet-aware interaction so a visible prompt corresponds to
the selected travelling item.
- Terrain conforming can ignore actors that explicitly opt out, while tall trees
or real blockers may still prevent or shape a route according to their policy.

AUFTConveyorJunctionActor is the general splitter/merger base. Add any number of
UFT item ports, set one or more inputs/outputs, bind them, and configure its mode,
filter rules, output priority, and buffer inventory. Smart, programmable, split,
merge, and priority behavior are data/Blueprint configurations of the general
junction rather than separate required native classes.

Input Priority Order and output/filter rules only affect routing when configured.
Leaving them empty uses the actor's normal compatible round-robin/default flow.
Validate that every role matches the direction on its selected port.

Conveyor lifts provide a validated vertical route and participate in Unreal Data
Validation for dimensions and route settings.

===============================================================================
13. FLUIDS
===============================================================================

Fluid content begins with UUFTFluidDefinition. Fluid storage uses
UUFTFluidContainerComponent, which owns capacity, current fluid type and amount,
type compatibility, and authoritative add/remove/clear operations.

The fluid network includes:

- Spline fluid pipes with terrain conformance, supports, flow limits, current
flow information, enable state, and optional simple head lift.
- General fluid junctions, including straight, T, and cross configurations.
- Valves with opening and flow-limit control.
- Pumps with power demand and head-lift contribution.
- Fluid storage actors and resource-zone extraction.
- Fluid resource zones with finite or infinite supply and placement projection.

Recommended pipe/junction setup:

1. Add a fluid container to every actor that stores fluid.
2. Add fluid ports at the real pipe connection locations.
3. Set consumer ports to Input, producer ports to Output, and manifold/junction
ports to Bidirectional.
4. Bind each port to its container and actor binding row.
5. Set compatible fluid filters/capacity and validate the asset.

Bidirectional does not force simultaneous flow in both directions. It permits the
network to resolve the active direction from connected availability and demand.

The optional head-lift model is intentionally a simple gameplay abstraction, not
a computational-fluid-dynamics solver. It represents how high a source/pump can
push fluid. Design pump spacing and maximum elevation around your game's scale,
and test branched networks under full and empty conditions.

Stored fluid is saved as container state. Dismantling does not automatically
turn litres into inventory items; provide canisters, a drain action, or a custom
overflow actor if physical fluid recovery is part of your design.

===============================================================================
14. POWER
===============================================================================

The power system forms server-authoritative networks from UFT power ports and
cables. It tracks generation, demand, supplied power, priority, partial supply,
battery state, brownouts, and history/statistics.

14.1 Consumers and generators

For a consumer, add a power port configured as Input and set its consumption.
For a generator, configure a power port as Output and set generation. A power
generator can also expose:

- Fuel inventory binding and accepted fuel definitions.
- Whether fuel is required.
- Generation capacity.
- Maximum cable connections.
- Enable state and current-fuel runtime estimate.

Power demand is not the same as available generation. A 100 MW generator can
brown out with three machines if their combined demand, clock scaling, losses,
or priority rules exceed 100 MW. Query network statistics rather than assuming
that a visible cable means sufficient power.

No Power Mode supplies effective power through the framework rule path. The
Power Port's On Power State Changed event still performs an initial effective
state update, allowing lights and UI to show the correct result.

14.2 Cables and poles

Power cables connect compatible power ports. Ground placement spawns a separate,
customizable pole actor and connects to its port. This allows a buyer-authored
pole Blueprint to contain any meshes, skeletal animation, lights, sound, logic,
and number of allowed connections.

Maximum Cable Connections belongs on the actual power port that accepts the
cables. Set it higher on a generator or pole when that endpoint should fan out.
Both endpoints must have available compatible capacity. Generator output ports
can connect to other generator outputs to share a grid. The solver sums each
active generator's capacity once; connecting generators does not multiply an
individual generator's rating or guarantee enough power for every consumer.

Cables watch endpoint ownership. Dismantling a machine or pole removes affected
cable segments and refunds their paid cable cost. Removing one cable should not
force destruction of an otherwise valid shared pole.

14.3 Batteries and history

Batteries expose stored energy and charge fraction. The power subsystem provides
network statistics and historical samples for UI/graphs. Configure history length
and sampling for the presentation you need; avoid retaining unnecessary high-
frequency samples in very large factories.

===============================================================================
15. RESOURCES, BIOMASS, AND SCANNING
===============================================================================

15.1 Resource nodes

AUFTResourceNodeActor supplies extractor and manual-mining content. Configure its
item definition, extraction properties, manual-mining cooldown/results, surface
deposit behavior, visuals, collision, marker, and effects. Nodes register with a
world registry so scanners do not repeatedly traverse the whole world.

15.2 Biomass nodes

AUFTBiomassNodeActor supports health, multiple harvests, regrowth, random visual
selection, accepted tool tags, collection/hit effects, and performance profiles.
Its interaction prompt can explain a missing required tool. Settings distinguish
visual/harvest collision from whether an actor affects terrain-conforming
logistics, rail placement, or moving logistics vehicles.

Use the biomass performance settings/profile for dense forests. Validate Nanite
and collision choices against the intended harvest method; visually complex
per-poly collision is rarely appropriate for thousands of plants.

15.3 Resource scanner

Put scannable definitions in UUFTResourceScanCatalog and assign the
catalog to the player's scanner integration. Scans are server-routed, cooldown
validated, and resolved through the node registry/spatial query. Results create
expiring pings that can drive scanner UI and world-space direction markers.

Custom UI uses the scanner component's available targets, selected target,
request action, result pings, expiry, and data-change events. Do not run a full
Get All Actors Of Class scan from every client.

===============================================================================
16. VEHICLES, TRUCK STATIONS, AND AUTOPILOT
===============================================================================

16.1 General logistics vehicle

AUFTLogisticsVehicleActor is the reusable truck/ground-vehicle base. A buyer can
bind:

- Static or poseable skeletal visual.
- Required physical chassis primitive (shape, static mesh, or skeletal mesh).
- Optional interaction collision; the chassis may be reused.
- Optional obstacle proxy; it may be derived from the body.
- Driver parking/seat anchor.
- Cargo and fuel inventories.
- Camera boom and camera.
- Route-break diagnostic visualization.

The Driver Parking Anchor is a safe temporary location/state reference for the
character while driving. It is not the visible driver seat mesh. Manual-drive
entry/exit preserves character possession, suspends hazardous character behavior,
searches for a collision-safe ground exit, and provides non-failing cleanup if a
pawn is destroyed or replaced.

Wheel behavior is data driven and supports any reasonable wheel count. Each
wheel can reference a component or poseable-skeleton bone, or expose state only.
Configure radius, suspension, steering/drive roles, and axes. Runtime wheel state
and visual events allow custom animation without hardcoded wheel components.

16.2 Navigation modes

Vehicle navigation modes are:

- NavMesh (default): route between timetable stations over Unreal navigation.
- Recorded Vehicle Route: follow an authored/recorded spline route.
- Both: use a compatible recorded route with NavMesh fallback.

NavMesh mode requires an enabled, reachable station in the timetable and a valid
RecastNavMesh covering the driveable area. Factory meshes must affect navigation
through collision/navigation settings or an explicit UFT obstacle policy.

NavMesh Path Re-query Interval Seconds (previously named Nav Mesh Path Rebuild
Interval Seconds) is a path re-query interval. It asks
Unreal for a fresh path around changed obstacles; it does not rebuild the entire
NavMesh or force all runtime tiles to regenerate. A value of zero keeps the path
until its target changes or blocking recovery requests another path.

A point-sized NavMesh path alone does not guarantee clearance for a truck body.
Use Get Vehicle Navigation Agent Size and configure a matching Supported Agent
with sufficient radius and height. The Windows editor helpers Configure Vehicle
Navigation Agent / Configure Vehicle Navigation Agent From Class assist with
this configuration. Build the navigation data for the intended vehicle size.

For runtime construction, use Dynamic navigation generation when new geometry
needs to be added. Dynamic Modifiers Only changes areas on existing navigation
data and is not a substitute for generating new collision geometry. Check the
mesh/navigation relevance and actual collision, not just the visible mesh.

A UFT Vehicle Navigation Obstacle component can exclude road-vehicle navigation
from a volume, for example a freight-platform opening suitable for trains but
too low for trucks. It is a navigation area, not a physical collision box, so
it can block road pathfinding without obstructing rail movement. Its lack of
gameplay collision is intentional; keep the owning actor collision enabled.

Predictive path validation is optional and disabled by default. It supplements
proper navigation-agent sizing; it is not a guarantee that arbitrary vehicle
shapes can traverse every route. Physical obstacle/stall recovery remains
necessary.

Recorded routes are created by driving a vehicle and using Start Recording
Vehicle Route, Finish Recording Vehicle Route, or Cancel Recording Vehicle
Route. Recording can conform points to ground, enforce spacing, capture station
stops only under configured speed/hold conditions, and play an event/sound when a
station is captured. Draft routes are excluded from discovery, assignment, and
persistence until successfully finished.

16.3 Autopilot and movement

Route behavior can be Loop, PingPong, or Once. Stop sources can be route-owned or
vehicle-specific. Wait rules can be Timer Only, Until Loaded, Until Unloaded, or
Until Transfer Complete.

Chaos is the recommended/default physical autopilot mode. A deterministic
kinematic alternative remains available for projects that prefer it. Chaos
autopilot includes obstacle/stall detection, uphill force, reverse-and-steer
recovery near blocked stations, unattended rollover recovery (including an
overturned saved vehicle), and path retries. Recovery requires usable space and
support; it cannot make an impossible slope or corridor driveable. Manual Chaos driving uses
server authority plus owner-client prediction/smoothing for multiplayer input.

The route system checks vertical separation so a truck on one factory floor does
not choose a route or station on another floor merely because it is close in XY.
Connected-route diagnostics can expose gaps that prevent path resolution.

16.4 Fuel

Vehicles can require fuel and maintain both fuel item stacks and a converted MJ
buffer. Fuel UI should show total usable energy rather than only one inventory
slot. No-cost game rules can provide a safe virtual buffer when the vehicle is
configured to permit the bypass.

Running out of fuel removes traction but does not unrealistically zero all
coasting speed in one frame. Dismantling discards remaining converted energy but
returns physical fuel items from refundable inventories.

16.5 Truck stations

AUFTTruckStationActor supports buyer-authored visuals, dock point, input/output
inventories or fluid storage, item/fluid ports, fuel inventory/port, power port,
filters, and station events.

Transfer modes are Load Vehicle, Unload Vehicle, Load And Unload, None, or Use
Station Default. Compatible cargo can transfer all at once by default. Loading
and unloading use independent logic so a full unload buffer does not permanently
prevent a valid load operation. Refuel Vehicles is enabled by default for station
types intended to service vehicles.

Precise dock snapping is optional. The default behavior can preserve the
vehicle's physical arrival pose and stop in a valid service area. UI should label
station buffers, mode, power, alignment, compatibility, and the exact result:
source empty, destination full, fluid mismatch, wrong vehicle, no power, or
rate-limited service.

===============================================================================
17. RAILWAYS, TRAINS, AND FREIGHT PLATFORMS
===============================================================================

17.1 Track

AUFTRailRouteActor represents railway spline track. Configure gauge, connection
tolerance, minimum curve radius, maximum grade, vertical-curve/roll limits,
visual mesh, and reparameterization steps. Placement validates the configured
track limits. These limits must match the intended locomotives and freight cars;
they cannot guarantee compatibility with every later buyer-authored vehicle.
Coupler placement on curves also needs enough connected, unoccupied rail for
the new car and its coupler alignment.

Connected track topology is cached and rebuilt when dirty rather than sorted and
reconstructed every frame. Track dismantling checks occupancy so an active train
is not left suspended on a deleted segment. Active locomotives can provide World
Partition streaming influence along their approach.

17.2 Stations versus platforms

A Train Station is a directional timetable stop and service header. Adjacent Item
or Fluid Freight Platforms perform wagon cargo transfer. Direct platform stops
are also supported where the schedule design calls for them.

Do not treat a freight platform as a hidden duplicate Train Station. Recommended
layout:

- Place the Train Station at the locomotive/header position.
- Place one platform per intended wagon position along the track.
- Give every platform an explicit/automatic wagon index or pairing rule.
- Associate platforms with their parent station.
- Add the Train Station to the locomotive timetable.

17.3 Freight platforms

Item and fluid freight platforms support:

- Buyer-authored centerline anchor, dock point, visual, storage, item/fluid,
fuel, and power components.
- Automatic nearest-wagon pairing or explicit consist index/side.
- Separate loading and unloading buffers.
- Load, Unload, or Load And Unload behavior.
- Transfer-all-compatible-at-once by default.
- Vehicle refueling when enabled and the locomotive service position is valid.
- Diagnostics for candidate wagon, dwell, alignment, ownership, and correction.

The Rail Centerline Anchor is the physical placement reference and must be
resolved from the selected Blueprint component binding. A decorative arrow or
mesh origin is not the rail snap point.

17.4 Locomotive and consist

AUFTLocomotiveActor supplies traction, fuel, timetable, manual driving, signal
lookahead, station dwell, consist mass/braking, and recovery. AUFTRailFreightCarActor
is a universal wagon that can be configured for item, fluid, empty, or loaded
visual states.

Coupler anchors define actual front/rear connection points. Derived spline
spacing keeps wagons smooth through S-curves and elevation changes. Automatic
coupling validates alignment, speed, position, consist slot, and mass limits.
Building a wagon near a consist should snap to the available coupler, not an
arbitrary mesh-center offset.

Physics includes progressive braking, grade forces, curvature speed envelopes,
traction configuration, and consist-aware mass/brake statistics. Manual telemetry
can expose speed, brake state, gradient, and distance/aspect of the next signal.

17.5 Timetable and signals

Timetable changes from a multiplayer widget must use the UFTFactoryPlayerComponent
rail timetable nodes. Direct BlueprintAuthorityOnly actor calls from a client do
not become server RPCs.

On load, station identities and distances are reconciled before autopilot resumes.
Track redraw/topology changes invalidate and refresh cached stop distances. A
one-station closed loop completes a full circuit before servicing the same stop
again; it does not repeatedly dwell at its starting coordinate.

Signals query connected block/network occupancy and locomotive lookahead across
track-segment boundaries. Signal work uses registries/budgets suitable for larger
networks. Configure visible aspects in the signal Blueprint and test junctions
with trains spanning more than one route segment.

If a train cannot resolve a route, recover it with Recover Rail Vehicle To Nearest
Track. Recovery pauses autopilot so the player can inspect and correct track or
timetable configuration before resuming.

===============================================================================
18. DRONES AND DRONE PORTS
===============================================================================

18.1 Drone port composition

AUFTDroneStationActor is component driven. A typical port contains:

- Static collision shell and optional skeletal animated visual.
- Dock and takeoff scene points.
- Outgoing, incoming, recovery-overflow, and fuel inventories.
- Cargo input/output, fuel input, and power ports.
- A map/save identity where required.

Use the component picker in Factory -> Drone -> Storage/Components. A unique
component tag is a fallback. A static shell plus skeletal visual is usually more
performant and controllable than per-poly skeletal collision.

One separately constructed drone is assigned to one home port. The station does
not need to spawn the drone. A destination can receive several drones; they use a
fair holding/dock queue when the pad is occupied.

18.2 Cargo and fuel

Configure destination ID, dispatch enable, minimum/maximum cargo, whether empty
dispatch is allowed, fuel or electric-grid propulsion, energy per metre, reserve,
dock-service power requirement, maximum waits, and return-undelivered behavior.

Recovery overflow inventory prevents cargo deletion when the normal home incoming
buffer is full. Returned unused energy uses a reserve rather than being silently
clamped away. UI should show why a drone is queued: no power, pad occupied,
destination full, path blocked, fuel shortage, or recovery wait.

The optional cargo payload visual is cosmetic. Bind a scene component/actor class
that can show a buyer-authored crate under the drone. It appears when authoritative
cargo is present and hides when empty; the mesh itself is not the cargo record and
is not independently saved or replicated.

18.3 Flight and recovery

Drones follow staged takeoff, cruise, and landing paths. Obstacle avoidance can
raise/replan a corridor or hold when newly built geometry blocks the path. Actors
tagged UFT.IgnoreDroneObstacle can be excluded from the flight obstacle query.

Holding can be configured not to consume fuel, preventing blackout crash cascades.
Power recovery resumes the station queue fairly. Missing/unstreamed destinations
cause an undelivered return; missing home actors use cached home state and an
emergency recovery/landing path instead of leaving a permanent sky ghost. Active
drones supply World Partition streaming influence.

Station destination, cancel, and cargo-recovery actions from clients must use the
UFTFactoryPlayerComponent drone nodes. Cancellation uses server-current station
identity and race protection rather than a stale client selection.

The port menu supports Recover And Dismantle Drone on UFTFactoryPlayerComponent,
passing the station actor. This avoids requiring a cursor hit on a collisionless
or skeletal drone. The authority path validates recovery/refund capacity and
handles cargo and refundable items; it is not a currency sale. A port with an
assigned drone must recover/dismantle that drone before the port is dismantled.

UUFTFactoryFXComponent can be placed on a drone vehicle. Its working loop follows
active flight and stops for docked/loading/holding states according to the host
state contract.

===============================================================================
19. QUESTS
===============================================================================

Quest definitions are data driven. Supported objective types are:

- Reach Target.
- Interact With Target.
- Manually Mine Item.
- Have Items In Player Inventory.
- Build Buildable.
- Complete Recipe Craft.
- Produce Item In Machine.
- Custom Blueprint Event.
- Scan For Item.
- Dismantle Buildable.
- Complete Project Stage.
- Complete Multi-Stage Project.

Each objective can use an Objective ID, target actor class/Target ID, item,
buildable, recipe, project/stage, quantity, or custom filter as appropriate.
Optional objectives do not block quest completion.

Difference between the project objective types:

- Complete Project Stage fires when the selected stage of a staged project is
completed. Set the project identity/class and StageId when the quest should
track one exact construction phase.
- Complete Multi-Stage Project fires when the whole actor reaches final project
completion. It does not mean "complete any one stage."

The quest manager can run an individual-player campaign or a shared-factory
campaign. It is authoritative, replicated, and saved. The quest event subsystem
receives framework events for interaction, mining, build, dismantle, crafting,
production, scans, project stages, and custom events. Use its report nodes for
external Blueprint actions instead of manually changing quest counters.

Quest UI keeps completed objectives visible but scrolls/reveals the next active
objective. If replacing the widget, bind to manager data changes and explicitly
bring the active row into view. Completion audio is sequenced so the final
objective, quest completion, and next-quest start sounds do not play as an
unintelligible three-sound stack.

At game start/load, restored completion state is synchronized silently. Do not
play objective/quest completion audio merely because a saved completed value was
applied.

===============================================================================
20. MULTI-STAGE PROJECTS
===============================================================================

Multi-stage projects support monuments, rockets, bridges, research facilities,
and other objectives that visibly assemble over several deliveries.

A project definition contains ordered stages. Each stage can specify:

- StageId, display name, and description.
- Item and fluid requirements.
- Construction duration.
- Blueprint visual component tags revealed by that stage.
- Completion sound and Niagara effect.
- Quest/custom event identity.

The project actor owns/binds item and fluid input storage and can accept belts and
pipes. Runtime states include Waiting, Constructing, Completed, and Disabled.
It exposes requirement/current progress, delivery, enable/disable, immediate
completion, and reset operations, plus:

- On Project Stage Started.
- On Project Stage Completed.
- On Project Completed.
- On Project State Changed.

For a rocket:

1. Create one Blueprint child of the multi-stage project actor.
2. Add a permanent base and separate visual components for Foundation, Frame,
Engine, Fuel Tanks, and final assembly/launch visuals.
3. Give each staged visual a unique tag matching the stage definition.
4. Bind project item/fluid storage and ports.
5. Use On Project Completed on the server to run launch gameplay.
6. Replicate the authoritative launch state/transform; clients only play visuals.

The assembly root can be a Scene Component. Moving that root moves all revealed
parts; the root itself does not need replication if the owning actor's replicated
state or a replicated movement/launch variable drives the same transform.

In No Item Costs mode, required quantities display as fulfilled and delivery is
free. Reset Project returns the actor to stage zero for repeatable projects. Your
Blueprint should reset launch visuals/location in response to the authoritative
reset/state event rather than guessing from visibility.

===============================================================================
21. MAP, MINIMAP, COMPASS, AND MARKERS
===============================================================================

The map system uses a World Map Definition/catalog, a Map Manager actor, marker
components, per-player discovery state, and separate minimap/world-map widgets.

UUFTMapMarkerComponent can represent a point or spline line. Add it to resource
nodes, machines, stations, projects, routes, or custom actors that should appear
on the map. Configure icon/color/label/discovery behavior and make sure the marker
is enabled for the desired map layers.

The Map Manager provides:

- World-to-map UV conversion and bounds.
- Reveal/reset exploration for each player.
- Marker and polyline collection.
- Other-player display.
- Runtime orthographic map capture and refresh.
- Persistent player exploration in save data.

Map discovery is player state, including remote-player persistence on a shared
save. Projects with a custom account system should set a stable persistent player
identity so the same person receives the same exploration record after reconnect.

For a deterministic illustrated map, assign an authored Map Texture. When no map
texture is assigned, runtime capture uses a lighting-dependent Final Color view;
weather, exposure, shadows, unloaded cells, and recently dismantled geometry can
change the result. Runtime capture refresh is event/debounce driven; do not perform
a full map capture on every tick or every tiny actor mutation.

The compass and scanner marker widgets consume normalized direction/distance data.
Custom widgets should not reproduce the world/map rotation math independently.

===============================================================================
22. CODEX / ENCYCLOPEDIA
===============================================================================

The Codex is UI/data, not a world mesh. UUFTCodexComponent opens, closes,
and toggles it. UUFTEncyclopediaCatalogDefinition resolves entries, categories,
and search results.

An entry can source data from:

- Custom content.
- Item definition.
- Fluid definition.
- Buildable definition.
- Recipe definition.

Entries can include summary text, facts, sections, linked item/fluid lines, and
ordered content blocks. A content block can be Text or Image/Screenshot, with a
heading, body, caption, thumbnail, and full-size image. This supports tutorials
such as text -> screenshot -> explanation -> screenshot. The full-size image
viewer uses most of the screen and preserves an explicit close action.

Linked construction-cost items and related entries are clickable and navigate to
their own Codex records. Give every linked source a catalog entry or allow the
resolver to derive one. Search and category buttons should cache resolved entry
arrays while the menu is open; resolving and rebuilding every row on every frame
will cause visible hitches.

Recommended tutorial entry:

- Display Name: Controls and Shortcuts
- Subtitle: Learn the keys used to open and control each factory system.
- Summary: Learn which keys open your inventory, build menu, scanner, Codex,
maps, and other essential interfaces.

Long summaries must wrap and clip within result cards. Do not size cards from a
single-line text assumption.

===============================================================================
23. USER INTERFACE CUSTOMIZATION
===============================================================================

23.1 Native versus Blueprint layout

Most supplied widget bases derive from UUFTNativeLayoutWidget and expose Use
Default Native Layout.

- True: a native presentation class constructs its supplied default interface.
For the full factory menu this is UFTFactoryNativeMenuWidget.
- False in a Blueprint child: the buyer builds the Designer hierarchy and graph,
while retaining the native state, data getters, delegates, and action methods.
The UFTFactoryMenuWidget base supplies the data/action contract; it should not
be confused with the complete native presentation subclass.

Do not create a plain UUserWidget and then duplicate all authority logic. Derive
from the matching UFT widget class.

23.2 Widget classes on the player component

UUFTFactoryPlayerComponent exposes these presentation slots:

- FactoryMenuWidgetClass.
- InGameMenuWidgetClass.
- PlayerHudWidgetClass.
- MenuBackgroundBlurWidgetClass.
- CompassWidgetClass.
- MiniMapWidgetClass.
- WorldMapWidgetClass.
- ScannerScreenMarkerWidgetClass.
- InteractPromptWidgetClass.
- Z-order, pause, keep-alive, visibility, and focus settings.

UUFTPlayerHudWidget separately exposes QuickbarSlotWidgetClass.

The factory menu view enum contains Inventory, Builder, Scanner, Codex, and
FactoryActor. The same menu can therefore show general pages and the context of an
interacted machine, station, vehicle, project, or storage actor.

UUFTFactoryMenuWidget receives Initialize Factory Menu with inventory, builder,
and catalog sources. It exposes current view, inspected actor, build category,
inventory/machine/miner stacks and state, unlocked buildables, placement
selection, Open Factory Actor, Open Codex, and data-change events.

Custom UI rules:

- Cache component/catalog references once during initialization.
- Build static category/result lists only when their source changes.
- Update quantities, progress, power, and time from focused state/delegates.
- Preserve scroll offset when refreshing a freight, inventory, or recipe list.
- Route mutating button actions through UFTFactoryPlayerComponent.
- Restore game-only input mode and mouse capture when the final modal closes.
- Apply the shared background blur to menus that request focus.

Machine-specific custom menu workflow:

1. Create a Widget Blueprint derived from UFTFactoryMenuWidget (not a plain
UserWidget). Build your own hierarchy/graphs with native layout disabled.
2. On the Machine Actor, Factory -> Machine -> UI, enable Use Machine Control
Widget Override and select your class. Leave the override disabled to use the
player component's shared Factory Menu Widget Class.
3. In the widget, Get Inspected Machine Actor and check Is Valid. From that
actor read Input Inventory / Output Inventory -> Get Stacks, Get Item Input
Ports / Get Item Output Ports, fluid ports, power state, and Get Craft Progress
01 as needed. The data-change event is a notification, not a complete actor
payload containing every component.
4. On Factory Menu Data Changed is change-driven, not a fixed-frequency timer.
Initialization, view/context changes, inventory changes, and relevant source
signals can trigger it. Multiple queued changes can be coalesced to the next
tick. It is not a guaranteed progress-bar update for every production frame.
5. Use a widget tick or a short timer while visible for smooth progress/time
readouts. Update existing controls; do not reconstruct all slots or reset scroll
on each update. Stop timers and remove your delegate bindings when appropriate.
6. To close, Get Owning Player -> Get Component By Class
(UFTFactoryPlayerComponent) -> Hide Factory Menu. Check references for validity.
This lets the framework release its modal/input state; Remove From Parent alone
is not the complete close workflow.

23.3 Shipped Blueprint-only examples

The package contains editable examples under:

/UniversalFactoryTycoonFramework/Core/UI/UFT_Custom

- WBP_UFT_CustomFactoryMenu
- WBP_UFT_CustomCompass
- WBP_UFT_CustomInteractPrompt
- WBP_UFT_CustomMiniMap
- WBP_UFT_CustomPlayerHud
- WBP_UFT_CustomQuickbarSlot
- WBP_UFT_CustomScannerScreenMarker
- WBP_UFT_CustomWorldMap
- Extras/WBP_UFT_Button
- Extras/WBP_UFT_CustomMenuRow
- MainMenu/WBP_UFT_CustomMainMenu

These examples demonstrate buyer-owned Blueprint hierarchy/graph presentation
while the native widgets remain the default/reference. Their backend still uses
the plugin's C++ getters, data structures, and authority-routed actions. They are
not a separate Blueprint reimplementation of networking or the factory systems.
Choose the relevant widget class in your game/controller configuration to use
an example; merely adding the plugin does not select every custom example.

23.4 Interaction and crosshair

The interaction prompt and crosshair are separate presentation concerns. The
prompt receives action text/icon/validity from the player interaction system; the
crosshair can remain part of the player HUD. Avoid placing instruction text over
the exact center point—give it vertical and horizontal spacing for long cable or
placement messages.

===============================================================================
24. MAIN MENU, SETTINGS, SESSIONS, AND CHAT
===============================================================================

24.1 Main menu

AUFTMainMenuGameMode is a pawn-less game mode for a menu level.
AUFTMainMenuPlayerController supplies the MainMenuWidgetClass, gameplay world,
optional map catalog, factory creation/loading, session discovery/hosting/joining,
direct-IP connection, and settings actions.

Main-menu pages are Home, Play, Single Player, New Game, Load Game, LAN Host
Setup, LAN Servers, Online Servers, and Settings. A custom main-menu widget may
disable native layout and consume the same page/state/population APIs.

24.2 Game settings

UUFTGameSettingsLibrary supports:

- Monitor and resolution selection.
- Video preview with confirm/revert.
- FPS limit and freeze-while-menu behavior.
- Enhanced Input rebinding and conflict checks.
- Keyboard/mouse/gamepad presentation families.
- Master/music/effects/ambient/interface/voice audio channels when assigned.
- Look sensitivity and inverted axes.
- Subtitles, UI scale, and color-vision settings.
- Save/apply of user experience configuration.

Project Settings -> UFT User Experience supplies the Sound Mix/classes and
default gameplay input references. A custom settings menu should call the library
rather than directly writing scalability console variables without persistence.

24.3 LAN, online, and direct address

OnlineSubsystemNull provides LAN discovery for the included configuration. It is
not internet matchmaking. Internet session discovery requires a configured
provider such as EOS or Steam.

The session subsystem supports:

- Host LAN or online sessions.
- Advanced host settings and optional password.
- Find and join discovered LAN/online sessions.
- Join a custom IP/DNS address, including bracketed IPv6; port 7777 is the normal
default when omitted.
- Leave session and report asynchronous status/errors.

Direct-IP travel does not require EOS/Steam discovery, but the server must be
reachable through firewall/NAT/VPS routing. Password-protected discovered
sessions use a server-validated challenge/proof during PreLogin. A custom
GameSession must derive from AUFTAuthenticatedGameSession and call Super so the
authentication check runs before possession.

24.4 Chat

Chat is server routed and includes join/leave notices, a configurable message
length (256 default), retained history (100 default), and server cooldown (0.5 s
default). A project-owned text entry sends through UFTFactoryPlayerComponent.
Never replicate an editable widget or trust a client-supplied sender identity.

===============================================================================
25. SAVE, LOAD, AUTOSAVE, AND PLAYER IDENTITY
===============================================================================

25.1 Save model

UUFTSaveGameSubsystem owns world and player persistence. Save format version 9
stores a logical save summary plus validated payload generations. A summary
contains logical SlotId, display name, map identity/display name, world soft
reference, save time, play time, rules, version, loadability/error state, and an
optional PNG thumbnail.

The system captures one coherent live-world epoch on the game thread. Immutable
record assembly and disk writing may continue asynchronously/time-sliced. Factory
mutations are coordinated with the capture so actors, inventories, belts, and
players do not represent different moments.

Default hard safety limits include 10,000 actors and 100,000 components. Capture
timing thresholds default to 100 ms total and 5 ms per participant. Timing
overages are diagnostic by default: Abort Save On Capture Time Budget Exceeded
is false. A valid save may therefore complete despite a slow capture warning.
Enable that strict option only if exceeding a timing threshold should cancel
the save. Hard validity, size, serialization, and integrity failures still reject
a save and preserve the previous valid generation.

The live-world capture is synchronous; enabling time-sliced assembly (2 ms per
frame by default) does not turn arbitrary actor serialization into background
work. Profile large SaveGame properties and Before Save hooks when diagnosing
hitches rather than assuming all save work is asynchronous.

Manual saves may create a new thumbnail. Autosave and exit-save can reuse the
previous preview to avoid a ReadPixels/PNG hitch.

25.2 Logical save versus files on disk

One load-menu entry can legitimately correspond to several physical .sav files:
the current validated payload, a previous recovery generation, index/metadata,
and thumbnail data. This is not four player saves. Do not rename, delete, or send
only one internal file. To transfer a save outside a platform cloud system, copy
the complete SaveGames directory/set while the game/server is stopped.

Legacy UFT_-prefixed logical files are discovered/migrated for compatibility,
while current player-facing save names do not expose the framework prefix.

25.3 Blueprint API

Primary operations include:

- Create New Game.
- Save Current Game and Save Current Game Without Thumbnail.
- Get/Refresh Available Save Games.
- Request/load thumbnail on demand.
- Revalidate and Load a Save.
- Delete a Save.
- Get Active Save.
- Configure/query autosave.
- Is Save In Progress, Is Save Queued, and Is World Restore In Progress.
- Check whether the current world matches the active save map.

Listen to completion/failure delegates. Do not assume that clicking Save means a
write succeeded. Exit-save UI supports Retry, Leave Without Saving, and Cancel.

25.4 Save identity for custom actors

Add UUFTSaveIdentityComponent to actors that belong in world persistence:

- PersistentId: stable identity used to match records.
- Include In World Save: whether this actor participates.
- Runtime Spawned By Builder: marks framework-built runtime instances.
- Spawn If Missing On Load: allows recreation when no level actor exists.

Level-authored actors normally keep Spawn If Missing On Load false. A custom
runtime actor created outside the UFT builder should receive a stable ID and set
the runtime/spawn flags if it must return after a fresh map load.

Mark custom properties SaveGame. Implement IUFTSaveParticipantInterface when an
actor must prepare a compact snapshot in Before UFT Save or reconcile derived
state in After UFT Load. Keep Before Save fast, deterministic, and free of UI,
asset streaming, world travel, or long compression.

During BeginPlay, check Is World Restore In Progress before starting production,
playing completion audio, assigning random IDs, or overwriting restored values.

25.5 Player identity and multiplayer

Player inventory, equipment, quickbar/tool state, map exploration, and relevant
character state are keyed by a persistent identity:

- A portable standalone local-player slot is used for ordinary single player.
- A stable online identity is used when the provider supplies one.
- Projects using OSS Null or custom authentication can call Set Persistent Player
Identity before restore/possession finalization.

Display names are not stable account IDs. If a dedicated server assigns a new
identity on each connection, that player will appear to have an empty inventory
and map. Set the same authenticated ID on every reconnect.

Player inventory/equipment snapshots do not depend on a Blueprint component's
display name or position. Manual driving is saved with a stable vehicle identity
and is either reconstructed after both actors restore or converted to a safe
fallback character transform.

A disconnect can queue a shared-world checkpoint (enabled by default). The server
writes one coherent factory save containing all players; it does not need a
fragile independent world file per player.

===============================================================================
26. DEDICATED SERVERS
===============================================================================

Project Settings -> Plugins -> UFT Dedicated Server configures headless startup.
Principal settings are:

- Auto-start hosting.
- Gameplay map.
- Stable save slot (DedicatedServer by default).
- Create a save on first launch.
- Fail startup when a configured save cannot be loaded.
- Advertisement mode: Auto, Online, or LAN.
- Server name, maximum players (16 default), and advertise flag.
- Autosave enable and interval (300 seconds default).

Graceful-shutdown saving is configured on UFTSaveGameSubsystem, not on the
Dedicated Server settings object: Save Dedicated Server On Graceful Shutdown is
enabled by default, with Dedicated Shutdown Save Timeout Seconds set to 15.
A forced process kill cannot be relied on to finish a save.

Supported command-line overrides:

- -UFTNoAutoHost
- -UFTMap=/Game/Path/Map
- -UFTSaveSlot=LogicalSlotId
- -UFTServerName="Factory Name"
- -UFTMaxPlayers=16
- -UFTNoPower=0 or 1
- -UFTNoItemCosts=0 or 1
- -UFTHeadlessListenHost (installed-engine listen-server fallback)

A true dedicated build uses the project's Unreal Server target. An installed
engine without server binaries can use the headless listen fallback for testing,
but it is not identical to a cooked dedicated-server target. A -nullrhi
headless-listen package is still a game/listen build, not proof that a separate
Unreal Server target was built. Separately exported executable demos are not
automatically part of this source plugin's included content.

Runtime targets are Win64 and Linux; the Editor module is Win64-only. Existing
Linux validation includes headless runtime save/reload testing on AlmaLinux 9.8.
It does not establish Linux Editor support, a graphical Linux client, arbitrary
Linux distributions, or production player-capacity guarantees.

The server owns world saves and authoritative player state. Client save/load UI
should be hidden or disabled in a dedicated session. Headless execution must not
create Slate/UMG widgets, viewport captures, or cosmetic audio.

===============================================================================
27. WEATHER AND WORLD PRESENTATION
===============================================================================

AUFTWeatherSkyActor can own sun, moon, skylight, atmosphere, volumetric clouds,
fog, post process, wind, celestial bodies, weather particles, and ambient audio.

Presets include Clear, Partly Cloudy, Overcast, Storm, Foggy, and Custom. Time and
weather preset are replicated. Day/night and weather events allow game-specific
lights, materials, sound, or production rules.

Ambient sound layers support randomized selection so repeated weather cycles do
not always begin from entry zero. Effects Quality can scale optional particles
and presentation. Audio components are configured before registration rather
than changing Auto Activate after construction.

Weather visuals are client presentation. Replicate compact authoritative time and
preset state, not individual particle/audio components.

===============================================================================
28. MULTIPLAYER AUTHORITY AND REPLICATION RULES
===============================================================================

UFT follows a server-authoritative model:

- The server owns inventory, crafting, production, power, fluid transfer,
building, dismantling, vehicle schedules, station transfer, drone actions,
quests, projects, health-relevant actions, and saves.
- Owning clients predict visual placement and vehicle response where appropriate.
- Clients simulate cosmetic conveyor packet motion between authoritative
creation/removal/correction state.
- Remote transforms use smoothing; local controlled pawns avoid double movement
prediction on conveyors and vehicles.
- UI exists only for local players and receives replicated/read-only state.

Never expose a client widget that directly writes a replicated property. Use the
matching UFTFactoryPlayerComponent request node or create a validated server RPC
with ownership, range, target, permission, quantity, finite-number, cooldown, and
atomic-cost checks.

Join-in-progress clients receive current replicated factory state and registries.
Test late join after production, belts, vehicle routes, trains, drones, power
brownouts, active projects, and completed quests—not only in an empty map.

===============================================================================
29. WORLD PARTITION AND PERFORMANCE
===============================================================================

29.1 World Partition

Long-range logistics must remain resolvable across streamed cells. Active trucks,
locomotives, and flying drones expose/configure World Partition streaming-source
behavior. Saveable runtime actors retain persistent IDs so references can be
reconciled after streaming or load.

Do not assume an unloaded actor can be found with Get All Actors Of Class.
Framework registries and cached persistent state exist for resources, drones,
rail topology, and saving. Custom long-range systems should register lightweight
identity/state with a subsystem rather than depending only on TActorIterator.

29.2 Large factories

Practical scaling guidance:

- Keep conveyor visuals/materials shared and use visual profiles.
- Let clients interpolate packet movement from authoritative events/corrections.
- Keep power and rail topology dirty-driven.
- Use resource registries/spatial lookup for scans.
- Avoid per-widget or per-actor Get All Actors Of Class calls.
- Keep map capture event-driven/debounced.
- Use navigation-obstacle proxies rather than expensive per-poly collision.
- Use static collision shells for skeletal factory visuals.
- Tune World Partition streaming radius to speed and map cell size.
- Keep SaveGame data compact and profile Before Save hooks against the timing
thresholds. Overruns are warnings by default; strict timing cancellation is opt-in.
- Use actor relevance/cull settings appropriate to the visual scale, but do not
disable authoritative server simulation merely because no client can see it.

Closed conveyor loops, full station buffers, full drone destinations, insufficient
power, and incompatible fluids are gameplay backpressure. UI must distinguish
those states from a simulation bug.

===============================================================================
30. EXTENDING THE FRAMEWORK SAFELY
===============================================================================

30.1 Creating a new buildable machine

1. Create a child Blueprint of AUFTMachineActor.
2. Add art and a practical collision/navigation shell.
3. Add only the inventories/containers the machine needs.
4. Add item/fluid/power ports at physical connection points.
5. Bind storage and ports with component references.
6. Add UFT Moving Part and/or Factory FX components if required.
7. Create recipes and assign compatible machine types.
8. Create a Buildable Definition and add it to the Build Catalog.
9. Add a map marker/Codex entry if desired.
10. Validate, build, save/load, dismantle, and test as host and client.

30.2 Creating a custom storage/container

1. Derive from AUFTStorageActor for items or AUFTFluidStorageActor for fluid.
2. Add one or more inventory/container components.
3. Add ports and bind each storage role.
4. Decide which inventories refund on dismantle.
5. Set Buildable Definition, collision, marker, and Codex data.

30.3 Creating a custom vehicle/station

1. Derive from the general logistics vehicle or station actor.
2. Add a physical chassis/dock collision and buyer visuals.
3. Add cargo/fuel storage and bind it.
4. Add wheel/coupler/dock/port scene components as applicable.
5. Choose navigation, transfer, fuel, and power rules.
6. Use framework client request nodes in custom UI.
7. Test blocked paths, reverse recovery, full buffers, disconnect/reconnect,
save/load, and World Partition boundaries.

30.4 Custom gameplay logic

Use Blueprint events, delegates, policy classes, definition extensions, or an
actor component. Examples:

- On Power State Changed -> update emissive material/light.
- On Project Completed -> launch a rocket on the server.
- Vehicle wheel visual event -> drive a custom suspension rig.
- Quest custom event -> report an external puzzle or cinematic milestone.
- Factory FX state host -> play product-specific audio/particles.

Keep authoritative state separate from cosmetics. A sound, material, skeletal
animation, or payload crate must never be the only record that production,
inventory, or cargo exists.

===============================================================================
31. DATA VALIDATION AND RELEASE CHECKLIST
===============================================================================

UFT definitions and major configurable actors participate in Unreal's Data
Validation system. The runtime/editor source also contains a framework validation
library and automation coverage for economic quantities, construction,
logistics, save/load, rail, drones, and regression cases.

Use Unreal's Validate Assets action on your catalogs, definitions, and Blueprint
actors before packaging. An Error means the asset is unsafe or cannot perform its
declared role. A Warning identifies a likely usability/release issue that may be
intentional but should be reviewed.

Pre-release checklist:

- Every item, recipe, buildable, quest objective, project stage, station, and map
has a stable unique ID.
- Catalogs contain no duplicate IDs, null entries, or obsolete classes.
- Every buildable has an actor class, preview, valid cost, and placement mode.
- Every machine inventory/port binding resolves exactly one compatible component.
- Physical port transforms and cosmetic indicator transforms are correct.
- Collision blocks/interacts as intended and navigation obstacles are represented.
- Skeletal visuals use a physics asset or a static collision shell; avoid costly
per-poly skeletal collision.
- Recipes have valid positive quantities/timing and allowed machine types.
- Fuel items have positive energy and all accepted-fuel lists are intentional.
- Power generation exceeds expected demand or brownout is clearly communicated.
- Fluid types/capacity/head lift are tested through full branched networks.
- Conveyor, pipe, cable, rail, structure, drone, and vehicle placement each show
an accurate server-rejection reason.
- Stations expose correct buffer/mode/alignment/refuel information.
- Train timetables survive a real disk save and map reload.
- Drone cancellation and full-buffer recovery conserve cargo/fuel.
- Quest and project events do not replay completion audio after load.
- Custom runtime actors have Save Identity and correct spawn-on-load policy.
- A save/load test is performed during active production and manual driving.
- A disconnect/reconnect test uses the same persistent player identity.
- Host, remote client, late join, and dedicated server paths are tested.
- No custom UI/viewport/audio work executes on the dedicated server.
- World Partition tests cross several cells with every logistics type.
- Map capture/markers update after building and dismantling.
- Input focus returns to Game Only after closing the last modal menu.
- Asset references are tested in a clean buyer project, not only the development
host project.
- All paths remain comfortably below Fab limits and no redirectors/local build
folders are included in the release package.

===============================================================================
32. TROUBLESHOOTING
===============================================================================

Machine says "Waiting for input" although an item is visible

- Confirm the recipe accepts that exact UUFTItemDefinition.
- Confirm the item is in the inventory selected by the machine storage binding.
- Confirm the input port links to the same inventory.
- Check stack quantity, recipe machine type, and committed output blockage.
- Refresh the machine configuration if bindings were changed at runtime.

Machine event says effective power is true but UI says no power after load

- Read effective power from the bound UFT power port/network state.
- Do not restore a stale Blueprint boolean over the replicated result.
- Defer BeginPlay UI/FX initialization while world restore is active, then perform
a silent state refresh.

Power cable will not snap to a visible machine

- Verify the actor has a UFT Power Port Component and it is enabled.
- Set the correct direction: Input/Output for item ports, or the appropriate
Input/Output/Bidirectional flow for fluid and power ports.
- Check Max Connections on both endpoints.
- Confirm the binding/tag resolves and the port is not hidden inside blocking
geometry for the intended trace policy.
- The indicator arrow may be moved outward, but the component itself remains the
real cable endpoint.

Conveyor preview is green but click does nothing

- Check maximum/minimum segment length and cost scaling.
- Check player/server build distance and latency tolerance.
- Confirm the target port is compatible and not already occupied.
- Check blocking biomass/geometry and server footprint validation.
- Read the placement failure message/log; do not assume a save is responsible.

Splitter connects output to output

- Set the physical item port directions correctly.
- Match every Item Port Binding role to its selected component.
- Remove duplicate arrows/tags and obsolete special output-port components.
- Validate the junction and ensure its input is aligned with incoming belt travel.

Items stop at the end of a belt

- Inspect the destination port direction/filter and linked inventory.
- Check recipe compatibility and destination capacity.
- A refused or full destination intentionally creates backpressure.
- After load, verify both endpoint identities and connection restoration.

Generator/Factory FX loop plays only during each recipe

- Use Loop While Powered for a constant electrical hum.
- Loop While Working follows active production by design.
- Verify the FX component's power-state port/host binding and attenuation radius.

Looping audio stops after leaving and returning to its radius

- Use a persistent loop entry with inline attenuation rather than destroying the
audio component on inaudibility.
- Verify concurrency/virtualization on the source SoundWave/SoundCue.
- Confirm the host remains in powered/working state when the listener returns.

Train timetable is visible but autopilot does not move after load

- Read the locomotive status text for missing station ID, invalid route, fuel,
signal, grade, or curve reason.
- Ensure stop identities resolved and the Train Station, not only a freight
platform, is enabled in the timetable.
- Verify track topology, connection gaps, geometry limits, and fuel/power policy.
- If stranded, recover to nearest track, fix the cause, then enable autopilot.

Freight platform does not load/refuel the train

- Confirm the locomotive/wagon aligns with the intended station/platform index.
- Confirm mode is Load or Load And Unload.
- Confirm Refuel Vehicles is enabled and the fuel definition is accepted.
- Check station power when required and fuel inventory binding/port.
- Use platform diagnostics to inspect candidate wagon, dwell, ownership, and
alignment rather than watching only the visible mesh.

Truck says NavMesh needs a station although one exists

- Add an enabled Truck Station to the vehicle timetable through authority-safe
nodes.
- Confirm station persistent ID, compatibility, vertical floor, and reachability.
- Confirm RecastNavMesh covers both vehicle and dock with a navigable connection.

Truck repeatedly pushes into a station or obstacle

- Verify the collision/navigation proxy represents the visible obstruction.
- Use Chaos autopilot recovery and sufficient reverse distance/steering.
- Ensure the dock point is reachable without intersecting the station visual.
- Increase traction/uphill force only after confirming the path is physically
driveable.

Drone descends but remains above the pad

- Check dock occupancy/queue and service power.
- Check destination buffer capacity and unload timeout.
- Confirm dock/takeoff bindings resolve their Blueprint scene components.
- Check newly built flight obstacles and the ignore tag policy.
- Use cancel/recover so cargo returns to recovery overflow rather than deleting it.

Quest project objective does not complete

- Choose Complete Project Stage for one StageId.
- Choose Complete Multi-Stage Project for the final project state.
- Set the target actor class/Project ID/Target ID required to disambiguate multiple
project actors.
- Ensure external Blueprint logic reports through the quest event subsystem.

Resource marker no longer appears on map

- Confirm the actor still owns an enabled UFT Map Marker Component.
- Confirm the current player has discovered/revealed it.
- Verify marker catalog/layer/filter and Map Manager registration.
- On a server, verify the reconnecting player received the same persistent ID.

One save appears as several .sav files

- This is normally the current payload, previous recovery generation, index, and
metadata/thumbnail—not duplicated load-menu saves.
- Manage the logical slot through UFT APIs and copy the complete SaveGames set.

Save reports a slow capture/participant or a timing-budget failure

- In the current defaults, timing overruns warn but do not cancel a valid save.
Check Abort Save On Capture Time Budget Exceeded if you see strict cancellation;
project overrides can retain different settings.
- A cancelled save preserves the previous valid generation. A warning alone
does not prove that saving failed; inspect the final save result.
- Identify the named slow actor/component/participant and profile its hook.
- Remove large derived arrays, textures, NavMesh data, or synchronous compression
from SaveGame/Before Save. Do not disable integrity checks to hide a data error.
- Change timing thresholds only after profiling.

Client reconnects with empty inventory/map

- Supply the same stable persistent player identity before restoration.
- Do not use display name, transient controller index, or a new random GUID as an
account key.
- Confirm the server loaded the same logical shared-world save.

Menu closes but camera moves only while holding a mouse button

- Close through the player component/menu stack.
- When the last modal closes, restore Game Only input mode, hide/release the
cursor, and reacquire viewport mouse capture.
- Check that no invisible blur/menu widget remains focusable.

===============================================================================
33. SHIPPED DEMONSTRATION CONTENT
===============================================================================

The demonstration includes examples of:

- First-person player/controller and game modes.
- Main menu, settings, HUD, inventory, build menu, scanner, Codex, minimap, world
map, quickbar, compass, prompts, and Blueprint-only custom layouts.
- Iron, copper, coal, limestone, concrete, biomass, wire, and cable items.
- Axe and chainsaw tools with recipes/fuel behavior.
- Crafting bench, miner, smelter, constructor, foundry, and assembler patterns.
- Structures and storage containers.
- Conveyors, lifts, mergers, splitters, smart/programmable routing.
- Fluid extraction, pipes, valves, pumps, junctions, and tanks.
- Power generator, cable, poles, and consumers.
- Truck, truck station, recorded route, and NavMesh autopilot.
- Railway track, Train Station, locomotive, freight cars, and item/fluid freight
platforms.
- Drone, Drone Port, and cosmetic cargo box.
- Resource/biomass nodes, scan catalog, map catalog, and weather.
- Four quest definitions and an orbital/rocket multi-stage project.
- Codex catalog/tutorial entries and linked screenshots.

Treat these assets as examples and test fixtures. You may replace visuals and
balance while retaining the component/binding contracts. Before release, migrate
project-specific copies into your own organized content area and verify no demo
map or asset reference is accidentally required by runtime framework code.

===============================================================================
34. QUICK REFERENCE: COMMON BLUEPRINT ACTIONS
===============================================================================

Player menus:

- Open/Close/Toggle Inventory.
- Open/Close/Toggle Builder.
- Open/Close/Toggle Scanner.
- Open/Close/Toggle Codex.
- Open/Close World Map.
- Open Factory Actor through interaction.

Building:

- Get Unlocked Buildables.
- Select Buildable For Placement.
- Confirm/Cancel Placement through the player input path.
- Enter/Exit Dismantle Mode.

Inventory/equipment:

- Get Stacks / Count Item.
- Player-component transfer/move/merge actions for client UI.
- Equip Tool, Unequip Tool, Use Equipped Tool.
- Quickbar assignment and selection nodes.

Machines/projects:

- Set Recipe.
- Set Production Enabled.
- Start/Stop Crafting Bench craft.
- Deliver Project Items/Fluids.
- Reset Project.
- Bind project stage/completion delegates.

Vehicles/rail/drones:

- Drive/Exit/Right Logistics Vehicle.
- Set throttle, steering, brake, and look input.
- Add/remove/reorder timetable stops through player-component request nodes.
- Start/Finish/Cancel Recorded Vehicle Route.
- Recover Rail Vehicle To Nearest Track.
- Set/Cycle Drone Port Destination.
- Cancel Drone And Recover Cargo.

Save/session:

- Create New Game.
- Save Current Game (with or without new thumbnail).
- Load/Delete/Revalidate logical save.
- Host/Find/Join LAN or online session.
- Join Direct Address.
- Leave Session.

===============================================================================
35. TERMINOLOGY
===============================================================================

Authoritative
The server-owned state that decides the real gameplay result.

Binding
A component reference or unique-tag mapping that tells a general actor which
buyer-added component performs a role.

Buildable Definition
Data Asset joining menu content, actor class, cost, preview, and placement rule.

Committed Craft Batch
Immutable paid recipe result retained until output space is available.

Component Tag
Unique fallback name used when a direct Blueprint component reference cannot
resolve. It is not the gameplay ItemTag system.

Effective Power
Final usable powered state after connections, supply, priority, partial supply,
and game-rule bypass.

Indicator Transform
Cosmetic placement arrow transform; never the physical connection point.

Logical Save
One player-facing save entry backed by current/previous validated payload files.

Persistent ID
Stable identity used to reconcile actors, stations, routes, projects, and
players across replication, streaming, and save/load.

Policy
Replaceable Blueprint/C++ decision object for product-specific behavior while
the framework retains authoritative state and fallback rules.

Port
Item, fluid, or power connection component with role, filters, capacity, and a
physical transform.

Recovery Overflow
Storage reserved to conserve cargo/items when the normal destination is full.

Runtime Spawned
Actor created during play rather than authored into the map. Save Identity must
know whether to recreate it after a fresh map load.

Working
Actively producing/moving/performing its operation. Distinct from merely having
effective power.

===============================================================================
36. SUPPORT INFORMATION
===============================================================================

This documentation url:
https://celestiadominance.com/universal-factory-tycoon-documentation

Support community:
https://discord.gg/9Zc4wbwqG9

End of document.