How-To: Vary An Attack's Values

Goal: change the numbers a Targeting Preset queries with - radius, arc, range - per attack and per actor, without authoring an asset for every combination.

Every request gets its own copy

A UTargetingPreset holds its tasks as Instanced objects, which means the task objects belong to the asset. Load the preset once and every character, enemy and projectile referencing it would share those same task objects - one Crimson Selection: Socket Sweep in memory, not one per sword. Writing a radius onto that would resize the attack for the entire game.

So the plugin never uses the asset directly. Opening a window duplicates the preset, and the request runs against that private copy. Writing to it is safe by construction: the asset is untouched, and two actors attacking in the same frame cannot see each other's numbers.

The ways to change a value

Anatomy of a preset

Open a Targeting Preset and you get one array, Targeting Task Set, holding instanced tasks in execution order. Selection tasks contribute candidates; filters remove them; sorts order what is left.

1. Find the value you want to vary

A task property becomes a pin when it is marked ExposeOnTargeting. These ship exposed:

2. Exposing a value on your own task

Nothing to do if you are using the tasks above. To expose a property on a task you wrote, add the marker to its UPROPERTY:

UPROPERTY(EditAnywhere, Category = "Dimensions", meta = (ExposeOnTargeting, ClampMin = "0.1"))
float Radius = 300.f;

Every profile whose preset uses that task grows the pin. Any Blueprint-settable type works: floats, vectors, names, enums, structs, arrays.

3. Set the value on the node

BlueprintC++

Add Crimson Hit Window (or Crimson Hit Query) to your ability graph and set its Profile pin to a Hit Profile asset. The node immediately grows one pin per exposed value. Wire whatever computes the number - an ability level, a charge alpha, a stat lookup - straight into it.

The Profile pin must be a literal

Wiring a variable into Profile means the asset is unknown until the game runs, so there is nothing to build pins from. The node compiles with a warning and the attack uses the preset's authored values.

Which pins appear

The node only grows a pin for a value that is relevant to how the task is set up. A property the task's own Details panel would hide is hidden on the node too - the node reads the same EditCondition the panel does, so the two cannot drift apart.

Trace Type and Direction Mode are pins themselves, and they are read from the pin before the asset. Change Trace Type to Sphere on the node and a Swept Radius pin appears immediately, keeping every connection and value you had already set.

Shape Scale, for what pins cannot reach

Shape Scale multiplies every dimension of every Crimson shape, on top of whatever the pins resolved to. It covers the case a node pin structurally cannot: a persistent buff - a size potion, a growth mechanic - that has no idea which preset it is widening.

How values resolve

1. The window duplicates the profile's preset. The copy starts at the asset's authored values.
2. The node writes every pin you changed onto that copy. A pin still at its authored default writes nothing.
3. Shape Scale = the component's scale multiplied by the window's. Both default to 1, so either alone works and both together compound.
4. At query time each task uses its own value, then multiplies by Shape Scale if that value is a size.

4. Verify it

Console: Crimson.HitDetection.Debug 1. The queried shape draws in blue, so a size change is immediately visible.

What cannot be varied

Worked examples

A skill rank that sets radius

Three ranks, each with its own radius, from one profile and one preset. On Crimson Hit Query, wire a Select Float (indexed by the ability's rank) into the Radius pin. No tags, no component state - the value travels with the attack that uses it.

A charged attack that grows while held

Wire a Lerp from your charge alpha into the Radius pin - 300 at no charge, 700 at full. The charge finishes before the swing starts, so the value is known when the window opens, which is exactly when it is read.

A percentage area buff from gear

Shape Scale, not a pin. A percentage is inherently relative, so it should multiply whatever the base happens to be - including a base a rank pin already set. And the buff has no business knowing which preset it is widening. Recompute and set it whenever the equipment set changes.

// TotalAreaBonus is your own aggregate, e.g. 0.2 for +20%.
HitDetection->SetShapeScale(1.f + TotalAreaBonus);

Integrating a modifier or augment system

The integration is therefore always the same shape: resolve, then wire. Your system produces a final number; you plug it into the pin. Because it is an ordinary Blueprint connection, the source of every value is visible in the graph rather than implied by a tag matching somewhere off-screen.

Troubleshooting

See also

• How-To: Area Attacks and Hitscan
• Concept: Windows, Shapes and Filters
• API Reference