How-To: Get the Building Blocks

Goal: obtain every object the other pages assume you already have.

The hit detection component

Get Component By Class with Crimson Hit Detection Component, or the Find Hit Detection Component static node with an actor pin (Actor defaults to self).

The project settings

Project Settings -> Crimson -> Crimson Hit Detection. These are fallbacks and safety limits only; anything describing a specific attack belongs on a UCrimsonHitProfile.

Get Default Object with class Crimson Hit Detection Settings, then read its properties. In practice you rarely need this at runtime - the plugin reads it for you.

The shipped gameplay tags

The plugin ships example tags under CrimsonHitDetection.Zone.*, CrimsonHitDetection.Context.* and CrimsonHitDetection.Impact.*. They are examples: every tag property in the plugin is an unrestricted FGameplayTag, so your own project tags work just as well.

Where these come from
They live in the plugin's Config/Tags/CrimsonHitDetectionTags.ini and are registered by the module at startup. Plugin tag folders are not scanned automatically by the engine.

Collision profiles

Two optional profiles ship in the plugin's Config/DefaultEngine.ini: CrimsonHitbox for dedicated hurtbox geometry and CrimsonWeaponSweep for a weapon's own collision. Neither is required - the default queries use object types and find a stock Pawn with no setup.

Why no custom trace channels
Trace and object channels are allocated by index. Two plugins each appending a channel definition land on the same index and corrupt the host project's collision setup, so this plugin ships name-keyed profiles only.

See also

  • Quick Start
  • Concept: Windows, Shapes and Filters
  • API Reference