obviously yes lol.
This is happening to several overhead wires and other rails that are also anchored.
7 Likes
This also happens to the roads in my game.
8 Likes
I’ve experienced the same problem,
for me, it seems to be mainly for smaller longer objects.
At least I haven’t noticed it on bigger parts…
4 Likes
This is a known bug that has existed for years. It has been named “brickshift”. I have had this issue for several years with all parts in my game, including my roads and traffic signals that are farther away from the origin.
Although I don’t know exactly why it is like that, but one temporary solution is to make the rails and ties have the exact same orientation in a section, and try making the tracks and ties half the size.
Also, when moving parts in longer distances, copy and paste, don’t duplicate. This minimizes the brickshift on the multiple parts at farther distances from the origin. Try not to drag the parts as much when they are far from the origin. Undoing the moves will NOT undo the brickshift, so if it happens you would need to completely reinsert the copied rails. These methods work for me.
Here’s some examples:
Traffic light, installed May 2016, far away west of origin
Misaligned long road, installed December 2015
Minor visor issue, traffic light installed in July 2019
Sometimes it gets as bad as this:
Traffic light installed in June 2016
4 Likes
The cause of brick shift is due to a phonomenon known as Floating point errors. Basically it’s down to the ways computers handle numbers. Like have you ever inputted a whole number as the pitch for an audio and found it becomes some really crazy decimal? Thats a floating point error.
4 Likes
There’s gotta be some way for them to handle this, no???
2 Likes
Well for me I build my main models close to the origin before using copy and paste. I also tend to make sure things that need part precision are close to the origin in the game. Example: I always prefer to have my groups bus depot close to 0,0,0 in order to prevent brickshift.
3 Likes
obvously that would add a pretty big performance hit. maybe there could be a property to change it for specific parts so not every part has so much persision.
6 Likes
I would LOVE this. A toggle for parts like “ClientAdditionalPrecision” would be excellent.
3 Likes
Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up when we have an update for you.
4 Likes
Maybe there could be a property to change it for specific parts so not every part has so much precision! Like a togglable attribute of baseparts called “ClientAdditionalPrecision” that is off by default to prevent unnecessary memory usage, but when enabled, the client would pay special attention to the part’s orientation/position values.
Thanks for taking this into consideration and I look forward to seeing what you guys do to solve this issue 
2 Likes
Bumping this, I still have this issue and if there could be some sort of feature where long aligned parts farther from the origin can be whitelisted with more precision for orientation, that would be excellent.
4 Likes
Hello, I am currently having this problem with only certain parts. Has there been any sort of fix to this?
I am also having this exact issue where only specific parts seem to reset their orientation to 0,0,0, especially when using shallow gradients.
I’ve had this issue for as long as I’ve been a developer on the platform, its always only specific parts, and never all parts.
An interrim fix may be to have a script that forcefully updates the part orientation (before deleting itself) as a child of the part(s) you want to fix.
1 Like
Its been 3 years, what’s going on Roblox?
fr, I’ve fixed it by using unions which I don’t find ideal but it works well enough. I don’t think it’ll work 100% of the time or if you have loads of parts
Unions massively suffer from brick shift when rendered, they are absolutely not a solution (quite the opposite), and unions absolutely still suffer this problem.
1 Like
I mean, I fixed it this way since it was the only amount of parts doing it and I found it worked for me. It’s not the best fix for my game but it will have to do since we have no way on actually fixing it
1 Like
Duplicate of Many parts refuse to maintain their studio-set orientation in-experience.
We found that part rotations that were close-but-not-quite-axis-aligned had about 4x worse angular error than expected due to a bug in the rotation compressor.
This should now be fixed or much better.
1 Like
This post was made 3 years before mine, mine should be considered the duplicate instead.
I’d like to see whether the OP’s issue is resolved though, as it may be more general compression of orientation rather than the fixed bug due to very long parts unlike in my case (note how their example is a long straight section of track, likely many hundreds of studs, while mine was less than 50 studs)
1 Like