The Weapon Master

The Weapon Master is the foundation of every weapon in Cube Weapon.

Every weapon build starts with a Weapon Master. It defines the base identity of a weapon platform and contains all information that every instance of that weapon shares.

Without a Weapon Master, a weapon cannot exist.

What is a Weapon Master?

Think of the Weapon Master as the blueprint of a weapon family.

For example:

Weapon Master
M4 Platform

├── Compatible Barrels
├── Compatible Magazines
├── Compatible Stocks
├── Compatible Scopes
└── Default Weapon Settings

Every M4 that exists in your game originates from the same Weapon Master.

The individual builds only determine which parts are installed.

Responsibilities

A Weapon Master is responsible for describing the weapon itself.

Typical responsibilities include:

• Defining the weapon platform
• Selecting the weapon family through WeaponType (actor allocation is separate)
• Defining compatible weapon parts
• Providing default settings
• Referencing default assets
• Identifying the weapon throughout the framework

The Weapon Master is not responsible for storing runtime values such as ammunition, durability or currently equipped parts.

Installed parts belong to FWeaponBuildData; ammunition and durability belong to runtime/project state, not the build structure.

Creating a Weapon Master

To create a Weapon Master:

• Open the Content Browser.
• Right-click inside your project.
• Select Miscellaneous → Data Asset.
• Choose a concrete asset class derived from PDA_WeaponMaster; the native base is abstract.
• Save the asset inside your weapon folder.

Example:

Content
└── Weapons
    └── Assault Rifle
        └── DA_WM_AssaultRifle

Keeping one folder per weapon platform is highly recommended.

Weapon Identity

Every Weapon Master represents exactly one weapon platform.

For example:

Weapon Master

AK Platform

can produce:

• AK-47
• AKM
• AK-74
• Tactical AK
• Suppressed AK

These are all different Weapon Builds created from the same Weapon Master.

Relationship to Weapon Builds

A Weapon Build resolves one Weapon Master through its WeaponID and the configured database.

Weapon Build
        │
        ▼
Weapon Master

However, a single Weapon Master can be shared by any number of Weapon Builds.

This allows dozens of weapon variants without duplicating data.

Compatible Weapon Parts

One of the primary responsibilities of the Weapon Master is defining which weapon parts are compatible with the weapon.

For example:

Weapon Master

Supports

✔ Barrel

✔ Magazine

✔ Scope

✔ Stock

✔ Grip

Does NOT Support

✖ Cylinder

✖ Bow String

Explicit validation checks slot tags, socket providers, part filters, required slots and capability conflicts; the master does not contain a direct list of compatible part assets.

This prevents invalid weapon configurations.

Runtime Behavior

The Weapon Master itself is never modified during gameplay.

Explicit build validation reads these definitions. After a successful build is registered, equip initializes runtime entries and components on an already acquired actor.

The original Weapon Master remains unchanged and can safely be reused by any number of players.

Best Practices

One Weapon Platform per Master

Avoid creating a Weapon Master for every small variation.

Instead:

✔ One Weapon Master

M4 Platform

Many Weapon Builds

M4 CQB

M4 Sniper

M4 Support

M4 Heavy

This reduces duplicated data and keeps your project easier to maintain.

Keep the Weapon Master Generic

A Weapon Master should describe the platform—not a specific player loadout.

Avoid storing information that changes during gameplay.

Examples of data that should not belong in the Weapon Master:

• Current Ammo
• Durability
• Current Skin
• Equipped Attachments
• Player-specific Statistics

Those values belong elsewhere in the framework.

Organize Assets

A recommended folder structure is:

Weapons
│
├── Assault Rifle
│   ├── Weapon Master
│   ├── Parts
│   ├── Meshes
│   ├── Materials
│   └── Icons
│
├── Shotgun
│
└── Sniper Rifle

Keeping each weapon platform self-contained makes projects much easier to maintain as they grow.

Common Mistakes

Creating multiple Weapon Masters for cosmetic variations

This is unnecessary.

Create one Weapon Master and multiple Weapon Builds instead.

Storing gameplay state inside the Weapon Master

Weapon Masters are static assets.

Gameplay state belongs to runtime objects.

Duplicating identical data

If two weapons share the same platform, they should generally share the same Weapon Master.

Only create additional Weapon Masters when the weapon platform itself changes.

Summary

The Weapon Master is the foundation of every weapon in Cube Weapon.

It defines the weapon platform, determines which parts are supported and provides the data required to construct runtime weapons.

Every Weapon Build starts with a Weapon Master, making it one of the most important assets in the framework.

What's Next?

Now that you understand the Weapon Master, it's time to look at the second major building block of Cube Weapon:

Weapon Parts, which provide the modular customization system for every weapon.

Master Configuration

Field	Purpose
WeaponID	Unique ID used as the database key and build WeaponID
WeaponType	Weapon family: Melee, Range or Throwable
WeaponDetail	Additional weapon classification tag
MeshType	Static or skeletal visual representation
StaticMesh / SkeletalMesh	Mesh selected by MeshType
WeaponAnimInstance	Animation instance class for a skeletal weapon mesh
SubSlotSockets	Gameplay-tag-to-socket map for attachment providers
WeaponTags	Platform/provider tags used by compatibility and statistics
RequiredParts	Installed slot tags required by build validation
Stats	Base weapon statistics asset
WeaponFX / SideEffects	Referenced effect definitions

Register the master in PDA_WeaponDatabase and configure that database in Project Settings. The master has no actor-class property; internal allocation selects built-in actors from the requested weapon type.

Use the BakeMeshSockets editor action after configuring the mesh and registering the required slot tags. It rebuilds SubSlotSockets from Slot_... socket names and requires the complete derived tag to exist. Review the resulting map before saving.