modwright 0.1.2 → 0.1.3

package/knowledge/cyberpunk2077/codeware.systems.yaml

@@ -15,20 +15,42 @@ facts:
       - redscript
       - cet
       - red4ext
-    detail: "Source corrected 2026-09-07: RED4ext is listed under Installation, not Compatibility, and
-      the previous claim's parenthetical \"(per its own README, version 1.18.0 wiki)\" conflated two
+    detail: >-
+      Source corrected 2026-09-07: RED4ext is listed under Installation, not Compatibility, and the
+      previous claim's parenthetical "(per its own README, version 1.18.0 wiki)" conflated two
       things. 1.18.0 is the version stamped on line 1 of the Codeware wiki's Home page, and is what
       every API fact in this file was read against; it is not a floor. Framework versions stay in
-      the claim; \"Cyberpunk 2077 2.31\" is the game version this Codeware release targets, not an
+      the claim; "Cyberpunk 2077 2.31" is the game version this Codeware release targets, not an
       observation date, so there is no `verified_on`. This instantiates the general
-      cp2077.packaging.version-matrix-breakage."
+      cp2077.packaging.version-matrix-breakage.
+
+      Checked against commit 3a43182 (2026-08-28): README.md's Compatibility and Installation
+      sections are byte-for-byte unchanged (game 2.31, redscript 0.5.31+, CET 1.37.0+, RED4ext
+      1.29.0+) — neither confirmed nor contradicted by executable code, since these are floors on
+      other projects' version numbers, not something Codeware's own build asserts. xmake.lua's
+      `set_version("1.20.4", ...)` is a fourth, unrelated axis: Codeware's own release version, now
+      ahead of the "1.18.0" still stamped on the wiki's Home page at this same commit — the wiki
+      page has not been bumped to match the 1.20.4 project version.
   - id: cp2077.codeware.systems.service-persists-between-sessions
     claim: '"Services are singletons that created on scripts initialization and, unlike scriptable
       systems, live between game sessions. To create your own service, you have to define a class
       derived from `ScriptableService`." The instance is reached with
       `GameInstance.GetScriptableServiceContainer().GetService(n"MyService") as MyService`.'
-    status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Scriptable services"
+    status: inferred
+    source: "cp2077-codeware wiki Home, section \"Lifecycle > Scriptable services\"; confirmed against
+      commit 3a43182 in scripts/Scripting/ScriptableService.reds (`public abstract native class
+      ScriptableService` with commented-out `OnLoad`/`OnReload`/ `OnInitialize`/`OnUninitialize`
+      callback signatures) and scripts/Scripting/ScriptableServiceContainer.reds (`public abstract
+      native class ScriptableServiceContainer extends IGameSystem { public native func
+      GetService(name: CName) -> ref<ScriptableService> }`, reached via `@addMethod(GameInstance)
+      public static native func GetScriptableServiceContainer()`). The cross-session persistence is
+      implemented in src/App/Scripting/ScriptableServiceContainer.cpp: `OnInitializeScripts`
+      instantiates every non-abstract `ScriptableService` subclass and calls `OnLoad` (or `OnReload`
+      if `m_scriptsLoaded` is already true, distinguishing the two lifecycle events exactly as the
+      wiki describes); `LoadState`/`SaveState` (de)serialize `m_services` to a `.dat` file under
+      Codeware's own persistent-data directory (`s_stateDir`, separate from any save file) via
+      `Red::ObjectSerializer`, with `SaveState` called from `OnInitializeGameInstance`,
+      `OnBeforeWorldDetach` and `OnBeforeGameSave`."
     tags:
       - codeware
       - scriptableservice
@@ -42,8 +64,16 @@ facts:
     claim: '"If you declare `MyService` in a module, you must include the full path of the module to get
       the service" — a service declared in `module MyModule.Services` is fetched as
       `GetService(n"MyModule.Services.MyService")`.'
-    status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Scriptable services"
+    status: inferred
+    source: "cp2077-codeware wiki Home, section \"Lifecycle > Scriptable services\"; confirmed against
+      commit 3a43182: `GetService` in src/App/Scripting/ScriptableServiceContainer.cpp looks the
+      service up by exact `Red::CName` key
+      (`m_services.find(aType)`/`m_services.emplace(serviceType->name, ...)`), where
+      `serviceType->name` is the RTTI class's full name as registered by the redscript compiler —
+      module-qualified for a class declared inside a `module` block. The same full-path pattern is
+      used elsewhere in Codeware's own scripts, e.g. scripts/Localization/LocalizationSystem.reds's
+      `GameInstance.GetScriptableSystemsContainer(game).Get(n\"Codeware.Localization.LocalizationSy\
+      stem\")`."
     tags:
       - codeware
       - scriptableservice
@@ -56,7 +86,15 @@ facts:
       systems, service state storage is not tied to save files." "Persistence is available for all
       types except `String`, `ResRef`, `Variant`."'
     status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Scriptable services"
+    source: "cp2077-codeware wiki Home, section \"Lifecycle > Scriptable services\". Checked against
+      commit 3a43182: found the `persistent` field qualifier handled by the generic
+      `RTTI_PERSISTENT`/`RTTI_PERSISTENT_FQN` macros in the vendored
+      lib/Red/TypeInfo/Macros/Definition.hpp, which Codeware uses on its own internal state
+      (`RTTI_DEFINE_CLASS(App::ScriptableServiceContainerState, { RTTI_PERSISTENT(services); })` in
+      src/App/Scripting/ScriptableServiceContainer.hpp) — but no C++ in src/App enumerates or
+      enforces a `String`/`ResRef`/`Variant` exclusion list for user-declared `persistent` fields on
+      mod services. That exclusion looks like native engine/redscript-compiler behavior outside
+      Codeware's own source, so this claim is neither confirmed nor contradicted here."
     tags:
       - codeware
       - persistent
@@ -70,7 +108,12 @@ facts:
       are reset to defaults on each game launch. It's safe to change persistent data structure at
       any time.\""
     status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Scriptable services"
+    source: 'cp2077-codeware wiki Home, section "Lifecycle > Scriptable services". Checked against
+      commit 3a43182: this describes how the native object serializer restores only
+      `persistent`-flagged fields (see cp2077.codeware.systems.persistent-field-type-exclusions for
+      what was found on that mechanism); no Codeware C++ specifically implements the "unmarked
+      fields reset to defaults" behavior for user service objects beyond relying on that native
+      (de)serialization, so it is left unconfirmed rather than promoted.'
     tags:
       - codeware
       - persistent
@@ -83,8 +126,9 @@ facts:
       disposed when game session ends. An unreleased reference can interfere with normal object
       disposal and lead to bugs such as disappearing sounds or crashes."'
     status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Scriptable services" (the "Referencing game
-      objects" blockquote)
+    source: 'cp2077-codeware wiki Home, section "Lifecycle > Scriptable services" (the "Referencing game
+      objects" blockquote). Checked against commit 3a43182: this is a caution in prose with no
+      single API to test it against — left community.'
     tags:
       - codeware
       - scriptableservice
@@ -102,8 +146,26 @@ facts:
       `EntityTarget.ID`/`.Type`/`.RecordID(TweakDBID)`/`.Template`/`.Appearance`/`.Definition`,
       `ComponentTarget.ID`/`.Name`, `InputTarget.Key`/`.Axis`,
       `inkWidgetTarget.Library`/`.Controller`.
-    status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Game events"
+    status: inferred
+    source: "cp2077-codeware wiki Home, section \"Lifecycle > Game events\"; confirmed against commit
+      3a43182 in scripts/Callback/CallbackSystem.reds (`public native class CallbackSystem extends
+      IGameSystem` with `RegisterCallback (eventName: CName, target: ref<IScriptable>, function:
+      CName, opt sticky: Bool) -> ref<CallbackSystemHandler>`, reached via
+      `GameInstance.GetCallbackSystem()`) and scripts/Callback/CallbackSystemHandler.reds
+      (`AddTarget(target: ref<CallbackSystemTarget>) -> ref<CallbackSystemHandler>`, `SetRunMode`,
+      `SetLifetime`). All 15 event names are exact `Red::CName` constants in
+      src/App/Callback/Controllers/*Hook.hpp and src/App/Callback/CallbackSystem.hpp
+      (`Resource/Load`, `Resource/PostLoad`, `Session/BeforeStart`, `Session/Start`,
+      `Session/Ready`, `Session/BeforeSave`, `Entity/Extract`, `Entity/Assemble`,
+      `Entity/Initialize`, `Entity/Reassemble`, `Entity/Attach`, `Entity/Detach`,
+      `Component/Toggle`, `Input/Key`, `Input/Axis`, `InkWidget/Spawn` — note CallbackSystem.hpp
+      also defines further Session events, `Session/BeforeEnd`/`Session/End`/
+      `Session/AfterSave`/`Session/Pause`/`Session/Resume`, not in the wiki's table, consistent with
+      the claim's \"include\" wording rather than an exhaustive list). All selectors confirmed in
+      scripts/Callback/Targets/*.reds: `ResourceTarget.Path`/`.Type`,
+      `EntityTarget.ID`/`.Type`/`.RecordID`/`.Template`/`.Appearance`/ `.Definition`,
+      `ComponentTarget.ID`/`.Name`, `InputTarget.Key`/`.Axis`,
+      `inkWidgetTarget.Library`/`.Controller`."
     tags:
       - codeware
       - callbacksystem
@@ -112,16 +174,32 @@ facts:
       - syntax
     detail: "Caution for a validator: the event table names `Entity/Attach`, but the wiki's own
       `SetRunMode` example registers `n\"Entity/Attached\"` — the two spellings disagree on the same
-      page. Callback lifetime: \"When defined inside scriptable service, callback stays registered
-      until you manually unregister it. When defined in other contexts, callback is auto removed at
-      the end of the session\", overridable with `.SetLifetime(CallbackLifetime.Forever)` or
-      `...Session)`. The callback system can be accessed before the game instance is initialized."
+      page. Still true at commit 3a43182: wiki/Home.md lines ~152 and ~294 still write
+      `n\"Entity/Attached\"` in worked examples, while `Entity/Attach` is the only name any hook
+      registers (src/App/Callback/Controllers/EntityAttachHook.hpp) — the wiki's own examples appear
+      to reference an event that does not exist; `Entity/Attach` (the table entry) is the one
+      confirmed by source. Callback lifetime: \"When defined inside scriptable service, callback
+      stays registered until you manually unregister it. When defined in other contexts, callback is
+      auto removed at the end of the session\", overridable with
+      `.SetLifetime(CallbackLifetime.Forever)` or `...Session)`. Confirmed in
+      src/App/Callback/CallbackSystem.cpp's `RegisterCallback`/ `RegisterStaticCallback`: `if
+      (aSticky || (aFrame && aFrame->context &&
+      Red::IsInstanceOf<ScriptableService>(aFrame->context)))
+      handler->SetLifetime(CallbackLifetime::Forever);` — a callback registered from inside a
+      `ScriptableService` gets `Forever` by default; otherwise it defaults to
+      `CallbackLifetime.Session` (value `0` in scripts/Callback/CallbackLifetime.reds) and is torn
+      down with the session. The callback system can be accessed before the game instance is
+      initialized."
   - id: cp2077.codeware.systems.callback-once-run-mode
     claim: '"You can make callback to auto unregister after being fired by calling
       `.SetRunMode(CallbackRunMode.Once)`." `CallbackRunMode.OncePerTarget` instead auto-unregisters
       "after being fired for each listed target".'
-    status: community
-    source: cp2077-codeware wiki Home, section "Lifecycle > Game events"
+    status: inferred
+    source: 'cp2077-codeware wiki Home, section "Lifecycle > Game events"; confirmed against commit
+      3a43182 in scripts/Callback/CallbackRunMode.reds: `public enum CallbackRunMode { Default = 0,
+      Once = 1, OncePerTarget = 2 }`, set via `CallbackSystemHandler.SetRunMode(runMode:
+      CallbackRunMode) -> ref<CallbackSystemHandler>` in
+      scripts/Callback/CallbackSystemHandler.reds.'
     tags:
       - codeware
       - callbacksystem
@@ -133,21 +211,42 @@ facts:
       require loading resources you can refresh appearance\" with `comp.RefreshAppearance()`.
       Supported components are `entMeshComponent`, `entSkinnedMeshComponent`,
       `entGarmentSkinnedMeshComponent` and `entMorphTargetSkinnedMeshComponent`."
-    status: community
-    source: cp2077-codeware wiki Home, section "Entities > Mesh appearances"
+    status: inferred
+    source: "cp2077-codeware wiki Home, section \"Entities > Mesh appearances\"; confirmed against
+      commit 3a43182 in scripts/Entity/IComponent.reds: `@addMethod(IComponent) public native func
+      LoadAppearance(opt wait: Bool) -> Bool` and `public native func RefreshAppearance() -> Bool`.
+      The exact four supported component types are confirmed in
+      src/App/Entity/ComponentWrapper.cpp's constructor, which classifies a component into
+      `ComponentType::MeshComponent`, `::SkinnedMeshComponent`, `::GarmentSkinnedMeshComponent` or
+      `::MorphTargetSkinnedMeshComponent` (else `::Unsupported`) by RTTI `IsA` checks against
+      `Red::ent::MeshComponent`, `Red::ent::SkinnedMeshComponent`,
+      `Red::ent::GarmentSkinnedMeshComponent` and `Red::ent::MorphTargetSkinnedMeshComponent` —
+      matching `entMeshComponent`/`entSkinnedMeshComponent`/
+      `entGarmentSkinnedMeshComponent`/`entMorphTargetSkinnedMeshComponent` exactly."
     tags:
       - codeware
       - loadappearance
       - refreshappearance
       - entity-component
-    detail: The worked example is `comp.mesh *= r"mod\player\dynamic.mesh"; comp.meshAppearance =
-      n"neon_red"; comp.LoadAppearance();`. Softened on 2026-09-07 from "must be called ... (it
-      re-resolves resources)" to the wiki's own "you can request it to load".
+    detail: "The worked example is `comp.mesh *= r\"mod\\player\\dynamic.mesh\"; comp.meshAppearance =
+      n\"neon_red\"; comp.LoadAppearance();`. Softened on 2026-09-07 from \"must be called ... (it
+      re-resolves resources)\" to the wiki's own \"you can request it to load\". Confirmed the
+      resource re-resolution distinction in src/App/Entity/ComponentEx.cpp: `LoadAppearance` calls
+      `ComponentWrapper::LoadResource(/*refresh=*/true, aWait)`, which re-resolves the mesh/morph
+      resource path and then refreshes the appearance; `RefreshAppearance` calls
+      `ComponentWrapper::RefreshAppearance()` directly without touching the resource path — matching
+      the wiki's \"changed mesh/appearance\" vs. \"changed other properties\" split."
   - id: cp2077.codeware.systems.static-entity-reposition-without-respawn
     claim: '"Static entities can be moved now without respawning them at new position" via
       `entity.SetWorldTransform(transform)`.'
-    status: community
-    source: cp2077-codeware wiki Home, section "Entities > World transform"
+    status: inferred
+    source: 'cp2077-codeware wiki Home, section "Entities > World transform"; confirmed against commit
+      3a43182 in scripts/Entity/Entity.reds: `@addMethod(Entity) public native func
+      SetWorldTransform(transform: WorldTransform)`. The method is added to the base `Entity` class
+      (usable on any entity, not only ones spawned via StaticEntitySystem), implemented in
+      src/App/Entity/EntityEx.hpp as `Raw::IPlacedComponent::SetTransform(transformComponent,
+      aTransform)` — a direct transform-component update, confirming the "without respawning" claim
+      (no despawn/respawn round-trip).'
     tags:
       - codeware
       - setworldtransform
@@ -157,8 +256,17 @@ facts:
       `playerSystem.GetCustomizationPuppet()`, `GetInventoryPuppet()` and `GetPhotoPuppet()`, from
       `GameInstance.GetPlayerSystem(GetGameInstance())`, for the customization screen, inventory
       screen and photo mode respectively.
-    status: community
-    source: cp2077-codeware wiki Home, section "Player > Accessing player objects"
+    status: inferred
+    source: "cp2077-codeware wiki Home, section \"Player > Accessing player objects\"; confirmed against
+      commit 3a43182 in scripts/Player/PlayerSystem.reds: `@addMethod(PlayerSystem) public func
+      GetCustomizationPuppet() -> wref<gamePuppet>`, `GetInventoryPuppet() -> wref<gamePuppet>` and
+      `GetPhotoPuppet() -> wref<gamePuppet>`, each backed by an `@addField`-ed `wref<gamePuppet>`
+      set via `@wrapMethod(inkPuppetPreviewGameController) OnPreviewInitialized`
+      (customization/inventory, keyed on the controller's class name
+      `gameuiCharacterCreationPuppetPreviewGameController`/
+      `gameuiInventoryPuppetPreviewGameController`) and `@wrapMethod(PhotoModePlayerEntityComponent)
+      SetupInventory` (photo mode) — matching the claimed customization/inventory/photo-mode mapping
+      exactly."
     tags:
       - codeware
       - playersystem
@@ -168,8 +276,12 @@ facts:
   - id: cp2077.codeware.systems.wardrobe-forget-item
     claim: '"Items can be permanently removed from wardrobe" with
       `GameInstance.GetWardrobeSystem(GetGameInstance()).ForgetItemID(ItemID.FromTDBID("Items.Glasses_03_basic_09"))`.'
-    status: community
-    source: cp2077-codeware wiki Home, section "Player > Managing wardrobe"
+    status: inferred
+    source: 'cp2077-codeware wiki Home, section "Player > Managing wardrobe"; confirmed against commit
+      3a43182 in scripts/Player/WardrobeSystem.reds: `@addMethod(WardrobeSystem) public native func
+      ForgetItemID(itemID: ItemID) -> Bool` (the only member Codeware adds to `WardrobeSystem`).
+      `ItemID.FromTDBID` itself is a base-game function (`gameItemID.FromTDBID`, called via
+      `Red::CallStatic` in src/App/World/OpenWorldSystem.cpp), not something Codeware defines.'
     tags:
       - codeware
       - wardrobesystem
@@ -181,8 +293,15 @@ facts:
       retrieved at runtime\" —
       `GameInstance.GetVehicleSystem(GetGameInstance()).EnablePlayerVehicleID(t\"Vehicle.v_sport2_q\
       uadra_type66_avenger_player\", true)`."
-    status: community
-    source: cp2077-codeware wiki Home, section "Player > Unlocking vehicles"
+    status: inferred
+    source: 'cp2077-codeware wiki Home, section "Player > Unlocking vehicles"; confirmed against commit
+      3a43182 in scripts/Vehicle/VehicleSystem.reds: `@addMethod(VehicleSystem) public func
+      EnablePlayerVehicleID(vehicleID: TweakDBID, enable: Bool, opt despawnIfDisabling: Bool) ->
+      Bool`, which checks `vehicleID` against
+      `TweakDBInterface.GetForeignKeyArray(t"Vehicle.vehicle_list.list")` before calling the native
+      `ToggleGarageVehicle(garageID: GarageVehicleID, enable: Bool) -> Bool`. Note the actual
+      signature has a third, optional `despawnIfDisabling: Bool` parameter not mentioned in the
+      claim (despawns the vehicle if disabling succeeds).'
     tags:
       - codeware
       - vehiclesystem

package/knowledge/cyberpunk2077/entities.queries.yaml

@@ -0,0 +1,275 @@
+game: cyberpunk2077
+topic: entities.queries
+title: "Finding entities at runtime: what the dynamic-entity tag registry does and does not see, and
+  the RTTI-confirmed spatial query methods"
+facts:
+  - id: cp2077.entities.gettaggedids-is-a-dynamic-entity-registry-not-a-node-lookup
+    claim: "Game.GetDynamicEntitySystem():GetTaggedIDs(tag) is Codeware's DynamicEntitySystem, and it
+      returns only entities that system itself created (DynamicEntitySpec.tags) or was told about
+      with AssignTag. A sector-placed static prop (a worldEntityNode in a .streamingsector) was not
+      found by it in two in-game checks (2026-08 and 2026-09-09), and the source shows why: nothing
+      a streaming sector spawns is ever entered into that registry."
+    status: verified
+    verified_on: "2.31"
+    source: ModWright field verification
+    tags:
+      - entity
+      - tag
+      - gettaggedids
+      - dynamic-entity
+      - codeware
+      - world-placement
+      - gotcha
+    related:
+      - cp2077.entities.native-gametagsystem-finds-entities-by-tag
+      - cp2077.entities.codeware-staticentitysystem-spawns-tagged-static-entities
+    detail: "What is verified in-engine is the negative: an untagged sector node is invisible to
+      GetTaggedIDs, and the tags the test mod used only ever marked entities its earlier experiments
+      spawned dynamically (which is why its cleanup script deletes them by tag). A claim briefly
+      recorded as verified on 2026-09-10 and corrected the same day — that setting the sector node's
+      `tag` CName would make GetTaggedIDs find it — is ruled out by the source: the registry is
+      populated from DynamicEntitySpec.tags and AssignTag calls only, never from streaming-sector
+      node data or from the native per-object tag list. Codeware does mirror its tags into the
+      native side on spawn (DynamicEntitySystem.cpp: gameObject->tags.Add on spawn; AssignTag also
+      calls Raw::TagSystem::AssignTag), but the direction is Codeware -> engine, not engine ->
+      Codeware. So \"tag the node, then GetTaggedIDs\" is dead; the live question is whether a node
+      tag reaches the *native* tag system, which is the next fact. The scaffold
+      cyberpunk2077.new-sector-node therefore ships `tag: None` (the vanilla entSpawner export
+      shape) and keeps its N-1 row manual."
+  - id: cp2077.entities.native-gametagsystem-finds-entities-by-tag
+    claim: "The shipped game has its own tag lookup, separate from Codeware's: gameGameTagSystem
+      (obtained via ScriptGameInstance::GetGameTagSystem, so from CET presumably
+      Game.GetGameTagSystem()) exposes GetAnyMatchingEntity(tag: CName) -> ref<entEntity> and
+      GetAllMatchingEntities(tag: CName, out entities: array<ref<entEntity>>) -> Bool; gameObject
+      carries a native `tags: redTagList` field and a native HasTag(tag: CName) -> Bool method.
+      Whether a worldEntityNode's `tag` field lands in that list or that system is untested."
+    status: unverified
+    source: "rayshader/cp2077-nativedb@b5d29af classes.json: class gameGameTagSystem (parent
+      gameIGameSystem) with exactly those two functions; ScriptGameInstance function
+      GetGameTagSystem returning ref<gameGameTagSystem>; class gameObject field tags of type
+      redTagList and function HasTag(tag: CName) -> Bool; class redTagSystem (no scripted
+      functions). psiberx/cp2077-codeware@3a43182 src/Red/TagSystem.hpp wraps the engine's
+      TagSystem_AssignTag/UnassignTag by address and scripts/Entity/GameObject.reds adds
+      `AddTag(tag: CName)` to GameObject — so the native list is real and writable. Read 2026-09-10;
+      nothing on disk calls GetGameTagSystem from Lua or redscript. Negative searches (2026-09-11):
+      CDPR-Modding-Documentation/Cyberpunk-Modding-Docs at 4e798d6 (591 pages) and NativeDB-wiki at
+      ed4e34d document neither this system nor a world node's tag/tagExt fields."
+    tags:
+      - entity
+      - tag
+      - gametagsystem
+      - hastag
+      - rtti
+      - world-placement
+      - live-check-next
+    related:
+      - cp2077.entities.gettaggedids-is-a-dynamic-entity-registry-not-a-node-lookup
+    detail: >-
+      This is the mechanism an auto-tag idea would actually need, and it is a hypothesis with two
+      halves to test: (1) does the CET global Game.GetGameTagSystem() resolve, and does
+      GetAnyMatchingEntity find an entity Codeware tagged (a known-positive control: spawn or
+      AssignTag something with Codeware, then look it up natively — Codeware mirrors its tags into
+      the native system, per the previous fact); (2) does a sector node authored with a non-None
+      `tag` come back from the same call, or at least answer obj:HasTag(tag) once the object is in
+      hand. Console lines (save loaded, standing near a placed prop whose node has a tag, and near
+      any Codeware-tagged dynamic entity):
+        local ts = Game.GetGameTagSystem(); print(type(ts))
+        local e = ts:GetAnyMatchingEntity("<codeware tag>"); print(e, e and e:GetClassName())
+        local ok, all = ts:GetAllMatchingEntities("<node tag>"); print(ok, type(all), all and all[1] and all[1]:GetClassName())
+        local o = Game.GetTargetingSystem():GetLookAtObject(Game.GetPlayer(), true, false); print(o and o:GetClassName(), o and o:HasTag("<node tag>"), o and o:GetCurrentAppearanceName())
+      GetAllMatchingEntities has an out-parameter, which CET returns as a second value after the
+      Bool (cp2077.cet.member-calls-via-colon-and-out-params-as-extra-returns), hence `ok, all`. The
+      last line is also the cheapest way yet found to get a handle on a placed prop with no position
+      probe at all: look at it. GetLookAtObject(instigator: wref<gameObject>, withLOS: Bool,
+      ignoreTranparent: Bool) -> ref<gameObject> is RTTI-listed on gametargetingTargetingSystem
+      (cp2077.rtti.targetingsystem-crosshair-and-distance-queries; an earlier draft of this line
+      named GetObjectClosestToCrosshair, which actually takes an instigator, an EulerAngles and a
+      gameTargetSearchQuery) and is unattested from Lua. If half (2) passes, the scaffold can tag
+      its nodes again and N-1 becomes an automated row against a *new* probe kind over
+      GetGameTagSystem, not over cp2077.entity.tagged; if it fails, node tags are a dead end and
+      only the position-based calls remain.
+  - id: cp2077.entities.codeware-staticentitysystem-spawns-tagged-static-entities
+    claim: 'Codeware also ships a StaticEntitySystem (Game.GetStaticEntitySystem() by the same
+      @addMethod pattern): SpawnEntity(StaticEntitySpec{templatePath, appearanceName, position,
+      orientation, attached, tags}) spawns an entity "the way world nodes usually do", with its own
+      tag registry (IsPopulated/GetTagged/GetTaggedIDs/DespawnTagged/AttachTagged/DetachTagged), no
+      persistent state, and no distance-based visibility. Its tag registry is as private as the
+      dynamic one: it does not see sector-placed nodes either.'
+    status: inferred
+    source: psiberx/cp2077-codeware@3a43182 wiki/Home.md "Spawning static entities" (option table and
+      ladder example); scripts/World/StaticEntitySystem.reds and StaticEntitySpec.reds;
+      src/App/World/StaticEntitySystem.cpp GetTaggedIDs() reads m_entityIDsByTag only; the
+      callback-target table lists StaticEntityTarget.Tag(CName) alongside
+      DynamicEntityTarget.Tag(CName).
+    tags:
+      - entity
+      - codeware
+      - static-entity
+      - spawn
+      - tag
+      - world-placement
+    related:
+      - cp2077.entities.gettaggedids-is-a-dynamic-entity-registry-not-a-node-lookup
+      - cp2077.loot.streaming-sector-required-for-loot
+    detail: Recorded because it is the third tagged spawn path and easy to confuse with the other two
+      when a probe says "tagged". It is not a replacement for sector placement — the
+      streaming-sector rule (cp2077.loot.streaming-sector-required-for-loot) is about loot
+      interactions on containers, which no script-side spawn path has been shown to provide — but
+      for a placement a mod is willing to make at runtime it would come with verification built in
+      (its own GetTaggedIDs). ModWright's CET bridge does not call it.
+  - id: cp2077.entities.gameobject-getnpcsaroundobject-exists-in-rtti
+    claim: "gameObject (parent entGameEntity; every puppet and most world objects descend from it)
+      carries the RTTI-registered method GetNPCsAroundObject(range: Float) returning
+      array<ref<NPCPuppet>> — NPCs within that range of the object it is called on."
+    status: inferred
+    source: 'rayshader/cp2077-nativedb@b5d29af classes.json, class entry {"a": "entGameEntity", "b":
+      "gameObject"} ("a" is the parent, "b" the class name in this dump), function entry {"a":
+      "GetNPCsAroundObject;Float", "e": [{"b": "range"}], "c": array<ref<NPCPuppet>>}. Read from the
+      committed dump on 2026-09-10 and re-checked 2026-10-04; the dumper was not run.'
+    tags:
+      - entity
+      - spatial-query
+      - rtti
+      - npc
+      - unverified-call
+    detail: "The dump is real reflection data from the shipped build, so the method's existence and
+      signature are solid. An earlier version of this fact placed the method on entGameEntity; that
+      came from reading the dump's \"a\"/\"b\" keys backwards. Not confirmed: that CET exposes it as
+      a Lua member call (`obj:GetNPCsAroundObject(r)` is assumed, matching every other RTTI method
+      the bridge calls that way) and what the returned array looks like from Lua. No CET mod or wiki
+      page calls it. ModWright's cp2077.entity.nearby probe kind attempts this call live,
+      pcall-wrapped, and stays unverified until a live run exercises it."
+  - id: cp2077.entities.gameobject-getentitiesaroundobject-filter-constructors-exist
+    claim: "gameObject also carries GetEntitiesAroundObject(range: Float, searchFilter:
+      gameTargetSearchFilter) returning array<ref<entEntity>> — any entity type, filtered.
+      gameTargetSearchFilter is an opaque native struct (a class entry with no listed fields), but
+      the same dump's globals.json lists constructor functions that return one: TSF_All(mask),
+      TSF_Any(mask), TSF_Not(mask), TSF_And(tsf1..tsf4), TSF_Or(tsf1..tsf4), TSF_NPC(),
+      TSF_EnemyNPC(), TSF_Quickhackable(); the mask type is
+      gametargetingSystemSearchFilterMaskValue."
+    status: unverified
+    source: 'rayshader/cp2077-nativedb@b5d29af classes.json: gameObject function entry {"a":
+      "GetEntitiesAroundObject;FloatTargetSearchFilter", "e": [{"b": "range"}, {"b": "searchFilter",
+      "a": {"b": "gameTargetSearchFilter"}}]}; class entry {"b": "gameTargetSearchFilter"} with zero
+      fields and zero functions; globals.json entries TSF_All, TSF_Any, TSF_Not, TSF_And, TSF_Or,
+      TSF_EnemyNPC, TSF_NPC, TSF_Quickhackable, each with return type gameTargetSearchFilter;
+      enums.json gametargetingSystemSearchFilterMaskValue. Also in classes.json:
+      gameTargetSearchQuery (fields testedSet, searchFilter, includeSecondaryTargets,
+      ignoreInstigator, maxDistance, filterObjectByDistance, queryTarget; SetComponentFilter). Read
+      2026-09-10, re-checked 2026-10-04.'
+    tags:
+      - entity
+      - spatial-query
+      - rtti
+      - target-search-filter
+      - live-check-next
+    detail: >-
+      This is the call that would verify a world placement that is not an NPC (a sector-placed prop,
+      say). An earlier version of this fact said no TargetSearchFilter class appears in the dump and
+      that constructing the struct would mean guessing a native layout; both were wrong — the class
+      is there (opaque), and the struct is meant to be obtained from the TSF_* constructor globals,
+      not built by hand. The Lua side is largely settled from CET's own source (the cp2077.cet.*
+      binding facts, 2026-09-11): non-member RTTI globals are exposed as bare names, as Game.Name
+      and as Game["Name;"]; a returned struct is a ClassReference copy that passes straight back
+      into a struct-typed parameter; an array return is a 1-based table whose null handles become
+      nil holes. The mask enum is in the dump too: enums.json
+      gametargetingSystemSearchFilterMaskValue (alias TSFMV): Obj_Player=1, Obj_Puppet=2,
+      Obj_Sensor=4, Obj_Device=8, Obj_Other=16, Att_Friendly=32, Att_Hostile=64, Att_Neutral=128,
+      Sp_AimAssistEnabled=256, Sp_Aggressive=512, St_Alive=2048, St_Dead=4096, St_NotDefeated=8192,
+      St_Defeated=16384, St_Conscious=32768, St_Unconscious=65536, St_TurnedOn=131072,
+      St_TurnedOff=262144, St_QuickHackable=524288, St_AliveAndActive=174080. CET coerces an
+      undeclared enum value to 0 silently
+      (cp2077.cet.enum-params-accept-number-string-or-enum-but-undeclared-values-become-zero), so
+      "every object" cannot be one ORed mask; it is TSF_Or(TSF_Any(E"Obj_Device"),
+      TSF_Any(E"Obj_Other"), TSF_Any(E"Obj_Puppet"), TSF_Any(E"Obj_Sensor")) with each member built
+      by Enum.new("gametargetingSystemSearchFilterMaskValue", name), the one form that fails loudly
+      on a wrong type name. Still unverified: whether the game marks TSF_* isExec (which would drop
+      only the bare-global form), the semantics of TSF_Any vs TSF_All and TSF_Or, whether a static
+      prop is in the targeting set at all (a loot-case template that carries a
+      gameTargetingComponent is the likely case), and what the calls return on a real prop.
+      ModWright's cp2077.entity.nearby handler attempts exactly this behind `filter: "objects"`,
+      pcall-wrapped. Console lines (a save loaded, standing near a known placed entity), counting
+      with pairs because of the nil holes:
+        print(type(TSF_NPC), type(TSF_All), type(Game.TSF_NPC), type(Game["TSF_NPC;"]))
+        local f = TSF_NPC(); print(type(f))
+        local r = Game.GetPlayer():GetNPCsAroundObject(20.0); local n=0; for _ in pairs(r or {}) do n=n+1 end; print(type(r), n)
+        local e = Game.GetPlayer():GetEntitiesAroundObject(20.0, f); local m=0; for _ in pairs(e or {}) do m=m+1 end; print(type(e), m, e and e[1] and e[1]:GetClassName())
+        local E = function(n) return Enum.new("gametargetingSystemSearchFilterMaskValue", n) end
+        local g = TSF_Or(TSF_Any(E("Obj_Device")), TSF_Any(E("Obj_Other")), TSF_Any(E("Obj_Puppet")), TSF_Any(E("Obj_Sensor")))
+        local a = Game.GetPlayer():GetEntitiesAroundObject(20.0, g); local k=0; for _,x in pairs(a or {}) do k=k+1; print(x:GetClassName()) end; print(type(a), k)
+      Record each line's exact output.
+  - id: cp2077.entities.spatial-and-targeting-systems-exist-but-are-heavier
+    claim: "Two other RTTI-registered systems expose broader spatial/targeting capability:
+      gameISpatialQueriesSystem (Overlap/OverlapByQueryFilter/SyncRaycastBy* — physics-engine
+      overlap and raycast queries) and gametargetingTargetingSystem (the concrete class behind
+      ScriptGameInstance::GetTargetingSystem; gameITargetingSystem is its empty interface parent):
+      GetTargetClosestByDistance, GetObjectClosestToCrosshair(instigator, angleDistance, query),
+      GetLookAtObject(instigator, withLOS, ignoreTranparent) -> ref<gameObject>, GetTargetParts, and
+      other player-aim-centric lookups (signatures in
+      cp2077.rtti.targetingsystem-crosshair-and-distance-queries). Neither is a simple \"list of
+      entities near a point\" call the way GetEntitiesAroundObject's name suggests; both need more
+      setup (a query shape or filter, or player-aim context) than a probe should invent blind."
+    status: unverified
+    source: rayshader/cp2077-nativedb@b5d29af classes.json, gameISpatialQueriesSystem and
+      gametargetingTargetingSystem class entries (captured 2026-09-10; class name corrected
+      2026-09-11 — the functions live on the concrete class, not the interface).
+    tags:
+      - entity
+      - spatial-query
+      - rtti
+      - targeting-system
+      - future-work
+    detail: "Recorded so a future session does not re-derive this from scratch: these exist and are real
+      engine capability, but gameObject's own GetEntitiesAroundObject/GetNPCsAroundObject are the
+      more directly applicable pair for \"what did ModWright place nearby\" and were pursued first
+      for that reason. GetTargetParts takes a gameTargetSearchQuery, whose searchFilter field is the
+      same gameTargetSearchFilter the TSF_* constructors produce."
+  - id: cp2077.entities.ententity-getcurrentappearancename-exists-in-rtti
+    claim: "entEntity carries GetCurrentAppearanceName() -> CName (no parameters) and
+      GetCurrentColorVariantName() -> CName; entIComponent carries GetAppearanceName() -> CName. A
+      sector-placed loot-case prop inherits the entity-level read: a template whose entity class is
+      LootContainerObjectAnimatedByTransform reaches entEntity through its parent chain."
+    status: inferred
+    source: ModWright research
+    tags:
+      - entity
+      - appearance
+      - rtti
+      - unverified-call
+      - live-check-next
+    related:
+      - cp2077.entities.native-gametagsystem-finds-entities-by-tag
+    detail: This is a direct read of the question cp2077.entity.appearance asks by differential
+      inference (did the sector node's appearanceName resolve?). One scalar return, the same risk
+      class as GetWorldYaw. Once any handle to the placed prop is in hand (GetLookAtObject, a native
+      tag lookup, or a position query), `obj:GetCurrentAppearanceName()` compared with the node's
+      authored appearanceName is the whole check. Registered nowhere yet; the probe registry's
+      cp2077.entity.appearance row names it as the candidate for the next live run.
+  - id: cp2077.entities.loot-case-template-component-names
+    claim: 'A sector-placed loot-case entity template (entity class
+      LootContainerObjectAnimatedByTransform) declares eleven components, by class and CName:
+      gameInventory "inventory", gameinteractionsComponent "interactions", gameScanningComponent
+      "scanning", WorkspotMapperComponent "workspotMapper", entPlaceholderComponent "root",
+      gameaudioSoundComponent "audioSound", gameVisionModeComponent "vision", entSlotComponent
+      "UI_Slots", GameplayRoleComponent "GameplayRole", entEffectSpawnerComponent "state_fxes",
+      gameTargetingComponent "targeting". A light-prop template declares one, a gameLightComponent
+      under a mod-chosen name.'
+    status: inferred
+    source: ModWright research
+    tags:
+      - entity
+      - component
+      - template
+      - interaction
+      - loot-container
+    related:
+      - cp2077.entities.ententity-getcurrentappearancename-exists-in-rtti
+    detail: Design-time template fields from one mod's loot case and another's light prop, not an
+      in-engine observation that each component resolves on the streamed instance; the registry rows
+      that ask for component names stay unverified, but no longer have to say the interaction name
+      is unattested anywhere. The light-prop mod's CET script calls ent:FindComponentByName(<its
+      light's name>) — a live call against a name taken from the template, which is the pattern
+      cp2077.entity.components and cp2077.interaction.present rely on. The presence of
+      gameTargetingComponent "targeting" on the case is also the first evidence that a sector-placed
+      prop of this kind is in the targeting set, which the GetEntitiesAroundObject and
+      GetLookAtObject lines depend on.

package/knowledge/cyberpunk2077/redhottools.hotreload.yaml

@@ -199,10 +199,12 @@ facts:
       reload completed" after the trigger — see the archives read-back and
       hot-folder-moves-into-mods); the `.hot-tweaks` half is VERIFIED INEFFECTIVE — the sentinel is
       deleted/consumed but no TweakXL.Reload follows (see hot-tweaks-consumed-without-reload-1.3.0);
-      `.hot-scripts` is still untested. So "ModWright can drive all three" holds only for archives;
-      tweaks must go through TweakXL.Reload() via cp2077.lua.eval. RELATED:
-      cp2077.redhottools.hotreload.hot-folder-moves-into-mods (the archive half) and
-      cp2077.process.assetbuild.rht-hot-folder-banned-for-whole-mesh-archives.'
+      `.hot-scripts` drove real script reloads on 2026-09-13, but only seen fired together with a
+      second trigger, and that run ended in a crash (see
+      reloadscripts-recompiles-cleanly-storm-crash-1.3.0). So "ModWright can drive all three" holds
+      for archives; tweaks must go through TweakXL.Reload() via cp2077.lua.eval; scripts reload, but
+      one trigger at a time. RELATED: cp2077.redhottools.hotreload.hot-folder-moves-into-mods (the
+      archive half) and cp2077.process.assetbuild.rht-hot-folder-banned-for-whole-mesh-archives.'
   - id: cp2077.redhottools.hotreload.hot-tweaks-consumed-without-reload-1.3.0
     claim: "In Red Hot Tools 1.3.0.33690, dropping `red4ext/plugins/RedHotTools/.hot-tweaks` is consumed
       (RHT deletes the file) but does NOT drive a TweakXL reload: after an edited `r6/tweaks` file
@@ -243,3 +245,27 @@ facts:
       (src/core/deploy/reload.ts detectRedHotTools) now gates the RHT-dependent rows on the DLL +
       the watcher line instead. RHT 1.3.0 is installed and current while the README floors read
       2.21, so a floor check would have refused it."
+  - id: cp2077.redhottools.hotreload.reloadscripts-recompiles-cleanly-storm-crash-1.3.0
+    claim: "In Red Hot Tools 1.3.0.33690 a redscript hot reload recompiles and rebinds cleanly: RHT's
+      ScriptLoader logs Compiling, Reading blob, Validating, Capturing scriptable data, Binding,
+      Translating bytecode, Initializing runtime, Restoring scriptable data and \"Scripts reload
+      completed.\" with no compile or bind error. But with a save loaded, firing two script-reload
+      triggers at once (the `.hot-scripts` sentinel and the `RedHotTools.ReloadScripts()` facade,
+      called from CET Lua) produced about five full recompile-and-rebind cycles in 8 seconds, and
+      the game crashed to desktop just after the last one."
+    status: verified
+    verified_on: "2.31"
+    source: ModWright field verification
+    tags:
+      - redhottools
+      - hot-scripts
+      - reloadscripts
+      - hot-reload
+      - crash
+      - negative-result
+    detail: "Fire exactly one script-reload trigger. ModWright's reload apply writes only the
+      `.hot-scripts` sentinel for scripts. Still open: whether one clean reload with a save loaded
+      is stable, or whether script reloads belong at the main menu, since RHT rebinds every script
+      class over live gameplay objects. RELATED:
+      cp2077.redhottools.hotreload.triggers-are-sentinel-files and
+      cp2077.cet.sandbox.exec-func-vs-addmethod-reachability."