kronic/Project-M
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Netcode Bootstrap

Browse Source
This commit is contained in:
Luis Gonzalez
2026-05-31 14:27:52 -07:00
parent 99d8d2d2a9
commit 7fa77ce821
1813 changed files with 2921554 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Docs/Vault/07_Sessions/2026/2026-05-30_M1_Player_Slice.md
+50
View File
@@ -0,0 +1,50 @@
---
date: 2026-05-30
type: session
tags: [session, dots, netcode, m1]
permalink: gamevault/07-sessions/2026/2026-05-30-m1-player-slice
---
# Session 2026-05-30 — M1 Player Slice + foundation direction
## Goal
Kick off real dev via `/dots-dev`: lock the genre/foundation direction for a **V Rising × factory-automation co-op ARPG** (small team), plan the initial phases, and build **M1** — a server-spawned, owner-predicted player ghost that moves via twin-stick WASD + directional aim.
## Done
### Direction locked — see [[Pillars]]
- **Genre:** V Rising mechanics + action-ARPG combat (LoL / Diablo 4 / PoE2) + factory automation; small-team scope.
- **Control:** WASD movement, controller-first, **directional / twin-stick** aim (soft auto-target in-arc).
- **Multiplayer:** small co-op **2–4, client-hosted listen-server** (BinaryWorlds + in-proc IPC), PvE.
- **World:** persistent buildable **home base + instanced/procedural expeditions**.
- **Automation:** **progression accelerator** — self-running production chains; data model designed to grow toward full logistics.
- 6-phase roadmap M1–M6 — see [[Milestones]].
### M1 built — code-complete, EditMode-verified
All four asmdefs compile clean (source-gen OK); EditMode tests **3/3 green**.
- **Simulation:** `PlayerTag`, `PlayerInput` (IInputComponentData, `float2` Move/Aim `[GhostField]`, `ToFixedString`), `PlayerMoveStats`, `PlayerFacing` (`[GhostField]` Direction), `GoInGameRequest` (IRpcCommand), `PlayerSpawner`; `PlayerMoveSystem` + `PlayerAimSystem` (PredictedSimulationSystemGroup, `.WithAll<Simulate>()`, `SystemAPI.Time.DeltaTime` only — deterministic).
- **Client:** `GoInGameClientSystem`; `PlayerInputGatherSystem` (GhostInputSystemGroup, non-Burst ISystem reading the Input System).
- **Server:** `GoInGameServerSystem` (instantiate player + `GhostOwner` from `NetworkId` + `LinkedEntityGroup` auto-despawn).
- **Authoring/asset:** `PlayerAuthoring` / `PlayerSpawnerAuthoring` bakers; `Player.prefab` (GhostAuthoringComponent **OwnerPredicted**, HasOwner, AutoCommandTarget); `PlayerSpawner` wired into `Gameplay.unity`; `GameBootstrap.AutoConnectPort = 7979`.
- **Tests:** `PlayerMoveSystemTests` — deterministic advance + idempotence across tick batches.
- Live Netcode 6.6 API shapes verified via `unity_reflect` before coding (`GhostOwner.NetworkId`, `NetworkId.Value`, `Receive`/`SendRpcCommandRequest`, `GhostOwnerIsLocal`, `IInputComponentData.ToFixedString` → `FixedString512Bytes`).
### Build gotchas learned — now in repo `CLAUDE.md`
- Source-gen'd systems need **`Unity.Transforms`** as a *direct* asmdef reference (`LocalTransform`); transitive visibility doesn't satisfy the generator.
- Authoring asmdefs need **`Unity.Entities.Hybrid`** (for `Baker<T>`) and **`Unity.Collections`**.
- A component named **`PlayerInput`** collides with `UnityEngine.InputSystem.PlayerInput`; with `using UnityEngine.InputSystem;` the Entities generator binds `RefRW<PlayerInput>` to the *managed* class → misleading **CS8377** "must be unmanaged". Fix: fully-qualify Input System types, don't import the namespace.
- A nested baker class must not be named `Baker` (shadows `Unity.Entities.Baker<T>` → CS0308/CS0246).
## Decisions
- [[DR-002_Unity66_Alpha_Netcode_Transport]] — runtime netcode is blocked on the 6.6 alpha.
- **Host mode = BinaryWorlds + IPC** (stable), not the experimental `HostWorldMode.SingleWorld` (internal unless `NETCODE_EXPERIMENTAL_SINGLE_WORLD_HOST`).
- Correction to [[DR-001_Netcode_Test_Harness]] assumption: on the 6.6 upgrade, **Netcode (→6.6.0) and Physics (→6.5.0) DID renumber** into the editor line — they did **not** stay independent 1.x. `CLAUDE.md` updated.
## Open / deferred
- **BLOCKER — env-specific, NOT an engine bug (corrected 2026-05-31):** the in-editor connection never formed on Project M @ `6000.6.0a6` ("invalid wrapped network interface"). Initially mis-attributed to a Unity engine bug, but a **clean fresh `6000.6.0a6` project (`../Local Reference`, a full Netcode-for-Entities framework) connects fine**. The bare-scene repro still ran inside Project M's contaminated environment (embedded Entities-1.x `rukhanka` + in-place-upgrade `Library`/manifest residue + default driver/AutoConnect), so it isolated gameplay code but not the environment. Bug report withdrawn. See [[DR-002_Unity66_Alpha_Netcode_Transport]] → Correction.
- **RESOLVED 2026-05-31:** M1 runtime **fully validated on Unity 6.4.7 / Netcode 1.13.2** — connect → GoInGame → server-spawn → owner-predicted ghost → client replication all confirmed (`players=1`/`netIds=1`/`inGame=1`/`ownerLocal=1` in both worlds), no transport error. One-time fix: forced asset reimport to rebake the stale entity-subscene after the in-place downgrade. Minor follow-ups: enable `Application.runInBackground`; re-save URP global settings (cosmetic missing-types from the 17.6→17.4 downgrade).
- Deferred decisions (revisit at their phase): **relay provider** (default Unity Relay) before M3; home-base **grid 2D vs 3D** before M5; **production predicted vs server-only** before M6; **character controller** (custom kinematic vs vendor ECS-samples) at M4.
## Next
Re-run the M1 play-tick on a **stable Unity 6.x** (or reproduce with the `networked-cube` sample to file a bug). When green, proceed to **M2 — twin-stick combat / abilities**.
Docs/Vault/07_Sessions/_Decisions/DR-002_Unity66_Alpha_Netcode_Transport.md
+68
View File
@@ -0,0 +1,68 @@
---
id: DR-002
title: Unity 6.6.0-alpha Netcode/Transport runtime regression blocks in-editor play-tick
status: superseded
date: 2026-05-30
superseded: 2026-05-31 — see Correction below
tags:
- decision
- netcode
- transport
- engine
permalink: gamevault/07-sessions/decisions/dr-002-unity66-alpha-netcode-transport
---
# DR-002 — Unity 6.6.0-alpha Netcode/Transport runtime regression
> ⚠️ **SUPERSEDED 2026-05-31 — this was NOT a universal engine bug. See "## Correction" at the bottom.** A clean, fresh Unity `6000.6.0a6` project (`../Local Reference`) runs Netcode for Entities successfully. The failure was specific to **Project M's environment** (in-place 6.4→6.6 upgrade + embedded `com.rukhanka.animation` Entities-1.x package + default driver/AutoConnect path), not Unity itself. The drafted Unity bug report should **not** be filed.
## Context
The project runs on **Unity `6000.6.0a6`** (6.6.0 **alpha**) with `com.unity.netcode` 6.6.0, `com.unity.transport` 6.6.0, `com.unity.entities`/`collections`/`graphics` 6.5.0, `com.unity.physics` 6.5.0.
Building [[2026-05-30_M1_Player_Slice|M1]], the code compiled clean and EditMode tests passed (3/3), but the in-editor two-world play-tick **never establishes a network connection** (`NetworkId` connection count stays 0; no player ghost spawns). Every frame the console floods with exceptions located **entirely inside Unity packages**:
- `com.unity.transport`: `System.InvalidOperationException: Trying to access an invalid wrapped network interface.` (dominant, ~20×/sample)
- A cascade of Jobs-Debugger dependency-safety violations across Transport's internal layer jobs: `NetworkDriver:UpdateJob`, `SimpleConnectionLayer`, `SequenceReorderingLayer`, `AnalyticsLayer`, `BottomLayer`/`TopLayer`, `RpcSystem:RpcExecJob` ("you must include X as a dependency of the newly scheduled job").
- `com.unity.netcode`: "Server Tick Batching … falling behind its desired `SimulationTickRate`".
No `ProjectM.*` code appears in any stack trace. Reproduced across two clean play sessions. Disabling the Jobs Debugger (`JobsUtility.JobDebuggerEnabled = false`) removed the job-safety exceptions, but the **"invalid wrapped network interface"** persisted and the connection still never formed — so the root failure is Transport network-interface initialization, not the safety checks.
## Decision
Treat this as an **engine-alpha regression**, not an M1 code defect. M1 is **code-complete and statically verified**: clean compile + source-gen, EditMode determinism tests green, both `ServerWorld`/`ClientWorld` boot with correct flags. Runtime validation of the connect → spawn → predicted-move loop is **deferred to a stable Unity 6.x build**.
## Consequences
- Do **not** burn effort debugging Transport internals from game code; the fault is below our layer.
- Tracked action items: (1) re-run the M1 play-tick on a stable Unity 6.x; (2) optionally reproduce with Unity's own `networked-cube` sample to confirm + file a bug.
- Until resolved, treat in-editor netcode **runtime** on `6000.6.0a6` as unreliable; rely on plain-Entities EditMode tests (see [[DR-001_Netcode_Test_Harness]]) for deterministic logic coverage.
- **Recommendation:** for netcode runtime work, prefer a **stable** Unity 6.x release over the alpha.
## Confirmation — clean-room repro (2026-05-30)
Reproduced with **zero Project M code**: a fresh empty scene (camera + light only — no Gameplay subscene, no ghosts/components/systems) where Unity's canonical bootstrap creates `ServerWorld` + `ClientWorld` and auto-connects. The identical `Trying to access an invalid wrapped network interface` flood appears; `ClientWorld` opens a `NetworkStreamConnection` but the server never accepts and **no `NetworkId` is assigned** on either side. ⇒ the fault is entirely in Unity Transport/Netcode, not our gameplay or bootstrap logic.
## Web corroboration
- Netcode for Entities + Unity Transport are **mid-migration to built-in (Core) packages bundled with the Editor, since Unity `6000.5.0a7`** — which is why they renumbered into the 6.x line on our upgrade. ([status update](https://discussions.unity.com/t/netcode-for-entities-and-unity-transport-status-update/1707400))
- The netcode↔transport pipeline was **actively reworked this alpha cycle**: the `6000.6.0a5` changelog states "Netcode for Entities snapshots now use Unity Transport's unreliable sequenced pipeline instead of a home-baked solution." That unreliable-sequenced / `SequenceReorderingLayer` path is exactly what throws in our logs.
- Transport's `NetworkDriver.Concurrent` multi-job safety behaviour has acknowledged rough edges (Unity Transport maintainer, Jan 2026, Transport 2.6 / Unity 6.3) with no fix. ([thread](https://discussions.unity.com/t/using-the-same-networkdriver-concurrent-in-two-jobs-causes-an-error/1703439))
- **No public report matches the exact `invalid wrapped network interface` connection-blocking failure on `6000.6.0a6`** — consistent with an unreported in-flight alpha regression. Worth **filing a Unity bug** with the minimal bare-scene repro above.
## Resolution (2026-05-30)
**Reverting the project to Unity 6.4.7** (Netcode for Entities 1.13.2 / Transport 2.7.2 — the known-good baseline) to unblock runtime netcode. A file-ready bug report was drafted at `Docs/UnityBugReport-Netcode-Transport-6.6.0a6.md`. Next: re-validate the M1 connect→spawn→predicted-move loop on 6.4 (the M1 code should port with no/minimal changes — recompile + `read_console`). Revisit Unity 6.6 once the Transport regression is fixed in a later alpha/beta.
## Correction (2026-05-31)
The "confirmed engine bug" conclusion above is **withdrawn**. A side-by-side file diff against a fresh project (`Projects/Rain/Games/Unity/Local Reference`) showed:
- **`Local Reference` is a clean Unity `6000.6.0a6` Netcode-for-Entities framework project** (dedicated-server bootstraps, GhostBridge ghost framework, prediction, **its own custom `EntityDriverConstructor`** + explicit connect flow) — and it runs netcode successfully on the same alpha.
- **Project M @ 6.6 differed in three ways the template does not have:** (1) an embedded third-party **`com.rukhanka.animation` 2.9.0** built for **Unity 2022.3 / Entities 1.x** (depends on `entities.graphics 1.4.16`); (2) it was **upgraded in-place 6.4→6.6** (stale `Library/` + leftover/mixed `manifest.json` pins); (3) it used the **default `IPCAndSocketDriverConstructor` + `AutoConnectPort`**, whereas the template uses a custom driver constructor.
**Why my repro misled me:** the "bare scene" repro still ran inside Project M's contaminated environment (rukhanka + dirty `Library` load regardless of scene), so it isolated *gameplay code* but not the *project environment*. The correct control — a clean 6.6 project — works.
**Revised stance:** environment-specific, not an engine bug. **Do not file the Unity bug.** Candidate causes (unranked, not yet isolated): stale upgrade `Library`, the Entities-1.x `rukhanka` package, the default-driver/AutoConnect path, manifest-pin inconsistency. **To run on 6.6:** clean a 6.6 Project M (remove/replace rukhanka, delete `Library/` + reimport, reconcile manifest pins) and re-test. Project M is currently on **6.4.7** (stable baseline) where M1 should run regardless.
**Confirmed 2026-05-31:** M1 runtime **works on Unity 6.4.7** — the full connect → GoInGame → server-spawn → owner-predicted ghost → client replication loop validated (1 player ghost in both worlds, no transport error). This + the working clean 6.6 template settles it: the 6.6 failure was **environment-specific**, not an engine bug. (Note: the in-place 6.6→6.4.7 downgrade left a stale entity-subscene cache that hung the first play-mode entry until a forced reimport rebaked it — the same in-place-version-change dirtiness lesson.)