NPCStandIn was written to be dropped on a sphere and carried its identity in
per-instance public fields. The cost of that showed up in the scene itself: of
the two spheres, one was the Bartender and the other was named "Bartender (1)"
in the hierarchy while being configured as the Chair — data changed, name never
was. Nothing outside the scene could see what existed, and two copies could
disagree.
Identity now lives in an InteractableDefinition asset and the scene only places
a prefab. The migration matched the old objects by yarn node rather than by
name, which is the only reason the chair ended up as the chair.
InteractableDefinition rather than the planned "character definition": it covers
a character and a talkable object equally, so Bartender.prefab sits under
Prefabs/Characters and Chair.prefab under Prefabs/Interactables.
Three components collapse into one. DialogueInteractable was in no scene at all
— a dead trigger-zone variant of the same idea. ClickInteractableBridge existed
only to adapt NPCStandIn without modifying it, a constraint that died with
NPCStandIn; DialogueInteractor implements IClickInteractable itself. The parts
worth keeping were lifted out rather than discarded: WorldSpaceLabel and
InteractionPrompt are now normal components on prefab children, so a label can
be seen and positioned in the Editor instead of existing only at runtime.
InputDeviceTracker moved into NightclubArcadia.Core and gained a namespace,
leaving no global-namespace runtime types.
Characters get the same pipeline as Skills and Candidates:
Assets/Characters/characters.json is the source of truth, CharacterSetup
regenerates the definition assets on script reload and removes orphans. Adding
an NPC is a JSON entry plus a prefab — no code, and no Unity for the data half.
Phase 5.4 deletes the one-shot builders rather than disabling them. UILayerSetup,
PlayerControlSetup, UILayerSetupAutoRun and YarnDemoSetup assumed the
single-scene layout, had already destroyed a level scene and turned Systems
binary once each, and after NPCStandIn went they no longer compiled. The prefabs
they used to generate are authored and committed; the wiring knowledge is in
those prefabs and in git history. The asset generators — Skill, Candidate,
Character — are untouched and still work.
EditMode 42/42, PlayMode 7/7, YarnCheck 9 files / 35 nodes. All three scenes
still text.
Co-Authored-By: Claude Opus 5 <[email protected]>
Fixes "Can't start dialogue: no Yarn Project has been configured."
Cause, and it was mine. Phase 3.7 said "retarget YarnDemoSetup.cs or retire it";
I retargeted it. But that menu does not modify a scene — it builds one from
scratch and calls SaveScene over its target. Pointing it at
SC101_ConferenceHall.unity armed it at the real level, and running it replaced
the scene with a bare Yarn demo: ten of fourteen roots gone, including the
player, the lighting and the navmesh. The leftover Dialogue System prefab
instance it left behind had no yarnProject override, auto-started, and produced
the error.
The scene was committed, so nothing was lost; it is restored from HEAD at 14
roots with its sun reference intact.
The menu now targets Assets/Scenes/Dev/YarnSandbox.unity and refuses to run if
its target is not under Scenes/Dev, via ScenePaths.IsDisposable. It is renamed
to "Set Up Yarn Sandbox Scene" so the menu says what it does. The other three
setup menus open and modify their target rather than regenerating it, so they
were never affected and are unchanged.
The test suite could not have caught this, because it asserted only that a
DialogueRunner existed. TheDialogueRunner_HasItsYarnProject now asserts there is
exactly one runner across the loaded scenes and that its project is set and
compiled — which reproduces the failure exactly when the scene is broken.
Also here: four UI prefabs pick up m_EditorClassIdentifier changes from
Assembly-CSharp to NightclubArcadia.Game, written by Unity after the assembly
split in the previous commit. Expected and correct.
EditMode 42/42, PlayMode 6/6, YarnCheck 9 files / 35 nodes.
Co-Authored-By: Claude Opus 5 <[email protected]>
Runtime UI under Scripts/UI: a UIStateController owning menu/dialogue state, a
PlayerControlLock so opening a panel suppresses world input, panel visibility
helpers, and the menu input binding.
Views: the dialogue stream presenter and its options presenter and message row,
the portrait HUD, and the player menu with character, journal, and tab-bar
views. Skills gains SkillsPanelView and SkillRowView, which is why the Skills
asmdef now references UnityEngine.UI.
Prefabs/UI holds the authored canvases (dialogue stream, HUD, player menu) and
their rows. UILayerBootstrap remains a hand-added runtime fallback for scenes
where those prefabs are not instantiated; it deliberately does not auto-spawn.
Editor/UILayerSetup.cs is the one-shot menu that builds and wires those prefabs
into a scene, with UILayerSetupAutoRun reminding after a script reload.
Art/UI/Placeholder carries the placeholder portrait the HUD falls back to.
Co-Authored-By: Claude Opus 5 <[email protected]>
lennartandClaude Opus 5