Architecture

Cube Weapon separates asset definitions, build records, network routing and actor-local runtime state. There is no separate Weapon Build Data Asset class in the implementation.

Definitions and Builds

Type	Responsibility
UPDA_WeaponMaster	Abstract primary asset base for master identity, meshes, stats, tags and slots
UPDA_WeaponPart	Primary asset for attachment identity, compatibility, mesh, capabilities and modifiers
FWeaponBuildData	Value structure containing InstanceGuid, WeaponID, Parts, bValidated and bUsable
FWeaponBuildPartData	Part ID, parent ID, installed socket name and slot tag
UWeaponDataManager	Database lookup, asynchronous loading and asset caches
UWeaponRuntimeBuilder	Build validation, runtime component assignment, attachments and statistics

Builds reference asset IDs rather than direct asset pointers. The configured databases resolve those IDs to assets.

Subsystem and Components

UWeaponSubsystem is a Game Instance subsystem. Its registries associate controllers with UAC_WeaponNetComp, characters with UAC_WeaponCharComp, weapon GUIDs with actors, and build GUIDs with FWeaponBuildData.

• The Net component belongs on a PlayerController. It stores a working build, routes server RPCs and publishes build delegates.
• The Char component belongs on an ACharacter. It stores replicated assignments and the active weapon GUID, resolves actor references and handles attachment/animation transitions.
• The Gameplay component is created by AWeaponActorBase. It handles weapon state and the implemented interactions.

The public operation signatures accept controller/pawn base types, but component registration and attachment currently cast to APlayerController and ACharacter. A generic controller or plain pawn is not interchangeable with those supported owner classes.

Build Pipeline

Create or import WorkingBuild
    → Resolve master and part IDs
    → ValidateBuild
    → Set validation flags
    → Register build by InstanceGuid
    → OnBuildValidatedCallback

Import loads assets and replaces the working build; it does not validate or register it automatically. Build modifications affect the single working build on the Net component. Validate again after mutations before using that configuration.

Runtime Pipeline

Acquire registered actor
    → Equip with registered BuildID
    → Add master/part runtime entries
    → Resolve assets and assign mesh components
    → Resolve part attachments
    → BuildComplete and runtime statistics

Equip and acquire are independent operations. Runtime data is assembled on an actor that already exists. Unequip clears its runtime entries and removes its character assignment, then calls the controller's allocation-aware cleanup callback.

Replication

AWeaponActorBase is replicated. It replicates ActorNetGuid, BuildID, WeaponRuntimeData and RuntimeStats. Runtime entries use FWeaponDataArray, a Fast Array serializer, with client-side callbacks that rebuild visual components.

UAC_WeaponCharComp replicates AssignedWeaponActors and ActualUsedWeapon. UAC_WeaponNetComp replicates WorkingBuild. Build validation/fetch results also use client RPCs.

Clients rebuild meshes on replicated weapon actors. They do not independently spawn one actor per received build. A subsystem registry is local to its Game Instance; it is not itself a replicated object.

Loading and Statistics

Configured databases load asynchronously during initialization. Master and part assets are loaded on demand and cached. Mesh and stats fields on those assets include hard references, so loading an asset can also load those dependencies.

The runtime builder starts from Master->Stats, collects part modifiers, evaluates their tag filters, applies supported modifiers and normalizes the result. The calculated RuntimeStats are distinct from mutable gameplay state such as current ammunition.

For concrete signatures and data fields, continue with API Reference. See Implementation Limits for gaps in the current pipeline.