Physiks MP Player DataSync Optimizer B42 – 【Project Zomboid】

🧩 Physiks Player & DataSync Optimizer B42 [Version 2.2]
Multiplayer sync infrastructure, rebuilt for Build 42 — for every MP server, any size.

If you’ve played Project Zomboid multiplayer, you already know the symptoms: players rubber-banding into position, crouch animations that just don’t register, cars full of passengers that jitter and snap. These aren’t just “big server” problems — they show up in a 4-player co-op game just as easily as a full public server. This mod exists to solve that at the source — not by patching symptoms, but by rebuilding how player state actually moves across the network. Below is the full breakdown of every system in this mod and exactly how it works — no hand-waving, real numbers.

⚡ At a Glance

🗜️ Custom bit-packed sync engine — every player update compressed by a purpose-built binary packer
🚗 Vehicle-aware — automatically steps aside for players in cars so it never fights B42’s own vehicle physics
📊 Live Analytics & Real-Time Tuning — a companion admin panel showing exactly what your server is doing, tunable with zero downtime
👥 Works on any server size — helps a 4-player co-op game just as much as a full server, with defaults informed by real 30-32 player testing
🔧 Actively maintained — rebuilt against B42’s current API and kept current as the build evolves

[hr][/hr]

🎯 System 1: Update Tiering & Population Throttling
Every player’s own state gets sent on one of two cadences:

Near tier: every 0.1s (~10 updates/sec)
Far tier: every 0.3s (~3.3 updates/sec)
Threshold between the two: 50 tiles

To be precise about how “near” and “far” are currently measured: it’s each player’s distance from the map’s coordinate origin, a simple, cheap position check — not a per-player distance to whoever else happens to be standing nearby. It’s an area we’re continuing to refine, but the tiering itself already does real work reducing baseline traffic.

On top of that sits a population throttle: every additional concurrent player nudges everyone’s own update interval 5% slower, capped at 2x slower once you’re running roughly 21+ players at once. In plain terms — on a small server this throttle barely does anything, and on a large one it automatically leans harder on lower frequency instead of letting total network load scale linearly with player count. Either way, you get the benefit that actually applies to your server.

🗜️ System 2: Physiks BitLib — A Custom Compression Engine
This is the part most sync mods don’t have: a bit-packing library built specifically for this mod, not a generic serializer bolted on top.

Instead of sending position, health, animation, and velocity as separate readable fields — the straightforward approach, and typically 30+ bytes of payload before the game’s own network framing even gets involved — BitLib packs every field into a fixed number of bits and writes them edge-to-edge into the byte stream with zero wasted padding:

Position (X / Y): 16 bits each
Health: 8 bits
Animation state: 8 bits
Velocity (X / Y): 8 bits each

That’s 64 bits — exactly 8 bytes for a complete player state update. Every time. No padding, no waste.

📦 System 3: Delta Compression & Change Thresholds
Once a player’s been seen once, BitLib switches to delta mode: a single 1-byte header flags which of the 4 state categories actually changed since the last packet, and only those fields get packed:

Walking in a straight line (position + velocity changing): 7 bytes
Only position shifting: 5 bytes — over a third smaller than a full update
🔍 Honest edge case: if every field changes in the same tick (rare — taking damage while moving while switching animation, all at once), the packet is 9 bytes — one byte larger than a full update. It happens; we’re not hiding it.

The real win is the threshold gating underneath all of this. A field is only encoded at all if it moved enough to matter:

Position: 0.2 tiles
Health: 1 point
Velocity: 0.1 units
Animation: any actual state change

Cross none of those thresholds, and no packet gets sent at all for that player that tick — not even a small one. Anyone standing still, building, looting, or AFK contributes close to zero sync traffic, whether that’s one friend on a private server or one of thirty on a public one. (Precision tradeoff, disclosed: position resolves to roughly 0.18 tiles per step, health to about 0.4, velocity to about 0.04 — fine enough to be invisible in gameplay, coarse enough to keep every packet small.)

🚗 System 4: Vehicle-Aware Syncing
Most player-sync mods treat someone driving a car exactly the same as someone walking — and that’s exactly why passengers rubber-band. This one doesn’t. It detects when a player is seated in a vehicle and stops syncing their position entirely, on both ends:

🛑 It won’t send pedestrian-tuned position/velocity updates for someone moving at vehicle speed
🛑 It won’t apply position corrections to a seated remote player either

Instead, it steps back completely and lets Build 42’s own native vehicle systems — which already handle authority handoff and motion smoothing purpose-built for vehicle physics — do what they do best. No more two sync systems fighting over the same character. Works whether it’s one car or a whole convoy of them.

⚙️ System 5: Server-Side Load Management

Server-side player processing capped at 30 players per tick
Within a strict 50ms time budget per tick

This means population growth degrades gracefully instead of spiking server tick time all at once — the server does a bounded amount of sync work per tick no matter how full it gets.

✅ Compatibility
Build 42. This mod touches sync and networking only — it doesn’t alter game rules or content, so it plays well alongside your other gameplay mods.

Workshop ID: 3725078880
Mod Id: PhysiksDataSyncOptimizerB42

Workshop ID: 3725078880
Mod ID: PhysiksDataSyncOptimizerB42