Weapon Parts

Weapon Parts are the core of Cube Weapon's modular customization system.

Instead of creating a separate weapon for every possible variation, Cube Weapon allows you to assemble weapons from interchangeable parts.

This dramatically reduces duplicated data while giving players complete freedom to customize their weapons.

What is a Weapon Part?

A Weapon Part represents a single modular component that can be attached to a weapon.

Examples include:

• Barrels
• Magazines
• Stocks
• Scopes
• Muzzles
• Grips
• Lasers
• Flashlights

Each part is represented by its own Data Asset.

Why Weapon Parts?

Without modular parts, every weapon variation would require its own weapon asset.

For example:

M4

M4 Reflex Sight

M4 ACOG

M4 Suppressed

M4 Heavy Barrel

M4 Long Barrel

M4 CQB

...

Very quickly this becomes difficult to maintain.

With Cube Weapon, only a single Weapon Master is required.

Every variation is created by combining different Weapon Parts.

Creating a Weapon Part

To create a new Weapon Part:

• Open the Content Browser.
• Right-click inside your project.
• Select Miscellaneous → Data Asset.
• Choose PDA_WeaponPart as the asset class.
• Save the asset.

Example:

Content
└── Weapons
    └── Assault Rifle
        └── Parts
            ├── DA_Barrel_Long
            ├── DA_Barrel_Short
            ├── DA_Stock_Heavy
            └── DA_Scope_RedDot

Keeping all parts inside a dedicated Parts folder is recommended.

One Asset = One Part

Every Weapon Part should represent exactly one physical attachment.

Good examples:

✔ Long Barrel

✔ Short Barrel

✔ Suppressor

✔ Drum Magazine

✔ Reflex Sight

Avoid creating one asset that represents multiple components.

Reusing Weapon Parts

One of the biggest advantages of Cube Weapon is that Weapon Parts can be reused.

For example:

Long Barrel

        │

        ├── Assault Rifle
        ├── Battle Rifle
        └── Light Machine Gun

The same Weapon Part ID can be used in builds for multiple masters when its slot and provider-tag compatibility allow it.

This greatly reduces duplicated content across your project.

Combining Weapon Parts

A Weapon Build simply combines multiple Weapon Parts together.

Example:

Weapon Build

Weapon Master

M4

Parts

✓ Long Barrel

✓ Red Dot Sight

✓ Vertical Grip

✓ Suppressor

✓ Heavy Stock

Changing a single Weapon Part automatically creates a completely different weapon configuration.

Weapon Part Validation

Queue explicit build validation after editing the build. Separately, PDA_WeaponPart provides editor asset validation for its configuration.

For example:

• Is the part compatible with the selected Weapon Master?
• Does the referenced asset exist?
• Is every required reference assigned?
• Are duplicate or invalid configurations allowed?

Explicit validation reports invalid configurations. Equip does not rerun this validation, so the integration must validate/register the build before using it.

Organizing Weapon Parts

As your project grows, the number of Weapon Parts will increase significantly.

A recommended folder structure is:

Weapons
│
├── Assault Rifle
│   ├── Weapon Master
│   ├── Parts
│   │   ├── Barrel
│   │   ├── Magazine
│   │   ├── Scope
│   │   ├── Stock
│   │   └── Grip
│   │
│   ├── Meshes
│   └── Materials
│
└── Shotgun

A consistent folder structure makes large projects much easier to maintain.

Best Practices

Keep Parts Focused

Each Weapon Part should have a single purpose.

For example, a barrel should only describe the barrel itself.

Avoid combining multiple gameplay concepts into one asset.

Reuse Existing Parts

If multiple weapons use the same attachment, reuse the existing Weapon Part instead of creating duplicates.

This keeps balancing and maintenance much simpler.

Name Assets Clearly

Good naming examples:

DA_Barrel_Long

DA_Magazine_30Rnd

DA_Stock_Tactical

DA_Scope_RedDot

Consistent naming becomes increasingly important as your weapon library grows.

Common Mistakes

Creating duplicate Weapon Parts

Avoid creating multiple copies of identical parts.

If two weapons use the same attachment, they should usually reference the same Weapon Part.

Putting weapon data into Weapon Parts

Weapon Parts should only describe the attachment itself.

General weapon information belongs in the Weapon Master.

Creating separate Weapon Masters for every variation

Remember:

Weapon Masters define weapon platforms.

Weapon Parts define customization.

Keep these responsibilities separated.

Summary

Weapon Parts are the modular building blocks of every weapon.

Instead of creating hundreds of individual weapons, Cube Weapon allows you to build unlimited weapon variations by combining reusable Weapon Parts.

This approach reduces duplicated data, simplifies balancing and makes large weapon libraries much easier to maintain.

What's Next?

Now that you understand how individual Weapon Parts work, it's time to combine them into complete weapons.

The next chapter introduces Weapon Builds, where Weapon Masters and Weapon Parts come together to create fully configurable modular weapons.

Part Configuration

Field	Purpose
PartID	Unique registered part ID
CompatibleSlot	Slot tag family accepted by this part
WeaponTagsFilter	Required/blocked tags evaluated against the resolved socket provider
MeshType / mesh	Visual representation
SubSlotSockets	Child slots supplied by the part
PartTags	Tags contributed by the installed part
GrantedCapabilities / BlockedCapabilities	Build capability grants and conflicts
StatModifiers	Hard references to modifier assets
SideEffects	Soft references to side-effect assets

Add the part to a configured PDA_WeaponPartsDatabase under its PartID. The build stores the ID, actual parent ID, socket name and installed slot tag rather than the asset pointer.

The part's BakeMeshSockets editor action uses the deepest registered Cube_Weapon.Slot... tag derived from a Slot_... socket name. Unlike the master's bake action, it can fall back to a registered parent tag. Both actions clear their previous socket maps.

Editor asset validation checks slot validity, mesh configuration, non-empty socket entries, filter overlap, modifier entries and capability overlap. Runtime build validation is a separate operation; complete both when preparing content.