Quick Start

By the end of this page, a server-side broadcast makes a floating combat text appear over a target actor on every client - styled by your registry and recycled through the widget pool.

Prerequisites
A GameState subclass you can edit (Blueprint or C++), a server-authoritative place to report damage/heals from (e.g. a GAS AttributeSet or your damage pipeline), and a gameplay tag to describe the event (the plugin ships Damage and its children, e.g. Damage.Type.Fire).
Ships ready to run
CrimsonCombatText includes demo content - a registry (DA_CrimsonCombatTextStyles), a pop widget (WBP_CrimsonCombatText), and a distance curve - and DefaultCrimsonCombatText.ini already points Project Settings at them. So a fresh install pops numbers as soon as you wire the GameState component and broadcast (steps 5-6). Steps 2-4 show how to author and assign your own assets - skip them to try the shipped defaults first.

Authoring your own registry? Its editor's Add Examples button fills it with a worked set of styles, modifiers and advanced rules using tags the plugin ships, so you can read one instead of inventing one - see How-To: Author Styles in the Registry Editor.

1. Enable the plugin

Open Edit -> Plugins, type Crimson in the search box, tick CrimsonCombatText's checkbox, and restart the editor when prompted. For a Blueprint project that's the entire install - you never hand-edit the .uproject or any .Build.cs.

Verify
CrimsonCombatText shows as enabled in the Plugins window and the editor restarts without errors.

2. Create the motion set and style registry

Two data assets. Content Browser right-click > Crimson > Combat Text:

  1. Motion Set - name it DA_CrimsonCombatTextMotions. It arrives pre-seeded with ten editable built-in presets, so it is usable immediately.
  2. Style Registry - name it DA_CrimsonCombatTextStyles. Set its MotionSet to the asset above.
Use these names and setup is zero-config
Matching those two names means the shipped ini already points at them - no settings changes needed.
Reference implementation
Open the shipped DA_CrimsonCombatTextStyles (/CrimsonCombatText/) - study its Styles map (one row per tag, each with a MotionPreset), its Modifiers map, and its MotionSet pointing at DA_CrimsonCombatTextMotions in the same folder. Duplicate the pair as your starting point.

Plugin content is hidden in the Content Browser until you tick Settings -> Show Plugin Content.

In the registry, add a row to `Styles` keyed by the tag your gameplay code will send - Damage is the obvious first one. Set its MotionPreset to CrimsonCombatText.Motion.ArcOut and leave everything else at default.

One row covers a whole tag branch
Styles resolves hierarchically: a hit tagged Damage.Fire.Burn falls back to Damage.Fire, then Damage, then DefaultStyle. You only author the specificity you care about - one Damage row already covers every damage type.
Use Modifiers, not more style rows
For conditions that cut across types - Crit, Blocked, Absorbed - add a `Modifiers` row instead of more style rows. One Crit modifier layers onto whichever style matched, so you never need Damage.Fire.Crit and Damage.Ice.Crit as separate entries.
Verify
Both assets save without errors. The registry's MotionSet field resolves to your motion set (not None), and the Styles map lists your Damage row with MotionPreset = CrimsonCombatText.Motion.ArcOut.

3. Create the combat text widget

Content Browser right-click > Crimson > Combat Text > Combat Text Widget, named WBP_CrimsonCombatText. Add a Rich Text Block and name it TextBlock to get formatted text for free.

The widget's base class recognizes two child widgets by name. Name them exactly as written or the bind does not happen:

Widget namePalette typeWhat the plugin does with it
TextBlockRich Text BlockReceives the formatted text every time the widget is taken from the pool
TextBorderBorderNever touched by the system - a styling hook you drive yourself
Reference implementation
Open the shipped WBP_CrimsonCombatText (/CrimsonCombatText/) - its hierarchy is exactly the table above: a Border named TextBorder wrapping a Rich Text Block named TextBlock, with a Text Style Set assigned on the rich text. Duplicate it as your starting point.
Both widget binds are optional
Both TextBlock and TextBorder binds are optional. Bind nothing and implement the On Combat Text Applied event instead if you would rather drive your own visuals.
Without a style set, text renders unstyled
Set a rich text Text Style Set on the Rich Text Block, and make sure it has rows matching your style's ValueStyleTag / PrefixStyleTag (Default out of the box). Without them the text renders unstyled.
Verify
The widget compiles and saves. Select the Rich Text Block: its name in the Hierarchy panel reads TextBlock exactly (no trailing digit from a duplicate), and its Text Style Set resolves to a Data Table.

4. Point Project Settings at your assets

Open Project Settings -> Crimson -> Crimson Combat Text. If you used the asset names above these are already correct; otherwise set them:

SettingValue
RegistryPathYour style registry (step 2)
WidgetClassPathYour widget Blueprint (step 3)
RendererClassLeave as the widget renderer
NumberFormatCommaSeparated, Abbreviated or Raw
Project Settings > Crimson > Crimson Combat Text.
Verify
RegistryPath and WidgetClassPath both resolve to real assets (neither reads None), and the values are written to your project's Config/DefaultCrimsonCombatText.ini under [/Script/CrimsonCombatText.CrimsonCombatTextSettings].

5. Add the replication component to your GameState

UCrimsonCombatTextReplicationComponent is the broadcast entry point. It must live on the GameState (replicated, exists on every client) - it registers itself with each client's subsystem on BeginPlay, so there is no manual wiring.

Open your GameState Blueprint. In the Components panel click + Add, type combat text, and pick Crimson Combat Text Replication Component. There is no graph work - the component finds the local subsystem itself on BeginPlay.

If your project has no GameState Blueprint yet: Content Browser -> right-click -> Blueprint Class -> Game State Base, then set it as Game State Class on your GameMode Blueprint.

GameState, not GameMode
The GameMode exists only on the server, so a component placed there never reaches clients. The GameState is the canonical home.
Verify
The GameState lists the component in its component tree, and your project's GameMode uses that GameState class.

6. Broadcast a pop from the server

Wherever damage or healing is applied on the server, build a FCrimsonCombatTextEvent and call Broadcast Combat Text. Set Target (the hit actor - the server resolves the pop's world location from it) and Tags (matched against your registry rules and the per-player filters). Instigator, PrefixText, and CustomText are optional.

In whatever Blueprint applies damage or healing, on the branch that runs on the server: Has Authority (Branch, True) -> Get Game State -> Get Component by Class (Component Class = Crimson Combat Text Replication Component) -> Broadcast Combat Text.

Feed the Broadcast Combat Text node's Event pin from a Make CrimsonCombatTextEvent node (drag off the pin and search Make CrimsonCombatTextEvent): Value = the amount, Target = the hit actor, Tags = the tag your registry row is keyed by in step 2 (Damage), Instigator = whoever dealt it. Leave PrefixText, CustomText and World Location alone - the server resolves the location from Target.

Authority is checked for you
BroadcastCombatText validates HasAuthority() and ignores (with a warning) calls made on a client - safe to call from code that runs on both sides. In singleplayer and on listen servers the local player is also a client of the multicast, so this same path works everywhere.
Verify
Press Play (try Net Mode = Play As Client with 2 players): dealing damage shows a styled floating number over the target on every client, rising and fading per your registry's physics.
What's next
Give players display control (How-To: Filter Which Pops a Player Sees), place pops on a socket (How-To: Position Pops), replace the built-in motion with your own animation (How-To: Play a Custom Widget Animation), and save bandwidth in big worlds (How-To: Cull Pops on the Server).
Pops appear over the target by default (optional reading)
You do not need to configure placement to finish this Quick Start - with none authored, every pop anchors over its target actor.

When you want text somewhere else - under the enemy for healing, in a fixed HUD area, next to a health bar - see How-To: Position Pops and How-To: Show Pops on the HUD or a Health Bar.