So I made a map referencing gm_slope. This map features large wedges. Around 1000 studs large. Upon playing on the map on my client, I noticed that the wedges were offset by around 0.001 studs to a whole studs.
At first I thought this was a filtering enabled issue, it wasn’t. I tried multiple ways to fix these weird offsets until I completely moved the map closer to the centre of the workspace, in case the position values were being messed around with how far the map was from 0,0,0. This had some effect, as the largest offset wedge was now offset by a very tiny amount. But a previously tiny offset wedge was now offset around 1 stud.
So wherever I positioned the map, the offset of wedges changed per wedge. I noticed this in my other smaller maps that use 1-10 stud wedges.
This issue is happening both on clientside studio and clientside roblox.
Checking the CFrame positions on both client/server appear to show the exact same position values. Despite the clearly visible difference in positioning.
I also disabled any scripts that could possibly interfere, this did nothing either.
Note: I have also tried pasting the map into a completely fresh new experience/place on studio. The same issues occur regardless.
This isn’t always a simple problem to solve, but I’ll try my best in troubleshooting and provide some possible causes.
Wedge positions in Roblox can be affected by many things:
- Server-side physics: When you place a Wedge on the server, its position is computed through the server’s physics simulation. However, when the client receives the Wedge object, its position could be offset due to client-side rendering or physics updates.
- Client-side rendering: The client’s rendering engine will not necessarily be identical to the server’s physics simulation, leading to differences in position.
- Network latency and packet loss: Communication delay between client and server can cause position offsets, especially if the client is being sent stale or incomplete information about the Wedge object.
- Client-side jitter: The client-side physics simulation may have introduced random jitter (minute movements) in the Wedge position, leading to the offset effect.
To also mention:
Roblox uses floating point numbers to represent positions, which might lead to precision errors, especially with large-scale maps or objects placed far from the origin (0,0,0).
Judging by the position, I wonder what happens if you move it closer to origin?
Also here are some things to check:
I noticed your orientation changed, can you verify with me that your part is anchored, as that kinda gives me a suspicion.
It does not appear your position is a direct cause, I also cannot see the Z axis part of the position.
There is a noticeable difference between server and client here:
server
client
I didn’t notice that orientation difference, thank you for pointing it out! I can confirm it was all anchored, as I moved it closer to the origin 0,0,0. The same offsets persisted relatively.
I do believe it was likely floating point, as I saw in a few other posts that the server can handle 3 decimal poisitions whereas the client may round it up to two decimals. As when I rounded these positions, they seemed to stay consistent.
I didn’t want to go through the trouble of redoing the whole map to not use 3 decimal positions so I unioned the wedges and parts so if there were an offset, it wouldn’t look noticeable.
When I try to align wedges to parts, I do notice it immediately goes into 3 decimals like .137 which is why they seem to always be slightly misaligned even by the tiniest fraction on the client.
I guess all I can do is be more careful of how deep into decimals I go with positions
Mhm…and Im unsure but I had a similar issue, as orientation decimals were not fully ‘square.’ I do note I checked everything and made sure it was all a perfect number, which can be tried, to mitigate this.