Spawned gameplay objects are never wired into the level bus (flags don't capture, spawners don't spawn)

[Powback]

Full analysis committed as docs/entity-wiring-and-networking.md on live-ebx. This issue tracks the three High-severity gaps from it; G4-G11 are in the doc.

Findings are grounded in the Venice-EBX dumps, with verified vs inferred kept separate in the doc.

---

G1 — Level-bus connections are never authored (the headline)

Frostbite splits gameplay wiring in two:

• Inside the prefab — CapturePointPrefab carries an InterfaceDescriptorData exposing CaptureRadius, OnCaptured/OnLost etc., plus internal PropertyConnections. This ships in the blueprint, so CreateEntitiesFromBlueprint rebuilds it for free.
• In the level/subworld bus — the connections that make a flag a Conquest flag. Levels/MP_001/Conquest.txt (SubWorldData 539342BE-…) holds 49 PropertyConnections + 17+ EventConnections referencing the flag RODs (CQ_logic/8C5AF081-…, CQ_logic_US/10A70CA7-…). MP_001.txt (LevelData) has more, cross-partition into the world parts.

MapEditor only ever creates the object: LevelInjector:CreateWorldParts builds a WorldPartData() with only objects populated (no propertyConnections/linkConnections/eventConnections/descriptor), and InvokeBlueprintSpawn wires the new bus into nothing.

Result: spawn a CapturePointPrefab / vehicle spawner / MCOM and it renders, its internal wiring works, and the game mode never sees it. Flags never capture, spawners never spawn, MCOMs never arm. Note this is not addressed by parentRepresentative (#202) — that makes per-instance data unique, it doesn't wire anything into the level bus.

Also relevant: the networking realm of an event is carried on the connection (EventConnectionTargetType: Client / Server / NetworkedClient / …), not on the object.

G2 — Editing a networked object desyncs it

Any EBX edit re-instantiates via InvokeBlueprintSpawnFromClone, which hardcodes networked = false and runs client-only. CapturePointPrefab is NeedNetworkId True (verified). So the client ends up rendering a local non-networked copy while the server still owns the real entity.

networked can't simply be restored: the clone DC isn't registered in ResourceManager, so a networked spawn hands the peer an unresolvable blueprint guid and crashes it — which is exactly why it's false. Options: (a) keep client-only preview and re-sync authoritatively on save, (b) register the clone so peers can resolve it, (c) skip re-instantiation for needNetworkId objects and fall back to Disable/Enable. Needs a design decision.

G3 — Entity buses leak on every edit

GameObject:Destroy calls Disable() on its entities; GameEntity:Destroy has zero callers. Every (debounced) re-instantiation therefore abandons an entity bus.

Constraint that must survive any fix: destroying a vanilla entity crashes the game. That is why the code disables rather than destroys. It is also subtler than it looks — a vanilla object is re-registered as Custom after its first EBX edit, so from then on its entities descend from level data. A fix has to destroy only entities we created via CreateEntitiesFromBlueprint, e.g. by tagging them in the create hook. See §4.1 of the doc.

---

Useful adjacent finding: the field-id hash -> name table needed to make connections human-readable (838548383 -> Geometry, 2099208964 -> OnCaptured) is already shipped in data.zip as EventHashes.json and simply discarded at load — see #388.

[Powback]

G3 progress — groundwork landed (98ce724), leak NOT fixed. Recording the negative result so it isn't rediscovered.

Approach taken: tag entities the editor creates (GameEntity.isEditorSpawned, set from the pending-spawn info in the EntityFactory:CreateFromBlueprint hook) and destroy only those, keeping Disable() for everything else — because destroying an entity that came with the level crashes the game.

Measured result: every re-instantiation reports destroyed=0 disabled=N. The tagging never matches.

Reason: the entities attached to respawned objects are not created through the blueprint hook at all. They come from GameObjectManager:OnEntityCreate, the generic EntityFactory:Create hook, which fires for every entity the engine creates — including all vanilla level geometry — and carries no indication of who requested it. Tagging there would destroy vanilla entities, i.e. exactly the crash the current design avoids.

Remaining work: attribute entities created via the generic hook. The obvious candidate is to mark the manager while our own CreateEntitiesFromBlueprint call is in flight (set an owning guid before the call, clear it after) and treat entities created inside that window as ours. That needs verification that entity creation is synchronous within the call before anything is destroyed on the strength of it.

Landed anyway because it is safe and independently useful:

• GameEntity:Destroy now also clears m_ProcessedEntities. That table was append-only and the create hook skips any instanceId it has already seen, so once entities are genuinely destroyed a recycled id would make the hook silently drop the new entity — an object that renders but cannot be selected. Real latent bug, fixed regardless.
• The destroy path is pcall-guarded with a Disable() fallback.

Also worth flagging for whoever continues: the e2e entity assertion added alongside this is weak by construction — spatialGameEntities is the WebUI's own map, which refreshRespawnedGameObject already rebalances, so it reads as stable whether or not the ext leaks. A meaningful assertion needs ext-side entity/bus counting.

[Powback]

G3 fixed (995f17e). Following up on the negative result above.

The missing piece was attribution. Entities on respawned objects come from the generic EntityFactory:Create hook, which fires for every entity in the level and carries no indication of who requested it — so tagging in the hook alone could never work.

Fix: an explicit ownership window. GameObjectManager.m_SpawningForGuid is set around our own CreateEntitiesFromBlueprint calls (normal spawn and per-instance clone respawn), and the generic hook marks anything created inside that window as isEditorSpawned. Everything the level creates on its own falls outside the window, stays untagged, and keeps the Disable()-only path — so the constraint that destroying a vanilla entity crashes the game is preserved by construction rather than by a type check.

The normal spawn path's CreateEntitiesFromBlueprint is now pcall-wrapped as well, so a throw can't leave the window stuck open and mis-attribute every subsequent entity as ours.

Measured before vs after, with counters in GameObject:Destroy:

	before	after
WallLamp_01_MP001 (prefab)	destroyed=0 disabled=4	destroyed=4 disabled=0
WallLamp_01	destroyed=0 disabled=1	destroyed=1 disabled=0
ACUnit_01	destroyed=0 disabled=2	destroyed=2 disabled=0

Server stayed up throughout (destroying for real was the risk here), and the full e2e suite is 8/8.

Worth noting why this is safe for vanilla: DeleteGameObject sends vanilla/NoHavok objects to MarkAsDeleted, and GameObject:Destroy refuses them outright, so vanilla entities never reach this code. Only after an object has been re-instantiated once — which re-registers it as Custom — do its entities become ours to free, and by then they were created by our own respawn.

[Powback]

G2 fixed properly (9bd7e93). Live preview and networking, rather than trading one for the other.

Root cause was narrower than stated earlier in this thread. It is not that runtime DataContainers can't be replicated — it's that DeepClone was handed GenerateGuid(), which is random. Each realm therefore minted a clone under a different instance guid, so whatever one side replicated the other had never heard of. That is the whole reason networked = false was forced.

Fix, in two steps:

1. 913c5e9 — re-instantiate on both realms instead of client-only, so the client stops previewing a change the server never applied. Verified the server survives spawning from a clone; the original crash was the networked spawn, not the server-side spawn.
2. 9bd7e93 — derive the clone guid deterministically from the editor guid (identical on both realms) instead of GenerateGuid(). Both sides now hold their clone under the same guid, so InvokeBlueprintSpawnFromClone honours the blueprint's needNetworkId again.

Verified: server and client both survive the spawn that previously crashed; full e2e suite 8/8.

Not verified, stated plainly: the networked == true branch itself is not proven by that run. The e2e targets are lamps, almost certainly needNetworkId = false. Editing a CapturePointPrefab (confirmed NeedNetworkId True in the Venice-EBX dumps) would exercise it for real. Worth doing before treating G2 as fully closed.

Remaining known limitation in this area: on the server realm entities have no Destroy method (attempt to call a nil value), so G3's entity freeing is client-side only and falls back to Disable() on the server. The pcall guard means it degrades rather than crashes, but the server-side bus leak persists.

Status of this issue: G2 ✅, G3 ✅ (client-side), G1 still open — the level-bus wiring is untouched and remains the reason spawned gameplay objects do nothing.

[Powback]

Correction to G1's severity, from a real observation: spawned vehicle spawners do work. So "spawn a gameplay object and nothing happens" is too broad — it depends on whether the object's behaviour is intrinsic or externally wired.

• Intrinsic — a VehicleSpawnReferenceObjectData spawns vehicles because that is what the entity itself does. Nothing external has to tell it. It works when spawned, as observed. Consistent with the EBX data: it carries isEventConnectionTarget = 2 (ClientAndServer) where plain props are 3 (None) — it is built to participate on its own.
• Externally wired — a capture point prefab has no idea it is a Conquest flag. That meaning lives entirely in the level/subworld bus (Conquest.txt: 49 PropertyConnections + 17+ EventConnections pointing at the flag RODs). Spawn one and the game mode never sees it.

So G1 should be read as: objects whose behaviour comes from level-bus connections don't function when spawned — capture points, MCOMs, anything driven by gamemode logic — while self-contained entities are fine. That also narrows the fix: the connection-authoring work only matters for the wired class, which makes "duplicate-with-wiring" (clone the level-bus connections whose Source/Target is the original ROD and repoint them at the copy) a more attractive first slice than a general connection editor.

docs/entity-wiring-and-networking.md will be updated to reflect this rather than leaving the blanket claim.

[Powback]

Correcting my own correction. The working case was spawning a VehicleBlueprint directly — i.e. an actual vehicle entity, which is trivially intrinsic. It was not a VehicleSpawnReferenceObjectData.

So the spawn point is still unproven, and it sits squarely in the externally-wired class. The intrinsic/wired split in the doc stands as a distinction, but VehicleSpawnReferenceObjectData should be treated as unverified, not as evidence that wired objects work. Sorry for the noise — I generalised from one report without checking which object was actually spawned.

[Powback]

G1 feasibility probe (runtime, not dumps). The level bus is readable live through the existing PartitionSerializer path — no new transport needed.

Fetched Levels/MP_001/Conquest_Large (0CB74E25-485C-4F9F-8CB4-00808FB6F478) at runtime over MapEditor:RequestPartitionData: 371KB, 7 instances — SubWorldData, InterfaceDescriptorData, RegistryContainer, 4× WorldPartReferenceObjectData. The SubWorldData carries PropertyConnections, EventConnections, LinkConnections and Descriptor exactly as the doc describes.

Two practical notes for whoever implements this:

• Field names are PascalCase in the serialized form (PropertyConnections, not propertyConnections), and connection arrays serialize as {$value, $array, $type} rather than a bare JS array — a naive Array.isArray scan finds nothing and looks like "there are no connections".
• Match the running gamemode. The doc cites Levels/MP_001/Conquest, but a server on ConquestLarge0 loads Conquest_Large; requesting the wrong one returns "Partition not loaded on server", which reads as a serializer failure rather than a wrong-subworld mistake.

Scope interaction with #394 worth deciding before implementing: the externally-wired class this issue targets (capture points, gamemode logic under Gameplay/Level_Setups/) is now placed as placeholders — deliberately never instantiated, because instantiating them kills the client (#393). Those objects have no entity bus at runtime, so there is nothing to wire live. Until #393 is solved, G1's realistic deliverable is wiring carried in the save (clone the level-bus connections that reference the source object, repointed at the copy) so the baked level contains it — not live capture behaviour in the editor.