@zeuxcg is there anything you guys can do about the issue with positions not being accurate in servers? This is heavily effecting my game and I am sure any other games with vehicles have problems with this as well like vehicle simulator, Ultimate driving, Drive shaft, and other games.
2 Likes
Once again, positions should be preserved with full accuracy. Rotations can be off. If you have parts that have Rotation 0,0,0 and they look off feel free to submit this as a bug report. With regards to rotation, we’d need to investigate whether this is viable at all - the extra bandwidth requirements of a full transform are pretty substantial.
2 Likes
Who would I report this or send the file to? Also thank you for your time and patience.
You can use the Bug Reports category for this. If you don’t have posting access, then you can send a group-PM to @Post_Approval.
I’m not sure who you can send files to if you only want staff to see them. You can make a private place though and link it – staff can access those. It’s generally preferred that you make a minimal reproduction of the issue, though, which should be fine to share with others and include in your public bug report post.
You might be able to work around this bug. For all of the parts you want full precision for, you can experiment with putting CFrameValue objects in them on the server, then reading those and setting their CFrames using those on the client.
If the rotation of CFrameValue objects is not preserved with full accuracy, then you can experiment with sending the lookVector and upVector of the objects’ CFrames.
Here is some untested example code
local CollectionService = game:GetService("CollectionService")
local function markAsFullReplication(part)
local v = part:FindFirstChild("FRLook") or Instance.new("Vector3Value")
v.Value = part.CFrame.lookVector
v.Name = "FRLook"
v.Parent = part
local v2 = part:FindFirstChild("FRUp") or v:Clone()
v2.Value = part.CFrame.upVector
v2.Name = "FRUp"
v2.Parent = part
CollectionService:AddTag(part, "FullReplication")
end
local function lookUpToCFrame(position, look, up)
-- you might need to flip `look` somewhere (i.e. `-look`)
local right = up:Cross(look)
return CFrame.new(
position.x, position.y, position.z,
right.x, up.x, look.x,
right.y, up.y, look.y,
right.z, up.z, look.z
)
end
local function handleFullReplicationParts()
if game:FindService("NetworkServer") then
local function forPart(part)
markAsFullReplication(part)
end
for _, part in next, CollectionService:GetTagged("FullReplication") do
forPart(part)
end
CollectionService:GetInstanceAddedSignal("FullReplication"):Connect(forPart)
elseif game:FindService("NetworkClient") then
local function forPart(part)
coroutine.wrap(function()
part:WaitForChild("FRLook")
part:WaitForChild("FRUp")
part.CFrame = lookUpToCFrame(part.Position, part.FRLook.Value, part.FRUp.Value)
end)()
end
for _, part in next, CollectionService:GetTagged("FullReplication") do
forPart(part)
end
CollectionService:GetInstanceAddedSignal("FullReplication"):Connect(forPart)
end
end
handleFullReplicationParts()
Sadly there is no way to reproduce the issue since it just happens. Like no matter what game I make or play I notice the offsetting and this has been going on since like 2011.
It is how ever for me only the positions not the rotations since roblox changed .000 rotation to .00 only
JFYI we’ve just enabled a change that increases the precision of rotation replication by fixing a bug. (the change is live on Windows and Mac only, in desktop players - not in Win10 app or mobile yet, these just haven’t upgraded - the change will ship there in a week or so).
In theory rotated parts should align better in general now. We still are not using full precision rotation replication but I’m curious if any places posted here got better? If they didn’t it would also help to see models that showcase the portions of the places that have this issue, e.g. two rail segments that are misaligned etc.
5 Likes
Definitely looks a lot better! I don’t have any previous screenshots to compare with, but I should still be able to give a good idea. This is the seam in a fairly extreme example now, where it’s perfectly aligned in studio:
I’m not joking when I say this is a fairly extreme example, either - the two parts there have one of their size axes pretty much maxed out. I was trying to build a mile-tall tower or something with the scale of 2.5 studs to the metre. Don’t ask.
Edit: Fixed grammar.
I can confirm that it’s a lot less now. The rails are not overlapping eachother anymore, instead they’re just offset ever so slightly! I very much appreiciate this improvement!
Before: 
Now:
2 Likes
Thanks for feedback, glad to see it helped 
I’m planning to take another look at this to see if we can make it even better without spending too much extra bandwidth.
7 Likes
Same issue is happening and it still is pretty much the same. Why cant roblox use full precision rotation replication?
We have to find a balance between performance and fidelity that works well for all games. Currently using full precision rotations would add ~5% to the instance join data size on games like Jailbreak (that has just 20k parts so the join data is dominated by some other instances - the impact will be progressively worse the more parts you use), which is not a great tradeoff. Due to some properties of the replication system it’s non-trivial to make the format adaptive to the part size (which is what really the problem is - the larger the part, the more significant do rotational errors become).
1 Like
Would you mind sending me part of this level? (just the tracks) I’d like to take a closer look at the introduced errors for future improvements here.
1 Like
So pretty much it is a bug that will never be fixed due to the trade off that would have to happen. Because even if you gave the developers a option to use full precise rotations would be nice.
As a heads up, we found some vehicle models that depended on the old, imprecise, rotation too much and broke as a result. We’ve disabled this fix for now and will have to change some physics internals to bring it back 
So you’ll have to wait a bit longer to get smaller errors again.
Could you elaborate on that a tad more about the vehicle models that depended on the old; imprecise, rotation. Does this mean the rotations and positions ended up being changed to much or that the physics engine itself changed from the update? I am asking for more information about this to see if that was the result of why our chassis keeps bouncing on track segments more than usual yesterday.
Hey uh could you test something for me before I post it on the thread. Insert a new meshpart copy paste the location of the old one and paste it into that new meshpart and then paste the id of the old one into the brick and try the game tell me if it offsets.
and delete the old one after doing so
Physics engine didn’t change; the existing logic of old surface-based Hinge/Motor joints relied too much on the specifics of the old imprecise rotation so motors in some vehicles could lock up after the update. The change is temporarily disabled and will come back once we fix the Hinge/Motor logic.