As a Roblox developer, it is currently impossible to have large parts that actually stay where you place them when you test your game online. If you place a large part, anchored or not, in studio you’ll notice that it stays in the same position if you save the place and open it again in studio, but it shifts out of place (more so the larger it is) in online mode.
I may be wrong, but I’ve seen it mentioned somewhere that this is because part positions are sent to clients with less precision than they’re stored in the place’s rbxl in order to reduce bandwidth usage. Makes sense. I feel that anchored parts, however, should have their positions sent to clients with full precision, as they’re not intended to move. In the rare event that an anchored part is moved, it’s likely to be done by using a tween, in which case the end position could be sent to the client and the client can interpolate it (as I think it already the case).
Again, there’s a fair chance I may have misunderstood what was said or be entirely wrong on all accounts here, but on the off-chance I’m not, this fix would be greatly appreciated by all of us who use large parts.
Edit: I changed the title to specify rotations instead of positions.
This would be a great fix as I personally have brought this up 2 years ago and was told it was being fixed yet it never was fixed. I notice this issue with smaller parts as well and this bug currently has broken any racing game I have ever made due to the offsetting it creates a bump which sends cars flying or pops them up into the air during a turn. The most annoying part about this is in studios it is perfectly smooth but in a actual server im getting like .01 or .006 offsetting, If this issue continues to exist I will have to stop 7 years worth of work and go to unity or some other platform where this type of issue does not occur. This issue is highly annoying for those of us who make racing games and others who try to do showcases or use bigger parts were it is more noticeable. Programs like blender use I believe .00000000 for positions and never offsets not even by .00000001 so for roblox I do not see why this can not be fixed as it only uses .000. This issue honestly should stop being overlooked and ignored.
To zeuxcg, I would assume since you work on networking or at-least seem to would you be able to explain to me or see if this is something that can be fixed or why it can’t be fixed? Because this is a issue that is seriously affecting my game heavily and keeping me from being able to optimizing it.
Positions are replicated with full precision for .CFrame updates and initial join. Rotations, however, are not. Are the parts that are offset rotated, or do they all have Rotation 0,0,0?
It seems to happen with all large parts that I’ve seen (or rather, it happens with all parts but gets far more noticeable as the parts get larger), including anchored ones - of course, the vast majority of them have a rotation other than 0,0,0.
Edit: I changed the title to specify rotations instead of positions.
The tracks are in segments so for straight aways if I made it 1 segment rather than multiple it would use less parts and textures. However by doing this I also increase the amount the part will offset in the actual servers of the game due to floating point errors. This then causes the cars to bounce and fly off the track since it has a .005 or .002 offset. In studios though. the parts are perfectly aligned no offsetting. Bigger parts = more offsetting.
They have both I have some parts with zero rotation then others with some rotation.the offsetting is the position though. Ever since roblox removed .000 in rotations and changed it to .00 I have not had to worry about the rotations offsetting.
These are two rails connected to eachother (they have rotation applied to them), but the bigger the rail, the bigger the offset becomes online (and it’s a real pain)
@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.
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.
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.
