Communities and characters

A community is the native world-side system that turns a character record and one or more AI spots into actors that quest logic can activate, wait for, hand to a scene, and eventually deactivate. No single resource owns that complete lifecycle:

always-loaded community registry
  + streamed compiled community area
  + streamed AI spot and workspot
  + questphase activation and readiness gate
  + scene actor acquisition
  + delayed questphase cleanup

Treat those as cooperating owners. A valid TweakDBID does not place an actor, an AI spot does not activate its community, and a scene actor definition does not spawn the character it intends to acquire.

Advanced characters add two more chains without replacing the community:

Character record -> .ent exposed mapping -> .app internal definition

spawned community actor -> Gameplay AI tier -> temporary role/workspot
  -> observed result -> scene/phase/cleanup handoff

The first controls gameplay defaults and renderable presentation. The second temporarily changes what one spawned actor is doing. Neither should borrow a story-unique character or mutate a shared vanilla resource.

The beginner-safe lifecycle is:

Activate community
  -> wait for CharacterSpawned
  -> enter a broad setup area
  -> start the scene
  -> acquire the community entry
  -> consume the named scene outcome
  -> advance outcome-specific journal or branch state
  -> wait until V leaves a cleanup area
  -> Deactivate community
  -> complete the owning phase and its terminal one-shot state

The order is part of the design. Starting the scene immediately after Activate creates a race between actor materialization and scene acquisition. Deactivating on the scene’s last spoken line can remove an actor while the scene, AI, or workspot still owns it.

Native ownership map

This builds on the resource model, identifier domains, world streaming model, and persistent state.

Three world identity domains

The retained compact community shape places three numeric identity domains beside one another:

1. the community/source identity shared by the compiled area’s sourceObjectId and its registry item’s communityId;
2. the separate world-node identity of the registry node itself;
3. one separate world-global identity for every AI spot.

They must not be collapsed because all three can appear as 64-bit values. The AI spot’s full NodeRef, the community entry’s CName, and its character record’s TweakDBID are additional typed identities. A debug name is none of them.

Registries and compiled areas explains the exact joins and the collision that motivated this rule.

Reading route

Read these chapters in order:

1. Registries and compiled areas — where template data lives, how a streamed source meets its registry item, and why registry, source, and spot identities stay separate.
2. Entries, phases, and AI spots — how an entry selects a character record, appearance, time period, and placed workspot.
3. Activation, readiness, and acquisition — why Activate, CharacterSpawned, broad setup, and scene acquisition are four different lifecycle steps.
4. Cleanup and character safety — delayed deactivation, save-aware tests, unique-character hazards, and the bounded generic-character recommendation.
5. Character records, entities, and appearances — the native record-to-entity-to-appearance chain, typed identities, mod-owned authoring boundary, and render/lifecycle acceptance matrix.
6. AI roles, behavior, and workspots — record behavior, Gameplay tier, follower/patrol roles, direct workspot commands, state observation, and ownership transfer.

The later scene chapters own screenplay, actor/performer, entry-point, and named-exit details. This section explains only the community side of their join.

Vanilla references

Extract the following resources from your own game with WolvenKit. Do not copy or redistribute the extracted CR2W files.

Each path supplies Observed in vanilla evidence for its own focused shape. It is not a template for copying unrelated IDs, records, appearances, or world positions.

First-pass failure routing

WolvenKit opening every file and ArchiveXL mounting the block are intermediate checks. Use the Lab 5 clean-save procedure to verify the complete cqa005 activation, acquisition, and cleanup route in game.