Outcome-shaped object { id, order, type, target, config }
(may be a plain in-memory object, not necessarily a live TriggerOutcomeModel)
Document providing dialog
context (effect list for the effect picker, parent actor for the resource
picker, documentName for applyDamage's context label, etc.)
Parent trigger object (used by applyDamage's "Available
Variables" panel and forwarded as userChoice's nested-editor context)
OptionalextraOpts: object = {}
{ allSwings, currentSwingIdx, currentTriggerIdx },
passed straight through to applyDamage's variable-table builder when configuring
an outcome that lives inside a swing (omit for trigger-level/stage-level outcomes)
The processed config object, or null if cancelled
Build and show the type-appropriate config dialog for a single outcome, returning the processed config object (or
nullif the dialog was cancelled). This is the shared "figure out which dialog this outcome type needs, show it, normalise the result" step used by every live document-write handler (onConfigureOutcome,onConfigureSwingOutcome,onConfigureStageOutcome) — and by anything that needs the same dialog without persisting straight to a document, notably theuserChoicenested outcome-list editor (config-dialogs.mjs), which operates on an in-memory copy until the outer dialog's own Save commits it.Registry-backed types (
pushDrawOverride,applyDamage,playAnimation,userChoice) delegate toconfigDialogFor. Everything else falls back to the generic_buildOutcomeConfigContentdialog (effect picker / item drop-zone / resource picker hooks wired the same way the live handlers already do).