Your First Weapon

This guide creates a minimal build and equips it on a character. Complete Project Settings and Character Integration first.

1. Enable Plugin Content

Open the Content Browser settings and enable Show Plugin Content. Use suitable existing assets as references and keep your own assets in the project content folder.

2. Prepare a Weapon Master

Use a concrete asset class derived from PDA_WeaponMaster; the C++ base is abstract. Configure:

• A unique WeaponID, for example Rifle_Master
• WeaponType, for example Range
• MeshType and the corresponding mesh
• A suitable Stats asset, for example PDA_WeaponStats_Range
• SubSlotSockets, WeaponTags and RequiredParts as needed

Register the master under its ID in a configured PDA_WeaponDatabase.

For a master-only build, RequiredParts must be empty. Otherwise, add all required parts before validation. See The Weapon Master.

3. Create the Working Build

Get the Weapon Subsystem from the Game Instance. Call CreateBuildOp with the requesting PlayerController. Connect the returned request, bSucceed and FailureReason to QueueWeaponOperation as Request, bCondition and Message.

Creation assigns a new InstanceGuid to the controller's working build. On the server, read the new value from OnWorkingBuildModified; on a client, use OnWorkingBuildCreated or OnWorkingBuildReplicated.

These are asynchronous/event-driven stages. Do not queue all subsequent operations immediately after a pure helper node.

4. Set the Master and Add Parts

Construct CreateAddPartToBuildOp with:

Input	Master assignment
RequestingController	The owning PlayerController
BuildID	Working build InstanceGuid
PartID	Registered master ID, such as Rifle_Master
ParentPartID	Root
SocketName	A non-empty name, for example Root
InstalledSlotTag	Not used for the master assignment

The helper requires a non-empty socket name even for this root assignment. The root branch sets WeaponID; it does not append a part record.

For attachments, use the actual parent master/part ID, a registered part ID, a real socket name and the corresponding slot tag. Add parent parts before children that depend on their slots. Wait for working-build changes before proceeding.

5. Validate the Build

Queue CreateValidateBuildOp using the working build GUID. Validation loads the master and parts, checks compatibility and required slots, sets bValidated and bUsable, and registers a successful build in the subsystem.

Bind OnBuildValidatedCallback before submitting the request. Continue with its build GUID. A successful request helper is not a successful build-validation result.

6. Acquire a Weapon Actor

Queue CreateAcquireOp with AllocationType = Internal and the matching WeaponType, for example Range.

Internal allocation spawns one of the built-in actors: WeaponActorMelee, WeaponActorRange or WeaponActorThrowable. External allocation instead calls I_WeaponController::AcquireWeaponExternal; your project supplies the actor.

Obtain the registered actor's ActorNetGuid. The controller's WeaponAcquiredCallback is called from the owning client's OnRep_Owner path when the GUID is already valid. Standalone and authority-side flows need their own actor/GUID handoff; the current internal spawn path does not return an actor or invoke an authority-side acquisition callback. See Implementation Limits.

7. Equip and Select the Weapon

Once both the validated build and acquired actor are available, queue CreateEquipOp with:

• RequestingController: the owning PlayerController
• Character: its Character
• WeaponGuid: the registered actor's GUID
• BuildID: the successfully validated and registered build GUID
• TargetSocket: a character socket, such as back_weapon

Equip assigns the actor to the character and initializes its runtime entries. It does not acquire an actor or rerun complete build validation.

Then queue CreateUseOp with the actor GUID and the active socket, such as hand_r_weapon. Use sets ActualUsedWeapon, which the attack/reload/firemode helpers use.

CreateBuildOp → working build created
CreateAddPartToBuildOp → master and parts assigned
CreateValidateBuildOp → OnBuildValidatedCallback
CreateAcquireOp → registered actor GUID available
CreateEquipOp → assigned and initialized actor
CreateUseOp → selected weapon

Each request is submitted through QueueWeaponOperation; arrows indicate completed stages, not just helper calls.

8. Test the Setup

Check the build-validation callback, registered actor, character assignment and visible mesh. Test Standalone, Listen Server and a remote client separately. If a stage fails, see Troubleshooting.

For the internal responsibilities and replication model, see Architecture.