How-To: Author an Equipment Definition

Goal: one Blueprint class per piece of gear, declaring which slot it fills, what it grants, what it attaches, and which runtime class carries its logic.

Prerequisites
Quick Start steps 1 to 4, and slot tags of your own.

1. Create the class

Right-click in the Content Browser -> Add -> Crimson Plugins -> Equipment -> Equipment Definition. That creates a Blueprint child of UCrimsonEquipmentDefinition.

A definition is a class, not an asset instance
UCrimsonEquipmentDefinition is Const and Abstract. The plugin only ever reads its class default object through GetDefault, and never creates one. Everywhere you pass equipment around you are passing a TSubclassOf - which is why Equip Item's first pin is a class, not an object reference.
Verify
The new asset opens on the Class Defaults panel with four properties under Equipment.

2. Fill in the four properties

PropertyTypeWhat it does
Equipment Slot TagFGameplayTagWhich slot this fills. Must match a Slot Tag in the pawn's layout or the equip is rejected with an error.
Instance TypeTSubclassOf<UCrimsonEquipmentInstance>The runtime object created on equip. Defaults to UCrimsonEquipmentInstance; point it at your own subclass for per-item logic.
Granted AbilitiesTArray<FCrimsonEquipmentAbilityGrant> (+ GrantedEffects, GrantedAttributeSets)Abilities (and effects, attribute sets) granted to the pawn's ASC while this is equipped, and revoked on unequip. AbilitySetsToGrant is honored only with CrimsonCore.
Actors To SpawnTArray<FCrimsonEquipmentActorToSpawn>Meshes and actors attached to the pawn while this is equipped.

All four are EditDefaultsOnly, so authoring is entirely the Class Defaults panel - there is no graph. Set the slot tag first: it is the one value that will reject the equip outright if it is wrong.

Verify
Equip the definition. LogCrimsonEquipment with verbose logging on reports the resolved slot tag and index; a tag that is not in the layout logs an error and Equip Item returns null.

3. Decide what each piece of gear needs

Most definitions need only a slot tag and one actor entry. Add the rest when the gear earns it:

The gear needs...Set
To be visibleOne Actors To Spawn entry with a mesh and a socket. See How-To: Attach Visual Actors.
To bring abilitiesGranted Abilities (and Granted Effects, Granted Attribute Sets). See How-To: Grant Abilities from Equipment.
Per-item state or reactionsInstance Type pointing at your subclass. See How-To: Add Per-Item Logic.
Nothing but occupancy (a trinket that only exists to be worn)Just the slot tag. An entry with no actors and no grants is valid.
Verify
A definition with only Equipment Slot Tag set equips cleanly: Get Equipment Instance For Slot returns a valid instance and nothing is spawned or granted.

4. Reuse one definition across many items

A definition describes the gear, not the item. If your project has a hundred swords that all attach to hand_r and grant the same set, they can share one definition; what differs per item lives on the source object you pass to Equip Item.

Where per-item variation lives
Durability, rolled stats and a display name are properties of your item object, not of the definition. Pass that object as Source Object, read it back with Get Source Object on the instance, and the definition stays shared. How-To: Bridge an Item System is the full pattern.
Verify
Equip the same definition twice with two different source objects: Get Source Object on each instance returns the object that equip passed, and the two instances are distinct.

See also

  • How-To: Attach Visual Actors
  • How-To: Grant Abilities from Equipment
  • How-To: Add Per-Item Logic
  • Concept: Definitions, Instances and Entries