@MBobbo
You mentioned you bypassed FMoverDefaultSyncState::ShouldReconcile but have you looked to see what is the culprit in causing a reconcile to be needed there for you?
Yes, for me the culprit was the distance between the location of the server and client being greater than the static value there (5.f)
I’m not reproed it but you can’t rely on client and server stepping the same amount of frames in all cases no. If the server or client has a CPU hitch it might drop physics frames as to not cause further CPU performance issues like going into a spiral.
This makes sense! Thanks for clearing that up. I have a lot of code that is highly dependent on the number of frames between actions. From now on I will just snapshot the server frame when the action starts and then when another action begins get the delta between the current server frame and the snapshotted frame to calculate how much time has passed.
Your approach with essentially running rendering behind in time is an approach that does work, but at the cost of decoupling physics and rendering timelines further than they already are which means it can be hard to aim at an object you want to collide with or perform logic based on overlaps or sweeps etc.
Understood. From my CVD captures the visual mesh doesn’t stray too far from the root component so it will do for now until I find a better approach. I’m looking forward to the updates. I’ve been checking up on UE5main almost every day to see where things are headed. I ran my first dedicated server test using Chaos Mover today and there are a ton of kinks to work out on my end but it’s super exciting to see things somewhat working properly between multiple clients over the network. Once I’m able to reduce the number of corrections and hide the ones that do occur my game will be extremely polished thanks to you guys! 
Thanks for taking the time to reply!
Hi @MBobbo, I’m building a physics-based multiplayer party game (think chaotic soap/physics objects knocking each other around) using the NetworkPhysicsComponent resimulation system and I have some architectural questions before committing to this design.
Planned Architecture:
Each physics pawn has two collision layers. The inner layer is the actual mesh collider which handles real environment collisions like walls and static meshes via normal Chaos physics. The outer layer is a larger trigger box which handles pawn-to-pawn interactions only. When two pawns’ trigger boxes overlap, instead of relying on default PhysX contact resolution, I calculate and apply velocity changes inside OnPreSimulate_Internal based on the interacting objects’ current velocity, mass, and type. This gives me full control over game feel tuning similar to how Rocket League tuned their impulse responses. Mesh colliders between pawns are set to ignore each other to avoid double-resolution conflicts.
Questions:
First, overlap events are detected on the Game Thread but OnPreSimulate runs on the Physics Thread. Is there a safe and resimulation-compatible way to pass overlap data into OnPreSimulate, or should I be doing the overlap query directly inside OnPreSimulate using a physics scene query?
Second, when a pawn bounces off a static mesh via real Chaos collision and then immediately enters another pawn’s trigger zone within the same frame, is there a guaranteed execution order between the contact resolution and my OnPreSimulate callback? I’m concerned about reading stale velocity data in the chain reaction scenario.
Third, does applying velocity changes to other pawns inside my own OnPreSimulate_Internal properly get recorded into those pawns’ rewind history? Or will the resimulation system on those other pawns be unaware of the externally applied velocity, causing desyncs on correction?
Fourth, we’re considering raising the physics tick rate from 30hz to 60hz specifically to reduce the window between game thread overlap detection and physics thread processing. Is this a reasonable trade-off or is there a better architectural solution to this timing gap?
Thanks in advance.