[realpoke]

Bodies spawning mid-game (projectiles, pickups) were being resimulated from the earliest rollback tick, running physics states that predate their existence.

The driver now tracks the network_rigid_body group and raises a resim floor through the new NetworkRollback.notify_resim_floor() when a body first appears, so rollback never goes earlier than a body's spawn tick.
Rollback also starts from the frame's first tick so multi-tick frames replay their full physics sequence, and space snapshotting is skipped when rollback_physics_space is off.

[elementbound]

I'm concerned this would mess up simulations. E.g. if the server receives a new input that was 5 ticks ago, and we just spawned a rigid body, the resim floor will be the current tick, meaning the received input will be ignored.

Would it be possible to selectively simulate rigid bodies instead? Or disable them for ticks they haven't existed yet? Liveness tracking could be useful for this.

[albertok]

Yeah I think @elementbound raises a good point, we can re-use RollbackLivenessServer since this is exactly it's job - liveness tracking. See https://foxssake.github.io/netfox/latest/netfox/tutorials/spawning-and-despawning-in-rollback/

So something like:

Each NetworkRigidBody registers with RollbackLivenessServer in NOTIFICATION_READY, then we filter in the physics driver.

addons/netfox.extras/physics/physics_driver.gd
for net_rigid_body in rollback_participants:
    if NetworkRollback.is_rollback() and not RollbackLivenessServer.is_alive(net_rigid_body, tick):
        continue
    net_rigid_body._before_physics_rollback_tick(delta, tick)

Combined with implementing _rollback_spawn / _rollback_despawn on NetworkRigidBody to freeze/thaw the body in the physics server as well.

Personally I've been using Predictive Synchronizer for both projectiles and pickups to save on bandwidth ( their consequences are server replicated, clients predict ) but can see the benefit of providing the full lifecycles in these classes.

[realpoke]

Thanks for the feedback! Good catch on the global rollback floor, you're totally right that clamping it drops valid player inputs.

Regarding RollbackLivenessServer, that makes good sense for normal node sync, but with Rapier's StateManager3D do full native world swaps.
Any body spawned after that snapshot just gets wiped on the engine side, so GDScript liveness can't really save it.

I ended up solving this in RapierDriver3D instead by pruning the older space cache with remove_cached_by_index when a body spawns.
That way netfox core stays completely untouched and player inputs keep working.

I can close this and make a small PR for netfox.extras instead if you'd like it upstream, or just close it out.
Let me know what you think!

[albertok]

@realpoke Oh right.

yeah if its rapier specific a fix in the rapier driver would be awesome.

[realpoke]

Moved shared logic for 3D and 2D out into addons/netfox.extras/physics/rapier_driver.gd
Let me know what you think!