Condition index

Find a native condition class, its wrapper, and the chapter explaining its fields. Test listener timing and save/load behavior when adapting a condition to your quest.

The condition inventory is Observed in vanilla. Use the named depot paths to inspect matching nodes in your own installation. For a worked example, start with Labs at a glance.

Choose the evaluation schedule first

The same predicate can sit beneath two different graph schedules:

An immediate Condition does not wait on its False route. A Pause Condition does not expose an ordinary False continuation in the focused shape. See Immediate branches and waiting gates.

Read the payload layers

Many condition families use two object layers:

Condition or Pause Condition node
└── condition                    domain wrapper
    └── type                     concrete predicate payload

For example:

questFactsDBCondition
└── questVarComparison_ConditionType

Other wrappers, including questTriggerCondition, carry decisive fields directly. Preserve the actual wrapper/payload pairing; replacing a wrapper while leaving an incompatible nested handle is not a type conversion.

Families reduced to practical property contracts

The focused authoring fields and validation steps are in Condition payloads. Community readiness adds the identity and activation-order requirements in Activation, readiness, and acquisition.

Fact comparators

The property guide exposes these native values. The count column keeps the retained corpus observation separate from enum availability:

The absence of LessOrEqual from this focused sample is not evidence that the enum cannot represent it.

Facts are signed integers. Equal 1 and Greater 0 are not interchangeable when another writer can store 2.

Trigger predicates

The retained trigger inventory contains:

These names are search keys, not proof of exact state-versus-edge behavior through activation, teleportation, streaming, or save/load. The exact Lab 3–5 resources use state-shaped IsInside / IsOutside forms with the player form of the activator fields; test the intended crossing and reload behavior in game.

Time payloads

The payload name does not settle pause-menu, time-skip, fast-travel, loading-screen, process-restart, or save-restoration policy. Those are separate runtime cases; see Delays, facts, and persistence boundaries.

Logical condition trees

questLogicalCondition combines child predicates inside one Condition or Pause Condition. It is not a graph-level join or race node.

The exact nested AND condition in Lab 2 is Structurally validated. There is no generic NOT wrapper in the retained corpus. Use a payload’s own negative form only when that payload owns one—for example NotEqual, IsOutside, or the journal-state payload’s inverted field. See Boolean condition trees.

Do not confuse the table with questLogicalAndNodeDefinition or questLogicalXorNodeDefinition. Those graph nodes combine execution signals and have sockets; questLogicalCondition combines predicate objects and has no listener sockets to cancel.

Object-condition families

The retained corpus contains 60 questObjectCondition wrappers. Their nested payloads account for all 60 definitions:

All four rows are Observed in vanilla inventory. The device row now has a bounded property/ownership procedure in Advanced devices and interactions, while a new custom-device lifecycle remains Experimental until its exact matrix passes. The other rows remain discovery entries rather than complete property recipes. The shared wrapper does not imply shared fields or runtime behavior.

Character, combat, and workspot families

The 250 retained questCharacterCondition wrappers contain:

Condtion is the native spelling in the two class names above. Preserve it when searching. Except for the bounded CharacterSpawned contract taught by Lab 5, these rows remain Observed in vanilla discovery entries. Before authoring one, establish actor/community ownership, reference form, streaming/readiness, the producer of the state change, and cleanup.

Lab 5’s focused spawn wait is:

questCharacterCondition
└── questCharacterSpawned_ConditionType
    ├── objectRef.reference: community NodeRef
    └── comparisonParams
        ├── comparisonType: Greater
        ├── count: 0
        └── entireCommunity: 1

Read it literally: the community-scoped spawned count is greater than zero. It does not prove that every actor in a multi-entry community is ready.

Scene, content, phone, and system families

Every row is Observed in vanilla. A condition is a consumer of state; it does not create the scene, token, phone call, or camera behavior it observes.

Vehicle and spawning families

These rare families are Observed in vanilla and remain poor copy-by-name recipes. Test them in a small mod-owned project before integrating them into a quest.

Distance operands

All 55 retained questDistanceCondition wrappers use questDistanceComparison_ConditionType. The focused operand relationship is:

questDistanceComparison_ConditionType
├── distanceDefinition1 -> questObjectDistance
│   ├── entityRef
│   └── nodeRef2
├── distanceDefinition2 -> questValueDistance
│   └── distanceValue
└── comparisonType

Call distanceValue a numeric threshold. The retained shape does not prove a universal measurement unit, the reference points used on each entity, or streaming/teleportation policy.

Focused vanilla search routes

Extract these resources from your own game and retain only focused notes or excerpts. Do not redistribute the CR2W files or full serializations.

Before using an indexed family

For a condition not yet taught as a practical recipe, retain:

1. the exact immediate or waiting graph node and socket route;
2. the wrapper, nested concrete payload, and every decisive field;
3. ownership and resolution for every external identifier;
4. the system or graph operation that produces the observed state;
5. a mod-owned WolvenKit 8.19.0 round trip with non-null compatible handles;
6. already-true, normal-transition, false/failure, save/load, stream-loss, cancellation, completion, and re-entry cases as applicable;
7. exact versions, installed filenames, save history, and logs.

Until those checks exist, a corpus row remains Observed in vanilla and a new behavior claim remains Experimental.