Delays, facts, and persistence boundaries

A delay in a questphase is a condition payload, normally held by a Pause Condition node. It gates the route that entered it; it does not schedule a complete quest action by itself. The nodes after the delay still own the journal update, fact write, scene start, or other effect.

This distinction matters when saves, time skips, and re-entry are involved. The serialized resource describes the delay and its wiring, while only runtime tests can establish how its active state survives interruption.

Pinned acceptance environment

Runtime test date: not yet recorded.

The book-owned Lab 2 CR2W resources are Structurally validated by cooking and serializing them back with WolvenKit 8.19.0. The other values pin the environment required by the future runtime acceptance run; they have not yet been exercised together for Lab 2. Timing and reload behavior therefore remain Experimental until the dedicated record passes.

Realtime delay payload

questTimeCondition wraps a concrete time condition. The realtime form is questRealtimeDelay_ConditionType:

Keep the spelling miliseconds in the native property tree. Correcting it to English creates the wrong field in raw representations.

Observed in vanilla: nested Pause Condition node 71 in base\open_world\street_stories\westbrook\japantown\sts_wbr_jpn_03\phase\sts_wbr_jpn_03_streetstory.questphase holds a two-second realtime delay.

Lab 2 uses 30- and 120-second realtime waits so the intermediate objective state is observable and a tester can make a mid-flow save. The WolvenKit round-trip proves their resource shape; it does not yet prove what the clock does in a pause menu, loading screen, or save/reload.

Game-time delay payload

questGameTimeDelay_ConditionType stores game-world duration fields:

Observed in vanilla: the following depot resources contain long game-time waits:

Those observations establish the payloads, not every clock rule. The contact, message, or scene seen after an SQ011 delay is downstream behavior and should not be attributed to the time condition itself.

Delay a follow-up offer after completion

To offer a second quest twelve game hours after the first completes, use two sequential waits before activating any message or reply choice:

Input
  -> Pause(completed fact > 0)
  -> Pause(game-time delay: 0 days, 12 hours, 0 minutes, 0 seconds)
  -> activate offer message
  -> activate reply choices

In WolvenKit, give the first Pause Condition a questFactsDBCondition wrapping questVarComparison_ConditionType: your completion fact, comparisonType = Greater, value = 0. Give the second a questTimeCondition wrapping questGameTimeDelay_ConditionType with the duration above. Connect the first Out to the second In, then the second Out to the message’s Active socket. Keep reply activation downstream too.

This graph expresses a wait that becomes active after the prerequisite passes. Starting both waits in parallel expresses a different timing requirement: the delay can become active while the prerequisite is still pending. An immediate Condition is also unsuitable if this running route needs to wait for a completion fact that is currently zero.

This follow-up pattern is Experimental until tested in game.

A completion prerequisite and a delay do not replace a separate already-sent guard. Preserve that guard when composing a one-shot offer. Nor can the new gate retract an offer already delivered by an older build: repeat from an untouched pre-install save. Test initial suppression, completion, elapsed game time, reload during the wait, and duplicate prevention separately.

Choose the clock deliberately

Use a realtime delay when the authored meaning is a short wall-clock beat such as debouncing a transition or allowing a presentation step to breathe. Use a game-time delay when the fiction depends on Night City time passing.

Do not choose solely by duration. A ten-second game-time wait and a ten-second realtime wait ask different runtime questions:

All answers in that table are Experimental until tested on the pinned build. Enum names and vanilla serialization do not settle them.

Facts are durable design state, not Boolean variables

questFactsDBCondition compares a named fact’s signed integer value. Facts are often used as zero/nonzero flags, but their native model is an integer:

cqa002_completed Equal 0
cqa002_test_mode Equal 2
cqa002_signal_failed Greater 0

The comparison operators represented in retained resources include Equal, NotEqual, Greater, GreaterOrEqual, Less, and LessOrEqual.

A fact can make a delayed route re-entry-safe only if the graph checks and writes it at the right boundaries. The fact’s persistence does not magically cancel an active listener or undo a side effect that already ran.

One-shot entry guard

Place a completed guard before the first player-facing or save-backed effect:

Input
  -> Condition(completed == 0)
       False -> terminating Output
       True  -> first-run route

Write the completion fact before, or in a tightly controlled sequence with, the final visible completion transition. Then make the False route terminate without reactivating journal entries, starting scenes, or spawning world content.

Use different facts when “started” and “completed” have different meanings. One fact cannot distinguish a partially completed run from a never-started run.

The labs supply a Structurally validated guard. Test re-entry and reinstallation using a completed save to check its one-shot behavior.

Clean-save rule

Facts, journal state, active quest nodes, scene state, communities, and device persistent state can all be save-backed. A save made after an earlier build was installed is not a clean first-run test, even when the archive has since been removed.

For every practical delay or one-shot test, retain:

1. one untouched save created before the candidate was first installed;
2. one save made while the delay or listener is active;
3. one save made after completion;
4. the exact installed archive and registration file;
5. exact game/mod versions and fresh logs;
6. observations and fresh logs for each run.

Never reuse the mid-flow or completed save as the clean replay baseline.

Minimum timer acceptance matrix

Record what happened; do not normalize a surprising result into the behavior you expected. See Lab 2 test protocol for the concrete two-route version of this matrix.

Test pause-menu, process-restart, time-skip, and fast-travel behavior separately when your quest depends on them. For parallel waits, also test simultaneous arrival and a late second input.