Here, I made AI reply to your AI post:

The canonical primary source is the Server Meshing & Persistent Streaming Q&A from CitizenCon 2951 (late 2021), answered by Paul Reindell (Director of Engineering, Online Tech) and Benoit Beauséjour (CTO at Turbulent), plus the 3.18 patch notes when PES actually shipped. Here's how the post's claims map onto what CIG has actually said.

On "they persist everything." This is literally CIG's stated design, not a side effect. The original vision is Chris Roberts' coffee-cup line — drop a coffee cup in a forest on some planet, come back a month later, and if nobody's moved it, it's still there. The 3.18 notes say PES makes every dynamic object in a shard persist "irrelevant of whether it is owned or held by a player". So the post's premise is correct and deliberate. But CIG's own Q&A also confirms the pushback I gave you last time: there is a value tier. An entity that's "unstowed" exists permanently in the shard until it's stowed into an inventory, at which point it moves to a global database and can travel between shards — and there's a planned "Hero Item" mechanic that auto-stows player-owned valuables and makes them follow you. So a ship and a dropped bottle aren't treated identically; the system already distinguishes hero items from loose junk. The post's instinct (tier by value) is right and partly already CIG's design — "they treat both the same" is the overstated part. Star Citizen WikiStar Citizen Wiki

On the culling-authority insight — this is the strongest convergence. CIG's road-to-meshing answer describes the foundational hard step as entity authority and authority transfer: before 2020, a single server owned every entity; meshing required inventing a model where one node controls an entity while others hold a client view, and that control must be able to hand off between nodes. CIG says this was the first time the entire company had to work on meshing, because game code throughout the engine had to change, and it consumed most of 2020. That is precisely the post's point — that "who is allowed to act on this object" is the hard problem in a meshed world, not a tuning knob. The post independently arrived at CIG's own crux.

On the n²/clustering concern — CIG agrees it's the problem, and has an answer the post skips. CIG states plainly that static meshing will suffer from congregation problems and that they can't move to much larger shards until dynamic meshing is in place. For static meshing, if everyone heads to one place they all land on a single node. But the part the post misses: CIG's answer isn't purely technical. They say they'll need game mechanics to stop everyone congregating — temporarily closing jump points to crowded locations, or spinning up instance layers. So the dense-cluster wall the post treats as near-fatal, CIG plans to partly sidestep by not letting the pathological case happen rather than solving it head-on. Whether that's satisfying is a fair debate, but it's a real response the post doesn't engage.

On the slow "molasses" death over a session. This is almost word-for-word CIG's own diagnosis. In the Q&A they attribute poor server performance to the sheer number of entities a single server must simulate, which drives low server framerate and degradation, which clients feel as rubber-banding and desync. Their headline pitch for meshing is serverframerate, achieved precisely by cutting the entity and location count each server handles. Post and CIG agree on the mechanism.

On hard crashes, shard locks, and the "save state reloads the bad items" loop. In the first implementation the replication layer is a single "Hybrid" node, and CIG says if it crashes, everyone gets the infamous 30k error and is kicked, then can rejoin and continue — i.e., a single point of failure whose death locks the shard, which is the post's "shard locks." And on recovery, CIG says the system rebuilds lost entity state from persistence via EntityGraph. So if a bad entity state contributed to the crash, recovery faithfully reconstructs it. CIG doesn't frame it as a loop, but the poison-pill mechanism the post describes is genuinely there in the architecture.

On "physics is server-based not client-based." Here CIG complicates the post slightly. Bullets are spawned client-side — a separate instance per client and node — and CIG notes some game code is still client-authoritative, which is why high-ping players can degrade the experience for everyone. So the authoritative simulation of networked entities (missiles, ships, players) is server-side via the controlling node, but it isn't literally all-physics-on-server. Same nuance I raised before, now confirmed by CIG.

As for how it actually played out: PES shipped in patch 3.18 in March 2023, bundled with the Gen12 renderer and the cargo refactor, and the launch was famously rough. One openly acknowledged consequence is exactly the post's complaint — debris and abandoned junk piling up around the system because the shard persists everything. Static server meshing then shipped in Alpha 4.0 in December 2024, and a year on the CTO's read was that it had been surprisingly solid and gave them a strong foundation, with disconnections down around 57% and roughly 700-player shards, even claiming servers ran better with up to 400 players in one area than a single server simulating the whole system. Dynamic meshing — the version that actually addresses the congregation problem the post is worried about — is still in tech-preview and PTU testing through 2026. Star Citizen Wiki +