Processor Variations

Every Processor in Power ships as a family of assets rather than a single one. A Reflector, for example, is not one asset — it is BSPostcontribution_Reflect_Int, ASPrecontribution_Reflect_Float, and about thirty others.

They all do the same job. What changes is where the Processor looks for its Relative Stat and what kind of Stat it expects to find there. The asset name tells you both.

Reading a Processor name

BS      Postcontribution   _Reflect   _Int    _Effector
▲       ▲                  ▲          ▲       ▲
subject stage              behaviour  value   variation

Each processor page lists the variations it actually ships with. This page explains the axes.

Subject — BS / AS / MAS

The prefix says whose Relative Stats the Processor reads.

Prefix	Subject	Reads relations from	Typical use
BS	Base Stat	The Effect's Target Stat	The rule belongs to the Stat being hit — Health knows what can block damage to it
AS	Attribute Stat	The Effect's single Attribute Stat	The rule belongs to the damage type — PhysicalAttack knows what resists it
MAS	Multi Attribute Stat	Every Attribute Stat on the Effect, in order	The Effect carries several Attribute Stats and each one should get a say — PhysicalAttack and FireAttack both check for resistance

MAS runs the same logic once per Attribute Stat, so an Effect tagged with three Attribute Stats can be reduced three times, once by each.

Not every Processor ships all three. A Processor that only makes sense against the Target Stat — Add, Set, HitRate in the Standard funnel — is BS only.

Value type

_Float and _Int pick which numerable Stat type the Processor operates on. Vector Processors carry _Vector2, _Vector3, _Vector2Int, _Vector3Int instead, and a few Processors are typeless because they never touch a value (Linker, Injector, ModifierRemover).

An _Int Processor must resolve an Int Stat, a _Float Processor a Float Stat. Mismatches are reported by asset validation.

Stat shape is not a variation

A Relative Stat can be split finely — per source Actor, per Effect Signature, or both — and the Processor that reads it does not change. Director, Intervener and Counter Effect, Immune, Modifier, Conditional Modifier, Limiter, Duration Modifier and Reflector Processors read whatever shape the Relative Stat has:

Stat shape	What it means
Plain Stat	One value, shared by every source and every Effect Signature
Source Separated Stat	A separate value per source Actor
Signature Separated list	A separate inner Stat per Effect Signature, run in order
Signature Separated list of Source Separated Stats	A separate value per Signature, per source Actor

Take a Reflector Stat with a value of 0.2:

• Plain — reflect 20% of everything, back at whoever hit you.
• Source Separated — each Actor that applied the reflect keeps its own share; one boss's curse reflects only that boss's hits.
• Signature Separated — each inner Reflector has its own Signature. Fire damage bounces back; physical damage does not.
• Both — reflect 20% of the fire damage that boss deals, and nothing else.

Turning a plain Stat into a list later (the Power Editor's Convert foldout on a Stat: Stat converts the Stat itself between Normal, SigSep, SrcSep and Signed; Relation converts the Stat a relation points to) never means swapping Processors, except for Signed, which needs the Signed Processors. A Processor that blocks — Immune, Director, an Intervener with BlockEffect — stops at the first inner Stat that blocks.

info

A few Processors read a plain Stat only: HitRate, ModifierCountLimit, ModifierReplacer, EffectAttributeEliminater, and every _Effector form. Their pages say so.

Effector variation

_Effector changes whose Repository is queried on the source side. Instead of reading the Stat from the source Actor, it reads it from the Effector's Actor.

This matters when the thing dealing the Effect is not the thing that owns the stats. A turret, a thrown weapon, a summoned totem, a projectile — the Effect's source is the Actor who built it, but the rules should come from the object doing the hitting.

_Effector variations only resolve the Applying side of a relation; there is no Effector-side "Receiving" key, because the Effector is never the target.

Signed variation

_Signed splits a Relative Stat in two: a Positive relation and a Negative relation. The Processor picks one based on the sign of the value it is handed, and contributes with that sign preserved.

Relative Stats are named <Mechanism>_<Side><Variation> — the mechanism (Modifier, ConditionalModifier, HitRate…), the side (Receiving on the target, Applying on the source) and an optional variation suffix (AS, Positive, Negative, Signed).

	Unsigned	Signed
Relative Stats	Modifier_Receiving, Modifier_Applying	Modifier_ReceivingPositive, Modifier_ApplyingPositive, Modifier_ReceivingNegative, Modifier_ApplyingNegative
Value of 0	Processed normally	Skipped
Behaviour	Same rule for damage and healing	Independent rules for damage and healing

Without it, a HealingReceived Modifier of +50% also amplifies incoming damage on the same Stat, because both are just "a change to Health". With _Signed, negative Health Effects route to one Modifier Stat and positive ones to another.

Signed variations exist only inside the Standard Processor funnel, plus the two Processors that operate directly on Modifiers — ModifierRemover and TimerModifier. Preprocessors and Postprocessors outside the funnel run before the sign of the final value is known.

A _Signed Processor reads Separated lists too: each inner Stat's own sign setting decides whether it applies.