Skip to main content

Blueprint Operations

UWeaponCommonFuncLib is a stateless UBlueprintFunctionLibrary. Its operation functions are BlueprintPure and return FWeaponOpRequest, with bool& bSucceed and FString& FailureReason outputs. They prepare requests; they do not spawn, equip or fire weapons.

Source: Public/System/WeaponCommonFuncLib.h, Private/System/WeaponCommonFuncLib.cpp and Private/Components/AC_WeaponNetComp_*.cpp.

Common Inputs and Outputs​

Every helper takes AController* RequestingController. Use the owning PlayerController with a registered AC_WeaponNetComp. The tables below list the additional inputs; all helpers also output bSucceed and FailureReason.

Request = Create...Op(RequestingController, inputs, bSucceed, FailureReason)
WeaponSubsystem.QueueWeaponOperation(bSucceed, FailureReason, Request)

The submission bCondition is the helper's bSucceed. The attack helper has a separate input also named bCondition, meaning trigger press/release. Releasing fire must submit a valid request with Payload.bState = false, not skip submission.

Build Helpers​

HelperAdditional inputsExecuted behavior
CreateBuildOpNoneReplaces WorkingBuild with a fresh GUID and empty configuration
CreateAddPartToBuildOpFGuid BuildID, FName PartID, FName ParentPartID, FName SocketName, FGameplayTag InstalledSlotTagLoads the asset; sets the master for Root, otherwise appends a part
CreateRemovePartFromBuildOpFGuid BuildID, FName PartID, FName ParentPartID, FName SocketNameRemoves the first matching part; Root clears the entire WorkingBuild
CreateValidateBuildOpFGuid BuildIDLoads/validates current WorkingBuild, updates flags and registers success
CreateDeleteBuildOpFGuid BuildIDClears WorkingBuild only when its GUID matches; does not delete the registry record
CreateImportBuildOpconst FWeaponBuildData& BuildLoads references and replaces WorkingBuild; no automatic validation
CreateFetchBuildOpFGuid BuildIDCopies registry data into WorkingBuild and sends the fetch client callback

Add/remove helpers check non-null controller, valid build GUID and non-empty part/parent/socket names. They do not perform full compatibility validation. The add helper does not reject an invalid InstalledSlotTag at construction; build validation checks the installed slot later.

For master assignment, pass the master ID as PartID, Root as ParentPartID, and a non-empty SocketName such as Root. The root branch sets WeaponID without adding a Parts record. For attachments use actual provider IDs and mesh socket names.

Add/remove/validate mutate the component's single WorkingBuild. Their BuildID is not a general selector for editing arbitrary registered builds. Finish pending asset loads before replacing that working value. Removing a parent does not recursively remove its children.

Import construction requires a valid Build.InstanceGuid and non-empty Build.WeaponID. It preserves supplied flags but does not establish that they reflect current validation. Always validate afterward.

Fetch on a missing registry key produces an empty build. Check the returned InstanceGuid, not just that a callback arrived.

Allocation and Equipment Helpers​

HelperAdditional inputsExecuted behavior
CreateAcquireOpEWeaponAllocationType AllocationType, ECustomWeaponType WeaponTypeInternal spawn or external allocation interface request
CreateEquipOpAPawn* Character, FGuid WeaponGuid, FGuid BuildID, FName TargetSocketAssign/attach actor and initialize registered build
CreateUnequipOpAPawn* Character, FGuid WeaponGuidClear runtime entries and assignment; call cleanup interface
CreateUseOpFGuid WeaponGuid, FName TargetSocketResolve controller's Pawn, select assigned weapon, change active socket

Acquire rejects None allocation/weapon types. Internal allocation picks AWeaponActorRange, AWeaponActorMelee or AWeaponActorThrowable; it does not consult a custom actor class on the master.

Equip construction checks non-null controller/Character, valid actor/build GUIDs and a non-empty socket. The runtime handler expects an already registered actor and build; it does not spawn or revalidate them. BuildRegistry.Find is dereferenced without a missing-key check.

Unequip reuses FEquipWeaponPayload without filling BuildID or TargetSocket. FEquipWeaponPayload::IsValid is not the router's check; the present route reaches the handler. Cleanup does not automatically destroy or detach the actor. The handler resets ActualUsedWeapon even when another weapon was active.

Use is selection/attachment. It does not mean fire or generic interaction. It resolves RequestingController->GetPawn() into its equip payload and targets an existing character assignment.

Interaction Helpers​

HelperAdditional inputsExecuted behavior
CreateWeaponAttackOpbool bConditionSends press/release state to ActualUsedWeapon
CreateReloadOpNoneRequests reload of ActualUsedWeapon
CreateTriggerFiremodeOpNoneRequests fire-mode change of ActualUsedWeapon

These helpers resolve the controlled Pawn's AC_WeaponCharComp and read ActualUsedWeapon; they do not accept an arbitrary weapon GUID. Select a weapon with Use first.

Range attack has an implementation, while Melee and Throwable attack branches are empty. Reload currently sets reload state and resets ammo to 100. Firemode toggles SemiAuto and FullAuto; it does not cycle every declared state.

Completion​

Use working-build delegates for create/edit/import, OnBuildValidatedCallback for validation success, FetchBuildCallback for received build data, and actor/Character state for equipment transitions. There is no ExecuteWeaponOperation node returning a universal FWeaponOpResult, and no CreateDropOp. See Replication and Events and Implementation Limits.