Zum Hauptinhalt springen

Inventory & Weapon Storage

Store weapon configuration as FWeaponBuildData. A weapon actor is a temporary world/network object, while a build records the master ID, installed parts and configuration GUID.

What to Save​

  • InstanceGuid and WeaponID
  • Part IDs, parent IDs, installed socket names and installed slot tags
  • Any additional project inventory metadata
  • Current ammo, durability or other gameplay state in a separate project record when needed

FWeaponBuildData does not contain ammo or durability. Saving only a build restores configuration, not all current gameplay state.

The subsystem's build registry is in-memory state and is cleared during initialization/deinitialization. The plugin does not write inventory or SaveGame files for you. Add the build structures to your project's persistence workflow.

Restore a Weapon​

  1. Load the saved build into your inventory.
  2. Queue CreateImportBuildOp for the requesting controller.
  3. Wait for the working build update after referenced assets load.
  4. Queue CreateValidateBuildOp and wait for OnBuildValidatedCallback.
  5. Acquire an actor of the matching weapon type and obtain its registered actor GUID.
  6. Queue CreateEquipOp using that actor GUID and the registered build GUID.
  7. Queue CreateUseOp if the weapon should become active.
  8. Restore additional gameplay state through your project's supported state handling.

Import does not validate/register automatically. Equip does not spawn an actor. These stages must be coordinated by the integration.

Fetching Build Data​

Use CreateFetchBuildOp and FetchBuildCallback to obtain registered data through the controller's network workflow. The current GetBuildData, AddOrUpdateBuildData and RemoveBuildData functions on AC_WeaponCharComp are stubs: they only check GUID validity. GetBuildData does not fill OutBuild. Use the fetch operation/callback rather than relying on these functions to read or change the registry.

Fetch also replaces the controller's WorkingBuild. Finish pending edits first and check the callback's InstanceGuid: an unknown registry key returns an empty build.

Unequip and Allocation​

The unequip handler clears runtime entries and removes the character assignment. It calls WeaponUnequipCallback rather than destroying the actor itself. Your project can destroy an internally allocated actor or return an externally allocated actor to a pool.

The routed Unequip handler runs without a target socket. Cleanup remains your callback's responsibility; see Implementation Limits. Clearing a build does not destroy the runtime actors that used it.

Shared Presets and Independent Weapons​

Reuse master and part assets. Copy preset build values into independently editable inventory instances with independent GUIDs. Two independent configurations with the same GUID overwrite the same registry key.

Multiplayer​

Actors are spawned/acquired on authority and replicated to clients. Clients reconstruct meshes on those replicated actors from runtime entries. They do not spawn independent actors just because an inventory contains a build.

An inventory system still needs its own authority, ownership and transfer rules. The weapon subsystem is not an inventory implementation.