Binds this logic to its parent data model and builds the actions map from the parent's intrinsic and scripted action definitions, selecting a default action.
Reserved base data (unused by the base class).
Must provide options.parent, the data model this logic
is embedded in; the parent's actionDefs are used to build
actions.
Executable actions for this document, keyed by shortcode — context-menu entries, chat-card buttons, and lifecycle hooks. A script action shadows (wholly overrides) the intrinsic action of the same shortcode (see the constructor).
The owning SohlActor — the document itself when it is an actor,
otherwise its owning actor (for an item, combatant, or effect), or null.
The logic of the owning actor — the Foundry-free way to reach the actor
layer from any logic. For an actor's own logic this is itself; for an
item's logic it is the owning actor's logic; otherwise null.
Resolved through the SohlLogicData port, so logic code
can navigate to the actor (and iterate items via allLogics /
logicTypes / getItemLogic) without touching the Foundry document.
This logic's typed data — its *Data interface (e.g. SkillData), the same
persisted object as document.system. Prefer document.logic.data when
reading a document's fields from a macro, Script Action, or module: it is the
typed, API-documented surface (autocomplete and reference links resolve),
whereas document.system is typed as the internal DataModel.
Convenience accessor for parent.
The owning document's id.
The owning SohlItem.
The owning document's kind (its actor or item type id).
Localized display label combining the typeLabel and the document's name.
The owning document's name.
A SohlSpeaker for the owning actor/item (a blank speaker if neither resolves).
Localized type (and sub-type, when present) label for the owning document.
The owning document's UUID — the opaque identity token from the data port.
Delete the owning document, after confirming with the user.
The action context; unused.
Open the sheet for the owning document.
The action context; unused.
Compute derived values that depend on sibling items being initialized.
Called on every item after ALL items have completed initialize.
Safe to access: sibling items' initialized state (e.g., reading trait attribute values for a skill base formula).
Not safe to access: sibling items' evaluated state — another item's
evaluate() may not have run yet. Dependencies on evaluated state
belong in finalize.
Example: a Skill reads trait attribute values to compute its skill
base; a gear item resolves its containerId to find its parent container.
Execute an action by shortcode, using the provided context or creating a new one.
The shortcode of the action to execute.
Optionalcontext: sohl.entity.action.SohlActionContextThe action context to use, if any.
The result of the action execution, or undefined if the action was not found or could not be executed.
Resolve cross-item dependencies that require all items to have been evaluated.
Called on every item after ALL items have completed evaluate.
Safe to access: all sibling items' initialized and evaluated state.
Example: fate mastery level (which depends on an already-evaluated Aura trait); encumbrance totals summed across all evaluated gear.
The context-menu options — the actions currently available — for this logic's document.
The available context-menu entries.
Set up base state from persisted data: create ValueModifiers, set base values.
Called on every item before any item's evaluate runs.
Safe to access: own persisted data fields (this.data.*).
Not safe to access: sibling items on the same actor — they may not have initialized yet. Cross-item reads belong in evaluate.
Example: a Skill creates its MasteryLevelModifier
from persisted fields; it does not yet read trait attribute values.
Resume an opposed test on this (the target) token — the handler the
opposed-request card's Respond button addresses. Reads the prior
OpposedTestResult (already revived from the card's data-scope),
lets the defender pick the responding skill or attribute, and resolves the
contest.
The action context; scope.opposedTestResult is the live
prior opposed test (revived by the dispatch handler), and (when
skipDialog) scope.responderLogicUuid selects the responding item logic.
The evaluated OpposedTestResult, false if a side
cancelled, or null when it cannot be resumed.
Begin an opposed test from this (the source) token — the canonical
action the source skill/attribute item logic delegates into. Resolves the
source item logic from scope.logicUuid and runs its opposed test; the
target is taken from scope.targetToken or the user's current target.
The action context; scope.logicUuid names the source
skill/attribute item logic.
The resulting opposed test, or null when it cannot be started.
Intrinsic action performed after finalize lifecycle stage. This is intended for modules to hook into (or ActionItems to override) to perform additional logic after the main lifecycle stages have completed.
The action context for the post-finalize hook.
Serialize this logic to a plain reference.
A uuid-keyed reference to this logic.
A logic is a behavior wrapper over a live Foundry document; it is never
revived from its own JSON (its constructor needs that document). Wherever a
logic is persisted — a chat card, an action sohl.entity.action.SohlActionContext.scope
— it is re-resolved from its uuid (e.g. via fvttLogicFromUuidSync), not
rebuilt from a payload. So it serializes as a compact, resolvable reference
(name/kind are carried for display and debugging); the owning document
holds the actual persisted state.
StaticdefineDefine the token's intrinsic actions — the opposed-test start and resume, dispatched programmatically (start, from the source item logic) and from the opposed-request card's Respond button (resume).
The token intrinsic-action definitions.
Token-scoped logic. Opposed tests (skill-vs-skill, skill-vs-attribute, attribute-vs-attribute) are about tokens: the source side rolls from the source token (the actor derived from it) and the responder side is dispatched to the target token from the opposed-request chat card.
The structure parallels sohl.document.combatant.logic.SohlCombatantLogic's automated-combat actions: a canonical opposedTestStart action (which the skill/attribute item logics delegate into, passing their
logicUuid) and an opposedTestResume action (the card handler on the target token). The test mechanics themselves stay on sohl.entity.modifier.MasteryLevelModifier —opposedTestStart/opposedTestResumehere resolve the source/responder item logic and delegate to it, just as the combatant delegates tostartAutomatedAttackFromItem.