[Bug] Spawning a CapturePointPrefab poisons the server: every subsequent client join dies

[Powback]

Reproduced twice on live-ebx. Severity is higher than it first looks: one bad spawn breaks the session for everyone who joins afterwards, and it presents as an unrelated join failure long after the spawn.

Repro

1. Join, enter the editor.
2. Spawn Gameplay/Level_Setups/Components/CapturePointPrefab_HQ (from the blueprint list). The spawn itself appears to succeed; the server stays up.
3. The spawning client dies shortly after.
4. Restart/relaunch the client and join again — it connects, then dies ~23 s later, before reaching the editor. It never gets far enough to spawn anything.
5. Restart the server → clients join fine again and the full e2e suite is 8/8.

So the object persists in the server's state and takes down every client that subsequently receives it.

Notes

• No crash dump is written, and there is no Lua traceback — the client just goes away.
• The server is unaffected throughout.
• Other spawns tested do NOT do this: nongroupable_autogen prefabs, a destruction/nongroupable prefab (×3), a banger blueprint (×2), and SoldierWeaponBlueprint.
• CapturePointPrefab is a SpatialPrefabBlueprint with NeedNetworkId True and InterfaceHasConnections True, referencing a graph of other blueprints — unlike the simple props above.

Hypothesis (initialisation ordering)

The live-spawn path and the join-sync path are not equivalent:

• Live spawn — the level is loaded and InstanceParser has populated its blueprint / variation / mesh-variation databases, so CreateEntitiesFromBlueprint runs against fully-initialised state.
• Join sync — the server replays its objects to a newly connected client, and those spawns can arrive before the client has finished initialising what those blueprints depend on (variations, referenced sub-blueprints, registries). A prefab that references a graph of other blueprints is exactly what would fault under that.

This is the same class of problem the project-load path already handles with completion-gated batching (ME_CONFIG.LOAD_BATCH_SIZE, ServerTransactionManager waiting for BatchDone), but the join-sync path for objects spawned during a session has no equivalent gate.

Worth checking: ServerTransactionManager sync-to-new-client, ClientTransactionManager:OnSyncClientContext, and whether that replay waits for Level:Loaded / InstanceParser readiness on the joining client.

Related

Very likely the same family as #296 / #364 / #2 ("spawning certain prefabs crashes the client"). Note parentRepresentative (#202) is implemented on this branch and does not prevent it.

Warning while debugging

Any such spawn persists server-side, so the next join fails and looks like an unrelated regression. Restart the server between attempts.

[Powback]

Hypothesis confirmed structurally — the join-sync path is ungated, while the project-load path is.

ServerTransactionManager (~:126-152): a joining client reports transactionId = 0, so the server walks every transaction, builds one s_UpdatedGameObjectTransferDatas table, and sends it in a single SyncClientContext NetEvent. The client's OnSyncClientContext → SyncClientTransferDatas then spawns the lot in one go. No batching, no acknowledgement, no wait for the client to be ready.

Contrast with project loading, which the codebase already protects (ME_CONFIG.LOAD_BATCH_SIZE = 500, server waits for ClientTransactionManager:BatchDone before releasing the next batch, with a safety timer). Its own comment says this is completion-gated specifically because overlapping batches "crashed the client".

Same hazard, protection applied to only one of the two paths.

That also explains why this reproduces with CapturePointPrefab_HQ and not with simple props: it's a SpatialPrefabBlueprint referencing a graph of other blueprints, so it's both heavier to construct and more dependent on the client having finished initialising blueprint/variation data — exactly what an ungated dump immediately after connect won't have waited for.

Suggested fix: route the join sync through the same completion-gated batching used for project loads, rather than sending one unbounded payload — i.e. reuse the m_LoadingInProgress / LOAD_BATCH_SIZE / BatchDone machinery for the transactionId == 0 case. A readiness gate (don't start until the joining client reports level/InstanceParser ready) is likely needed on top, since batching alone only fixes volume, not ordering.

Both are worth testing separately: batching may be sufficient if the failure is volume/timing, whereas if a single CapturePointPrefab alone kills a freshly-joined client then it's an ordering/initialisation problem and the gate is the real fix. The repro in the issue body distinguishes them — the poisoned server had one such object, which points at ordering rather than volume.

[Powback]

Trap for whoever implements this — the obvious minimal fix is unsafe.

The tempting small change is: on join (transactionId == 0), answer with only the first N transactions instead of all of them, and let the client ask for the rest. That would strand the client half-synced.

ClientTransactionManager only sends RequestSync from the command-handling path, when it detects a transaction-id mismatch:

if self.m_LastTransactionId + #s_Commands ~= p_TransactionId then
    m_Logger:Warning('Client is not synced, requesting sync')
    NetEvents:SendLocal('ClientTransactionManager:RequestSync', self.m_LastTransactionId)
    return
end

There is no "keep pulling until caught up" loop. A client that receives a deliberately partial sync has no mismatch to detect and simply stops, permanently missing the remaining objects — silently, and for every joining player, which is a worse failure than the current bug (which only triggers after a specific prefab is spawned).

So the fix has to be one of:

1. Server-driven batching — push the join sync through the same completion-gated handshake the project-load path uses (LOAD_BATCH_SIZE + waiting on ClientTransactionManager:BatchDone, with the existing safety timer). The server keeps sending, so it doesn't depend on the client re-asking.
2. Client-side catch-up — have the client continue requesting until its transaction id matches the server's, then partial responses become safe.

(1) reuses machinery that already exists and is proven on the load path, so it's the lower-risk option.

Either way, verify against the repro in the issue body — and note the distinction raised earlier: the poisoned server held exactly one object, which suggests ordering/initialisation rather than volume. If a single CapturePointPrefab kills a freshly joined client, batching alone will not fix it and a readiness gate is the actual fix. Test both hypotheses separately rather than assuming batching is sufficient.

[Powback]

Good news — the machinery is already in place; option (1) needs no new protocol.

ClientTransactionManager:SyncClientTransferDatas doesn't apply the transfer datas directly — it converts them into commands (SpawnGameObjectCommand / DeleteGameObjectCommand) and feeds them through the normal command queue, which already sends ClientTransactionManager:BatchDone back to the server (ClientTransactionManager.lua:292). The queue is also already throttled per tick by QUEUE_MAX_COMMANDS.

So the client side is fine as-is. The only unbounded step is on the server: the transactionId == 0 branch builds one table containing every transaction and ships it in a single SyncClientContext NetEvent.

That makes the fix narrow and low-risk:

• Chunk the join sync in ServerTransactionManager at LOAD_BATCH_SIZE, reusing the existing m_WaitingForBatchAck / m_BatchAckSafety gate that the project-load path already uses.
• No client change required — it already acks, and the earlier "partial sync strands the client" trap does not apply, because the server keeps sending rather than relying on the client to re-ask.

Still worth testing both hypotheses (volume vs ordering) against the repro, since the poisoned server held a single object — but if ordering turns out to matter too, the readiness gate can sit on the same code path.

[Powback]

Reproduced cleanly, and the earlier framing was wrong — this is NOT primarily a join-sync problem.

Spawning Gameplay/Level_Setups/Components/CapturePointPrefab_HQ kills the spawning client within seconds. The server is unaffected. The join deaths reported above are a secondary effect: the object persists server-side, so every later joiner receives it, spawns it, and hits the same thing.

So the batching/ordering theory for the join path is a red herring for this bug (the poisoned server held exactly one object). The join path may still deserve gating on its own merits, but it is not the cause here.

Actual signature (client log, immediately before death, repeated many times):

[WebUI] Tried to set visibility of an entity that hasn't been registered in InstanceManager
  at ri.setOverride        (app.js)
  at Or.onSetEBXField      (app.js)
  at Ya.HandleResponse     (app.js)

No crash dump is written — this is not a native crash. It is a WebUI-side error flooding until the Gameface app wedges, which is why it looks like a hang/disappearance rather than a crash.

Prime suspect is WebUI-side entity bookkeeping, specifically Editor.refreshRespawnedGameObject (added on live-ebx when respawns were made to update in place instead of erroring as duplicates). It calls SpatialGameEntity.Delete(), which unregisters the instance from InstanceManager, and then re-selects the object. Anything still holding a reference to a deleted SpatialGameEntity will call SetVisibility on an unregistered instance and produce exactly this error — and a prefab with many entities multiplies it into a flood.

Worth checking in that area:

• stale SpatialGameEntity references surviving in editor.spatialGameEntities, in the THREE scene graph, or in the selection group after Delete()
• onSelect/onHighlight recursing over children that were already deleted
• whether InstanceManager.SetVisibility should no-op with a warning instead of erroring per call (it should not be able to flood the log regardless of the root cause)

That last point is worth doing on its own: a single bookkeeping mistake should not be able to take the client down through log volume.

[Powback]

Correction: the visibility spam was a symptom, not the cause. This is a native fault.

Hardened InstanceManager (261cdf1) so a freed instance can no longer flood the log or write out of bounds — then re-ran the repro on a clean server.

The client still dies ~3 s after spawning CapturePointPrefab_HQ. With the JS spam silenced there is now no error at all: the client log simply stops after the editor's normal startup lines, and no crash dump is written. Nothing in Lua, nothing in JS.

That rules out the earlier theories in this thread:

• not the join-sync path (the spawning client dies)
• not volume/batching (a single object)
• not the SetVisibility flood (silenced; still dies)

A silent stop with no dump and no Lua traceback is a native fault during entity creation — which matches how #296 / #364 / #2 were originally described. So this issue is very likely a true reproduction of that long-standing crash family, now with a deterministic one-line repro:

editor.SpawnBlueprint(<Gameplay/Level_Setups/Components/CapturePointPrefab_HQ>)

Also worth recording: parentRepresentative (#202) is implemented on this branch and does not prevent it, so that hypothesis for the crash family can be set aside.

Next avenues, in the order I'd try them:

1. Narrow which blueprint type triggers it — CapturePointPrefab_HQ is a SpatialPrefabBlueprint with needNetworkId = true and interfaceHasConnections = true, referencing a graph of other blueprints. Test a SpatialPrefabBlueprint without connections, and a LogicPrefabBlueprint, to isolate which property matters.
2. Try it with networked = false forced on the spawn params — if that stops it, the fault is in replication rather than construction.
3. Bisect the entity-creation path itself (representative on/off, variation hash on/off), since there is no Lua error to guide it.

The InstanceManager hardening in 261cdf1 is worth keeping regardless: SetColor/SetMatrixFromSpatialEntity were indexing the instanced mesh with -1 (writing outside the buffer), and SetVisibility combined a per-call console.error with an O(n) scan over ~7.7k entities.

[Powback]

Root cause narrowed to entity-bus construction — not replication, not prefab type.

Three controlled tests on fresh sessions (server restarted between each, since a spawned object poisons the session):

Spawn	Result
Plain SpatialPrefabBlueprint (Me_Storefront…, no gameplay logic)	✅ survives — 24 s, object count stable
CapturePointPrefab_HQ (networked = needNetworkId, i.e. true)	❌ dies ~3 s
CapturePointPrefab_HQ with EntityCreationParams.networked forced false	❌ dies ~3 s

So:

• Not the prefab type — an ordinary SpatialPrefabBlueprint spawns fine.
• Not replication / network ids — forcing non-networked changes nothing.
• It is construction of the entity bus itself.

The remaining differentiator between the two prefabs is interfaceHasConnections = true: CapturePointPrefab carries an InterfaceDescriptorData (B5571DDE-…, exposing CaptureRadius, OnCaptured/OnLost, …) plus internal Property/Link connections, where the storefront prefab has none. Building a bus whose interface has connections, at runtime via CreateEntitiesFromBlueprint, appears to fault natively — no Lua error, no JS error, no crash dump; the client log simply stops.

Suggested next test (one cycle each, and it should isolate it completely): spawn another blueprint with interfaceHasConnections = true but without needNetworkId — if that also dies, connections are confirmed as the trigger independent of everything else. LogicPrefabBlueprints are good candidates.

This also ties directly into #391 / docs/entity-wiring-and-networking.md: connections are the part of the data model MapEditor never authors, and they now look like the reason this whole class of prefab cannot be spawned at all — not merely "spawns but doesn't function".

The networked = false change used above was a temporary probe and has been reverted; the tree is clean.

[Powback]

Two updates: a further narrowing, and a requirements change that makes this much more tractable.

Narrowing

LogicPrefabBlueprint survives (24 s, count stable). So the trigger is narrower than "the blueprint has interface connections".

Test matrix so far, each on a fresh session:

Spawn	Result
SpatialPrefabBlueprint (Storefront, no logic)	✅ survives
LogicPrefabBlueprint	✅ survives
CapturePointPrefab_HQ, networked	❌ dies ~3 s
CapturePointPrefab_HQ, forced non-networked	❌ dies ~3 s

So it is not prefab type, not replication, and not merely the presence of connections. Something more specific to CapturePointPrefab — a spatial prefab that also carries an interface descriptor with connections into gameplay logic, and whose children include capture-area/logic entities.

The requirement is smaller than "make it work"

These objects do not need to function live in the editor. They need to be placeable, visible and saveable, so the level loader can wire them up at generation time (RMLevelLoaderGen-style). Live capture behaviour is not the goal.

That changes the target completely. Instead of constructing the real entity bus at runtime — which is what faults — the editor could:

1. Not construct the gameplay entity at all. Detect the crash-prone class and spawn a placeholder (a marker/ghost, per Logic/reference objects (vehicle spawns, capture points, triggers) are invisible in the editor #392) that carries the real blueprintCtrRef, transform, variation and overrides.
2. Save the real reference. GameObjectSaveData already persists blueprintCtrRef + transform, so the level loader emits the genuine prefab even though the editor never instantiated it.
3. Optionally render a translucent preview so placement is meaningful.

That sidesteps the native fault entirely rather than trying to fix engine-side entity construction, and it delivers what is actually needed: place a capture point, save it, have the generated level contain a working one.

Open question for the placeholder approach: how to decide which blueprints take it. Options: a type/name blacklist, a probe-and-remember (spawn once, if the client dies mark it), or driven by the blueprint carrying an InterfaceDescriptorData with connections. The last is the most principled and matches the evidence, but LogicPrefabBlueprint surviving shows it would over-match, so it needs refining against more samples.

This likely supersedes trying to "fix" the crash directly.

[Powback]

Worked around, not fixed. #394 landed in e0b27c0: blueprints under Gameplay/Level_Setups/ are no longer handed to CreateEntitiesFromBlueprint at all — they are placed as markers carrying the real blueprint reference, so the crash is unreachable through normal editor use (spawn and drag-preview both verified to leave the client up).

The underlying native fault is untouched and this issue should stay open. Anything that instantiates one of these prefabs by another route will still die the same way, and the diagnosis stands: it is neither prefab type nor replication (plain SpatialPrefabBlueprint fine, LogicPrefabBlueprint fine, CapturePointPrefab dies networked and non-networked), and a spawn attempt still poisons the server for subsequent joiners — restart the server between attempts when investigating.

The placeholder list in GameObjectManager is the practical mitigation surface: if another blueprint family turns out to fault the same way, adding its path prefix there sidesteps it immediately.