Skip to main content

Weapon Builds

A Weapon Build is FWeaponBuildData, a Blueprint-visible value structure. It combines a registered master ID and installed part records. It is not created through Miscellaneous → Data Asset.

Build Fields​

FieldMeaning
InstanceGuidIdentifier for this configuration instance
WeaponIDID resolved through a master database
PartsArray of FWeaponBuildPartData
bValidatedResult written by explicit validation
bUsableSet with bValidated by the current validation path

Each part record contains PartID, ParentPartID, InstalledSlotName and InstalledSlotTag. Save these values to preserve a configuration. Current ammo, durability and other gameplay state are not fields of this build structure.

Create and Edit a Working Build​

  1. Queue CreateBuildOp to create a working build with a new GUID.
  2. Queue CreateAddPartToBuildOp with ParentPartID = Root to set the master ID.
  3. Add attachments with their actual parent IDs, mesh sockets and slot tags.
  4. Wait for each relevant working-build update before requesting the next dependent action.
  5. Queue CreateValidateBuildOp and wait for OnBuildValidatedCallback.

The Net component owns one WorkingBuild. The current edit handlers operate on this structure; a BuildID parameter does not select an independent editable build from the subsystem registry.

For attachment records, use the master's WeaponID as the parent for direct children. Root is the special marker for assigning/removing the master, not the normal parent ID for attachments.

Validation Rules​

Explicit validation checks:

  • A loaded Weapon Master is available.
  • Each referenced part asset was loaded.
  • Each installed slot tag matches a currently available slot.
  • The installed tag matches the part's CompatibleSlot.
  • The combination of parent ID and socket name is not already occupied.
  • A socket provider exists and its tags pass the part's WeaponTagsFilter.
  • Granted and blocked capabilities do not conflict.
  • Every RequiredParts tag is present in the installed slot tags.

Available slots expand as parts are processed. Add providers before parts that depend on their slots. Slot compatibility uses hierarchical tag matching; required-part checks use exact tag membership.

On success, validation sets both flags, adds the build to the subsystem registry and broadcasts OnBuildValidatedCallback. Failures are logged with a reason and do not produce a successful-validation callback.

Editing does not reset existing validation flags. Failed validation does not remove an older registered snapshot under the same GUID. Only equip after successful validation of the current configuration.

The equip handler does not rerun these checks or gate on the flags. Always explicitly validate/register the build before equipping it. Do not treat client-provided flags as proof of server validation.

Import, Fetch and Delete​

  • CreateImportBuildOp loads the referenced assets and replaces the working build. Validate it afterwards; importing alone does not register the build.
  • CreateFetchBuildOp retrieves a registered build into the working build and returns its data through FetchBuildCallback.
  • CreateDeleteBuildOp clears the matching working build in the current implementation. It does not remove a previously registered build from the subsystem registry.
  • Removing the root master resets the entire working structure, including its GUID. Create/import a valid working build again before editing further.

Presets and Save Games​

Store preset FWeaponBuildData in your own Blueprint data, Data Table, custom asset or SaveGame. The plugin does not provide a separate build-asset class or automatic disk persistence.

Use independent instance GUIDs for independently editable weapons. Reuse the master and part assets while copying the configuration. Import and validate saved configurations before acquiring and equipping their runtime actors.

See Inventory & Weapon Storage for the restore workflow.