Starting June 15, we’ll be rolling out more reliable physics interactions in your games. You can opt-in now for early testing by using Workspace.ImprovedPhysicsReplication. We’ve significantly updated our backend replication system to provide:
“Eventual consistency”, ensuring that updates are not lost due to packet drops
Internal architectural improvements that will make it easier for us to support “Physics-like” Data Replication
Please note that once enabled, the network stats for physics will either disappear or drop to 0 KB/s. This is the expected behavior as traffic transitions to our new replication pipeline. Going forward, please use the stats for the new replication pipeline, Instance State Replication (ISR).
This Update + Server Authority
Do note that because Server Authority requires Workspace.NextGenerationReplication == Enabled as a requirement, this update has no impact on Server Authority games. Workspace.NextGenerationReplication is a more advanced version of this update, but contains potentially breaking changes (which is why it is not being automatically rolled out).
What’s Next
We plan to roll this out globally on June 15, and expect it to just be a silent bug fix to long-standing bugs. You can use this upcoming week as a window to flag any unexpected behaviors. Testing early allows us to actively respond to your feedback, whether that means delaying the global rollout or temporarily opting out of your individual place.
Sounds amazing, speaking of physics tho i wish the engine could render mesh collision better, because PreciseConvexDecomposition isn’t really accurate on most cases…
What you’re describing sounds like a performance hang that causes updates to not be sent. This will still happen.
Eventual consistency simply means that when the part comes to rest, we will ALWAYS make sure the final update arrives on all clients. This is not true on current Roblox, as we will try to send the final update a few times, but if you have a connection interruption or higher priority updates to send the part may come to rest in the wrong location.
Bad wording (on my part), when we say “invisible” we mean tech changes that should not impact behavior do not actually change behavior and don’t bother developers.
The fact that there were any bugs is the visibility that we’re talking about. We’re not trying to hide that changes happened.
Right now Physics Data is the only thing optimized for synchronizing continuously changing Game State, because Physics Data for non-sleeping parts is almost always changing every frame. All other data, like the Color, Anchored Boolean, everything on the properties list is optimized for “Discrete” updates which is great if you’re making one off changes but is bad if you’re changing them every frame and expecting them to synchronize.
Whenever we’ve wanted to add new continuously changing data (think of adding bone positions/offsets for animation that happens during simulation), we’ve never been able to do it because the Physics Sender was hyper optimized for sending ONLY Position Velocity data, and wouldn’t be able to add other data into it.
The architecture lets us really easily just mark a property as “Continuous” and send it via the new system, which means there is more freedom to what kind of Properties we can add and keep synchronized.
I’m having trouble finding Workspace.ImprovedPhysicsReplication in the Roblox Documentation. I found Workspace.PhysicsImprovedSleep which sounded similar, but it doesn’t exist under workspace in Studio.
Normally we would do this kind of rollout silently because its supposed to have no behavior changes, but if you read that thread you’ll notice we broke a few games. So now that we’ve fixed all those bugs, we’re trying to give creators the option to opt into this early and tell us if there are any issues we didn’t catch.
This should be an invisible change, based on our testing.
looks pretty good. previously, jumping and landing would almost always cause a resimulation and the same would be true for sudden velocity changes, even from things as simple as setting AssemblyLinearVelocity to 0 (this was very troubling when figuring out why landing would cause a resim). there are still some minor cases with collisions (particularly via geometry that isn’t uniform) and erratic player movement, but that’s to be expected honestly.
Internal architectural improvements that will make it easier for us to support “Physics-like” Data Replication
all i have to say is that i hope this is at least some progress towards calling .Destroy() on simulated instances because lord help me if i have to figure out how to make constraint movers not rollback when disabled one more time i might have to be admitted to arkham asylum
“Eventual consistency”, ensuring that updates are not lost due to packet drops
this one in particular was very huge. prior to this, seemingly-perfect resimulations would end up leading to rollback on top of rollback which would even leak into the visual entity renderer for my game depending on the circumstance. this forced me to making assumptions about the play-state regarding sequenced things (particularly framedata), like assuming that a sequence should waive rollbacks as long as the sequence’s initialization itself wasn’t rollbacked underneath strict termination guidelines (e.g. air movement is constrained over time via coded-in parabolic motion). the problem is still absolutely apparent, but far muted in many circumstances compared to before. unsure if this is what the update targets, but i did notice improvements in these areas (specifically: applying knockback to entities) - especially when joining lobbies with >80ms ping. to sum it up, most of the things affected once caused me many a headache when trying to maintain smoothness when a bunch of random irrelevant resimulations occurred at the same time.
hopefully, this will continue to show a reduction in headache from filtering out the noise from code-related mispredictions (cough, mover constraints…) and “weird physics inaccuracies.”
that being said, my before/after below, with network settings (note packet loss & jitter, track visible resims via the gauge on the left of the character + general character animation)
Hi, I was wondering if there will be any method to opt out. Since I’ve built this server authority system, and for some reason, the new replication method, false flags, and I can’t seem to find a method to counter it. It happens only when I’m on wifi, not Ethernet, and on my MacBook, rather than my main computer. I am not sure why. Do you guys have any suggestions or insights on what has changed so I can counter it?
edit: oh my goodness just look at the lack of rollbacks logs in the after video its so perfect
Wait, sorry I’m confused. Are you saying this setting has impact for you in Server Authority games?
Server Authority already uses a more advanced version of this tech by default. This setting should have no impact on Server Authority as server authority has already migrated almost all of properties to this mode. (This is what Workspace.NextGenerationReplication = Enabled does)
Sorry can you elaborate on what you mean? Is there a bug you can repro?
With server authority enabled, the Default and Enabled options appear to work identically. They are presumably both activated. This behaves differently from before. In older builds, inconsistent physics between client and server would cause the character to jitter nonstop.
AuthorityMode: Automatic
AuthorityMode: Server
ImprovedPhysicsReplication: Default | Enabled
A few days ago we enabled a fix to Humanoid Prediction/Resimulation that should have made them more consistent. It’s unrelated to this update. Is it possible that this is what you are noticing?
That’s a bit odd, isn’t it? That’s not what I meant…
its so perfect
