Activation, readiness, and acquisition

Community activation, actor readiness, player approach, and scene acquisition are four separate runtime events. Connecting them in that order prevents the scene from racing the world streamer:

questSpawnManager Activate
  -> questCharacterSpawned condition
  -> broad setup-area condition
  -> scene start
  -> scnActorDef community acquisition

The first node requests a state change. The second observes materialization. The third gives world and scene setup an approach boundary. The fourth asks an already-running scene to bind a performer to the available community entry. None substitutes for another.

Vanilla references

These focused base-game resources are useful comparisons. Extract them from your own installation; they are references, not files to copy into the project.

base\quest\minor_quests\mq003\mq003_orbitals.questphase
base\quest\minor_quests\mq003\phases\mq003_homeless.questphase
base\quest\minor_quests\mq003\scenes\mq003_01_homeless.scene

Activate requests community state

A questphase uses questSpawnManagerNodeDefinition. Its actions array can contain a questSpawnManagerNodeActionEntry whose typed payload is questCommunityTemplate_NodeType:

questSpawnManagerNodeDefinition
  actions[]
    questSpawnManagerNodeActionEntry
      type -> questCommunityTemplate_NodeType
        action: Activate
        spawnerReference: NodeRef
        communityEntryName: CName
        communityEntryPhaseName: CName

spawnerReference must resolve to the intended community source. The two CName fields decide whether the command addresses a named entry/phase or the broader community operation used by the inspected vanilla pattern.

None is an authored CName, not a missing field, null, or an empty string. The whole-community action uses Activate None/None; a focused action names the community-local entry and phase.

Choose scope deliberately:

An Out edge from the Spawn Manager says the command was issued. It does not prove the streamed area is present, a spot is available, an entity was constructed, or a scene can acquire that entity.

CharacterSpawned observes readiness

The focused retained condition shape is:

questPauseConditionNodeDefinition
  condition -> questCharacterCondition
    type -> questCharacterSpawned_ConditionType
      objectRef.reference: NodeRef
      comparisonParams
        comparisonType: Greater
        count: 0
        entireCommunity: 1

Read this payload literally. With Greater, count 0, and entireCommunity: 1, the condition asks whether the spawned count evaluated at community scope is greater than zero. It does not mean “every configured actor is ready.” For a one-entry contact, that distinction is small. For a three-entry encounter, it is decisive.

The objectRef.reference must target the same community intended by the activation action. Do not substitute the registry node’s world-global ID, the AI spot NodeRef, the entry CName, or the character TweakDBID. Those belong to different identity domains.

If a scene requires several specific performers, prove every required actor instead of treating aggregate > 0 as enough. Parallel actor- or entry-scoped spawn waits converging on an explicit And rendezvous make that requirement visible in the graph. This follows from the comparison semantics; it is not a claim that every vanilla multi-actor scene uses that exact graph. Check a vanilla resource with the same actor count and lifecycle before treating the arrangement as a reusable precedent. The single-entry cqa005 contact uses the same ordering and is exercised by the Lab 5 test guide.

Broad setup is an approach boundary

Readiness answers whether the actor exists. It does not answer whether V has approached through a useful streaming corridor or whether scene setup has had time to establish its state.

Use a generous outer trigger as the scene-start boundary after readiness:

Activate issued
  -> spawned readiness true
  -> V enters broad setup area
  -> checkpoint if the phase owns one
  -> start scene at its named input

The exact radius is location-specific. It must be supported by measured approach routes, streaming distance, sight lines, and the scene’s intended staging. A number retained from another location is not evidence for the new one. See Triggers and areas for volume and edge semantics.

Keep narrower mood, awareness, greeting, or interaction gates inside the already-running scene when that is the intended presentation. If the scene is launched only after the narrowest gate is true, all earlier setup conditions may already be satisfied on its first update. That can collapse setup, AI ownership, and opening dialogue into one startup tick.

The broad setup edge is not another spawn command. It is a sequencing and streaming boundary between the readiness proof and scene initialization.

The scene acquires; it does not spawn

A community-backed scene actor uses this focused shape:

scnActorDef
  acquisitionPlan: community
  actorId: scnActorId
  actorName
  communityParams -> scnCommunityParams
    reference: NodeRef
    entryName: CName

The fields cross three contracts:

The scene’s entryName must exactly match the registry template entry and the compiled area’s entry mirror. The reference must resolve in the scene’s NodeRef context to the same community used by the questphase. A character can be visible in the world while acquisition still fails because either join is wrong.

Scene acquisition also does not transfer permanent ownership. The quest still owns activation and cleanup; the scene owns the actor only for the performance window. Let the scene produce a named outcome before the quest advances to cleanup. The Scenes section owns the screenplay, performer, entry-point, and exit details.

Authoring and review procedure

For one community-backed contact:

1. Confirm the registry item and streamed area use the intended community identity and that the area can stream on every supported approach.
2. Add a Spawn Manager action using the community source NodeRef and chosen whole-community or named-entry scope.
3. Add a separate CharacterSpawned pause condition. Inspect the comparison, count, entireCommunity, and object reference rather than relying on the node caption.
4. Route readiness to a broad setup-area condition. Do not duplicate the activation action on every approach branch.
5. Start the scene through the exact named input after readiness and setup are both satisfied.
6. Set every community-backed scnActorDef to acquisitionPlan: community with the matching community reference and entry CName.
7. Route each named scene outcome back into explicit quest progression before scheduling cleanup.

For multiple required performers, repeat step 3 at the necessary scope and join the waits explicitly. Do not infer “all ready” from a single > 0 community count.

Acceptance matrix

Test the complete join in game, not only in WolvenKit:

The Lab 5 cases cover the supplied pre-scene save and the separate near-site arrival save. Generic fast-travel arrival, arbitrary pre-scene save points, active-line/interruption reload, and alternate named outcomes are additional tests for a quest that uses them.

Record the installed installed archive name, starting save, approach route, game and tool versions, exact first and last visible behavior, and any crash or log artifact. A successful CR2W round trip is Structurally validated; it is not a runtime result.

Common failures

Next: Cleanup and character safety.