(I am pretty sure the Body* object to blame here is BodyGyro, but I’m not positive)
I think this is an issue with distributed physics not handling network ownership correctly because if you are outside of the simulation region, the other bikes move correctly. I set the network ownership of the Part that contains the Body objects to the owner of the bike, but when you approach another player, the bike begins to rotate (on what appears to only be the y axis) and teleport around. Each client sets the properties of their own Body object (these properties are white-listed by FE).
I have seen this on other projects besides mine, so I know it isn’t a rare occurrence. Has anyone discovered a way around this issue?
Any chance you can link me to a place? I think I know what the issue is and I’m going to be working on fixing it today (although it would take a little while to get it across into Production).
In ROBLOX when we do automated distributed physics, and object can only be “owned” by one player on the server. The person that owns the object sends updates to all other players about the position of this object. Now, we have a special behavior for something that is within the simulation region of one player, but owned by another: this is called “Buffer Zone”.
In “Buffer Zone” we actually simulate the current physical state of the object (rather than simply teleport it to where the other player tells us it is) and then snap the object to the new position sent by the real owner. This is done so that just in case the part’s ownership transfers to the new owner that he doesn’t have extra stale-data.
Generally this should not lead to divergent behavior, so there are two things wrong with this picture:
[ul]
[li]BufferZone behavior should be disabled for objects with Manual network ownership.[/li]
[li]BufferZone simulation should not diverge like this.[/li]
[/ul]
I’ll be fixing the first part today and try to investigate the second point.
[quote] Any chance you can link me to a place? I think I know what the issue is and I’m going to be working on fixing it today (although it would take a little while to get it across into Production).
[/quote]
I’m working on this with Badcc and he’s away right now, so here’s the file.
Basically running two player test servers and approaching the 2nd player should show the same problem the gif shows. You can speed your bike up and down with W and S.
Thank you so so much! This was the one bug that this Tron game was needing. It’s truly game breaking and I wasn’t going to ever release if this was still around.
Just a heads up. This fix is delayed about a week. To make this fix work I had to make a property that only existed on the servers replicate out to the clients. Unfortunately, when we introduce new replicated properties we have to do two steps to release them otherwise older clients (iOS/Android) can run into problems.
Its still on the way, I just had to pull it out of the last release.
Can we get an update on this? We’re not sure if it’s live, we feel like our bike issue is still apparent. I want to ask before the code freeze is live.
It’s a tricky thing to test. We thought we saw it maybe 30 minutes ago but I don’t want to say anything too soon. We’ll keep trying to recreate the problem.
Thanks for checking.
