Build a defense result, folding any player-entered situational modifier
into the mastery level as a PLAYER delta.
Defense data; data.situationalModifier (the player-entered
defense modifier) is added to the masteryLevelModifier as a
PLAYER delta.
Result options; options.parent is required (base
TestResult).
The combatant logic for the defender.
The label for this defense result (shown on card).
OptionalmodeThe strike mode used for this defense (only if block or counterstrike).
Foundry roll mode (public / private GM / blind / self) used when posting to chat.
Context-menu responses available as follow-ups to this result — e.g. resuming an opposed test when this is the opening roll.
Whether a Fate Point may be spent on this test — true only when the owning
item has an eligible, charged Fate Mystery (availableFate) and the test
permits it. Fate is a post-roll success-level bump, never a re-roll: a
spend raises this result's stored successLevel (#854).
Whether criticals are possible — i.e. the modifier defines any critical success or failure digits.
Human-readable description shown on the result's chat card.
Whether the effective mastery level was constrained (capped) below its raw effective value.
Whether this result is a critical (success or failure). Always false when
critAllowed is false — except a forced auto-Critical-Failure
(#568), which is always critical.
Whether the test succeeded (success level at marginal success or better).
Whether this is a Success Value test (#848) — its roll is graded into a Success Value and Success Stars rather than a plain pass/fail. Drives the card's Success Value / Success Stars rows.
The item logic this test was rolled from (its skill/attribute/weapon).
The serialization discriminator for this instance — the concrete class's static Kind. Written into the JSON by toJSON under the kind key and read back by sohl.utils.defaultFromJSON to select the constructor. Derived from the class, never stored per-instance.
The ones digit of the roll total, tested against the modifier's critical digit lists.
The mastery-level modifier rolled against; its constrainedEffective value is the roll-under target for this test.
Set of mishap codes flagged for this result (e.g. fumble, stumble); lazily initialized.
Tactical movement state recorded for this test (stationary, etc.).
Internal identifier for this result (distinct from the display title).
Success level normalized to the canonical four-point scale (−1/0/1/2) from isSuccess and isCritical. Opposed and combat resolution compare two results by this value.
Success level before the four-point clamp — the stored level with every
successLevelMod folded in, so it can sit outside −1…2 (a Critical Failure
pushed down by −1 reads −2).
Opposed resolution compares this rather than successLevel because a contest's victory margin has no ceiling: each step between the two levels is one Victory Star, and a modifier that shifts a level widens the margin accordingly. Everything that asks "did it succeed, and how well?" wants the clamped successLevel / normSuccessLevel instead.
Longer result description for the chat card, derived on read from the description table (empty when no table is supplied). Never stored — see successStars.
Short result label for the chat card, derived on read from the description table (empty when no table is supplied). Never stored — see successStars.
The d100 SimpleRoll. May be pre-seeded before evaluate (e.g. for fate or a deterministic outcome).
Speaker identity (actor/token/user) used when posting this result to chat.
Success level clamped to the four-point scale: critical failure (−1),
marginal failure (0), marginal success (1), or critical success (2). The
raw internal level (which successLevelMod can push beyond this range) is
normalized here.
Number of success "stars" (quality grade), derived on read from the description table. Never stored (issue #205) — recomputed from the table plus the evaluated success level / target value / roll last-digit.
The test's target value — targetValueFunc(successLevel). For a plain
success test this is just the success level; success-value tests map it to
a quality/quantity outcome used to index the
description table.
Which kind of test this is — a TEST_TYPE id (e.g. success test, attack, block).
Title shown at the top of the result's chat card.
The token this test is associated with, if any.
Raise this result's stored success level by delta — the post-roll Fate
bump (#854). This mutates the already-settled outcome: it does not
re-roll and does not re-evaluate. Because the outcome text/stars are
derived on read (see resultText / successStars), re-posting
the card after a bump re-resolves the description table against the new
level automatically.
Fate is defined as successLevel += delta on the original result's stored
level; the successLevel getter re-clamps to the four-point scale on
read (e.g. a marginal failure bumped by +2 reads as a critical success).
Success levels to add (Fate contributes +1 or +2).
This result, for chaining.
Deep-copy this entity, re-parenting the copy under parent with no other
changes. Shorthand for clone({}, { parent }).
The Logic to own the cloned entity.
The cloned entity.
Deep-copy this entity, optionally overriding fields and clone options.
Field overrides applied to the clone.
Clone options (e.g. a new parent).
The cloned entity.
Re-open the standard test dialog on this already-settled result, pre-filled with its current situational and success-level modifiers, and fold the submitted values back into masteryLevelModifier.
How to collect the new modifiers; see SuccessTestResult.ModifierEditOptions.
{ changed } — whether either modifier actually moved — or
undefined when the dialog was dismissed, which cancels the edit.
This is the shared core of the GM result-edit: the single-test pencil (sohl.document.item.logic.SohlItemBaseLogic.resultEdit, #856) and the opposed-contest pencil (sohl.document.actor.logic.SohlActorBaseLogic.opposedResultEdit, #1082) both fold their sides through it. It never rolls — the die stays frozen and the caller re-evaluates on it.
A situational modifier of 0 removes the delta rather than recording a
zero, so an edited target is never left carrying a stale modifier.
Roll the defense (block or dodge) and apply defense-specific mishaps on top of SuccessTestResult.evaluate.
false if the base evaluation disallows the result; otherwise
true.
On a failed roll: for block, a critical failure flags a fumble (last digit 0) or stumble (last digit 5); for dodge, a critical failure flags a stumble. The resolved success level is then compared against the attack within the containing CombatResult.
Open the pre-roll dialog and fold its inputs into this result.
Extra template data merged into the dialog.
Invoked with the submitted form data once the dialog inputs have been applied.
The dialog render/submit result.
The dialog collects a situational modifier and a success-level modifier
(both applied to masteryLevelModifier), the rollMode, and
movement/mishap options. After the user submits, the supplied callback
is chained with the form data. This does not roll — call evaluate
afterward.
Render this result with the standard test chat card
(templates/chat/standard-test-card.hbs) and post it via the
speaker, attaching the Foundry roll and the dice sound.
Extra template data merged into the card. A buttons key
(ActionCardButton or ActionCardButton[]) becomes follow-up
action buttons on the card.
The derived display outcome (resultText, resultDesc, successStars)
is not carried by toJSON — it is folded into the card data here,
rendered once by the sender with a live targetValueFunc (issue #205).
An optional buttons entry in data (one ActionCardButton or an
array) is folded through toRenderableButtons — the same normalizer
the action-card framework uses — so the standard card can carry arbitrary
follow-up consent buttons (a graded test = successStarTable mapping +
buttons follow-ups), dispatched through the shared chat-card chokepoint
exactly like an action card. Nothing auto-fires (#853).
Serialize to a plain object satisfying DefendResult.Data: the inherited SuccessTestResult fields plus the combatant reference, defense strike-mode pointer, and label.
The plain-object representation.
The combatant is persisted by combatantUuid, and the defense strike mode
as its pointer data (rebuilt in the
constructor). situationalModifier is not emitted — it lives on the
serialized masteryLevelModifier as a PLAYER delta.
The defender's side of a combat exchange — a SuccessTestResult with defense-specific data.
Key properties
situationalModifier— player-entered modifier from the defense dialog.Evaluation
evaluate performs the defense roll (block, counterstrike, or dodge), determines success/failure, and checks for defense-specific mishaps (shield break, stumble, fumble). The defense success level is then compared against the AttackResult in the containing CombatResult to determine the final outcome.