Weapon Subsystem
UWeaponSubsystem derives from UGameInstanceSubsystem. It creates the data manager and runtime builder, tracks registered components/actors/builds, and routes requests. Its lifetime belongs to the Game Instance; do not create a separate instance for each weapon.
Source: Public/WeaponSubsystem.h, Private/WeaponSubsystem.cpp, Private/WeaponSubsystem_Routing.cpp and the registry/helper implementation files.
Blueprint Access
Get the Weapon Subsystem from the Game Instance and call its functions under Weapon Subsystem|Subsystem.
| Function | Inputs | Output and purpose |
|---|---|---|
QueueWeaponOperation | bool bCondition, FString Message, FWeaponOpRequest Request | void; submits a request |
GetWeaponRefByGuid | FGuid ActorID | Actor pointer plus bool& bValid |
GetWeaponGuidByActorRef | AWeaponActorBase* ActorRef | GUID plus bool& bValid |
GetNetCompForController | AController* Controller | Net component plus bool& bValid |
GetCharCompForCharacter | APawn* Character | Char component plus bool& bValid |
DumpWeaponDBLookup | None | Logs database-type routing |
DumpWeaponLookupTables | None | Logs lookup/cache contents |
DumpBuildData | const FWeaponBuildData& Build | Logs build identity, flags and parts |
Check bValid before using returned references. A valid GUID format is not proof that a registry contains its object.
Submission
If bCondition is false, submission broadcasts OnScreenMessageTriggered(Message), logs the message and stops. Otherwise it resolves the requesting controller's registered Net component and switches on OperationType.
Build operations route to QueueBuildOperation; acquire routes to QueueAcquireOperation; Equip, Unequip, InitializeWeapon and Use route to QueueEquipOperation; Attack, Reload and TriggerFiremode route to QueueWeaponInteractOperation.
CreateBuild is special: its helper does not create a payload and the router does not require Request.IsValid() for that case. Other handled cases require a present instanced payload. Unsupported enum values log Unhandled operation type.
Submission is not a serialized task queue. Asset requests can finish later and dependent operations must be coordinated using build delegates and actor state.
Registries and Native Access
| Registry | Key and value |
|---|---|
RegisteredNetComps | Controller → weak Net component |
RegisteredCharComps | Pawn → weak Char component |
RegisteredWeaponComps | Actor GUID → weak gameplay component |
BuildRegistry | Build GUID → FWeaponBuildData copy |
WeaponRegistry | Actor GUID → weak actor |
WeaponRegistryRecursive | Weak actor → actor GUID |
AddWeaponBuild replaces a record with the same build GUID. RemoveWeaponBuild removes it; GetWeaponBuild returns an empty structure when missing. These methods, GetDataManager and GetRuntimeBuilder are native APIs without BlueprintCallable declarations.
Registries are local to each Game Instance and cleared during initialization/deinitialization. They are not replicated SaveGame storage. Successful validation registers a build on authority; the fetch client callback also registers the received build locally.
Declared Delegates
The subsystem exposes OnUpdateTickDelegate, OnExternalRemoveItems, OnExternalRemoveCallback, OnExternalAddItems, OnExternalAddCallback and OnScreenMessageTriggered. The presence of the inventory/update delegates does not provide a completed inventory transaction or recurring update system. Bind your gameplay workflow to the events actually emitted by its path; see Replication and Events.