So currently this bug is causing issues when I duplicate a model and move it upwards with the move tool or by the grab tool and positioning it where I want it. The image shows what is constantly happening and I never had this issue before when I moved models until about maybe 4 or 5 days ago.
Now I know from a older complaint that I gave to roblox back in 2013 they stated parts eventually get floating point errors. But this is just from duplicating a model and moving it in any direction with the move tool or using the grab tool. The second image is showing me duplicating the model and then moving it. I have found that using increments of 1 sometimes works if you can move it up by that much evenly. Usually I use .05 increments until this bug started to happen. This is extremely frustrating to me as this is prohibiting me from getting pretty much any work done. The main reason for this is because I have rebuild everything from scratch rather than just moving it upwards after duplicating it.
This bug has impacted me so much over the past years. I’d really want to see it resolved once and for all.
3 Likes
Well this is much worst than what it usually is as moving any model gives me floating point errors now. Like this makes me want to quit trying to build in roblox and move to something else since it is such a frustrating problem that just got worse. This is coming from a guy who has used roblox since 2012.
1 Like
I thought using the grid gives you the same issue just as much as building without the grid scale. I would switch from .05 but most of the details I work with are around .05 or .1 and I know the issue existed since like 2008 or 2013 but Over the past 4 or 5 days I noticed that it is much worse than usual.
1 Like
I don’t get this report. You can’t just “fix” floating point errors. They’re not programmer errors, they’re just a limitation of the size of doubles in memory. What exactly is your suggested fix?
1 Like
… they can fix floating point errors what ever they did in the latest update made it worse. From that one would assume they can figure out what they did that made it worse and fix it. I am not a roblox engineer so I can’t just go do this and this and it will fix the problem. That is their job not mine.
You misunderstand. Floating point errors aren’t code logic errors. Whether the last update had any correlation with this or not, you’re probably using the wrong term. The only way this is affected is by the size of the unit you use to store data. Roblox uses 8 byte doubles, which are accurate up to 13 decimal places (in the Lua anyways). If you want more accuracy, you increase the amount of bytes your numbers use, or refrain from using larger numbers along with decimal places.
This being the case, I think you should change the title, as it’s misleading to say “floating point errors” when it’s likely not the case.
If the update and these issues are linked, then it’s probably a logic issue in the tools, and not anything to do with the data type.
Floating point errors is when roblox does not store the data of the rotation or position properly for bricks. Instead of lets say .1 it gets changed to .101 or rotation 90 gets turned to 89.845
No, that’s not it at all. It has nothing to do with the Roblox codebase, it’s literally the size of the number in memory, and how accurate it can be. You can only store so much information in 64 bits.
Then what would you call it?
Not sure, but it isn’t a floating point error if it’s not directly related to the accuracy of the numbers.
Make sure you can for-sure tell that this is the issue. As a rule of thumb, the larger your numbers get, the less accurate, and the more decimal places, also less accurate.
This can also generally be related to the studio environment, and there are many factors that can affect it. Not throwing out the fact that it may have been a recent update away, it’s still more likely that something in the work environment changed and is affecting this.
I mean every single developer that I have talked to calls it floating point errors so until someone says a different name for it I will keep it how it is. This includes belzebass, simbuilder, quantumdepression, and a few others that I talked to on discord.
Can you post or send me the model that you have this problem with?
Honestly it is with any model but yeah I can send you a model for this so you can easily see it. I’ll send it now with a explanation of what to do to replicate it.
Not sure if this is related but…
Studio:
Online: 
The positions in the properties tab match exactly in both studio & online, but for some reason the rail is physically offset online, causing massive issues when driving my trains…
1 Like
That is a different bug but yeah I have had that as well in studios everything is aligned but online it is not.
1 Like
People lump a lot of things into the category of “floating point errors”, and while some are directly the result of the scale or nature of the number being stored, i.e. it’s too precise for the number of mantissa bits, or its binary representation is an infinitely repeating pattern of bits. But other forms arise from this indirectly, say if a calculation has intermediate values that are of a different scale or precision than the input or output. And then there is accumulated error, which can result from repeated operations losing little bits of precision. Accumulated error and rounding issues can make operations that would commute in their pure form non-commutative in practice; for example, rotate a part 9 different ways, and then apply the exact reverse sequence of rotations. After that, there is approximation error. For example, you might rotate a part with a matrix composed of sine and cosine calls, which are implemented (approximated) by finite partial sums the Taylor Series.
In short, there are a lot of ways you can introduce drift and precision issues in the “logic” that cannot be figured out just from looking at the stored or computed final values.
1 Like
Even though 0.1 has no finite binary representation, 0.1 does not simply become 0.101 without some help; this is like 6 orders of magnitude worse than just the normal imprecision of its stored representation. I’ve been seeing this too, and will file a bug. Accumulated error is the most likely cause of something like this happened due to dragging a part.
The fact that it happens by moving a model 1 time means it is producing the error and not doing it over time. It is hard to explain but pretty much what it is doing now shouldn’t be happening at all and it used to not happen. Now all of a sudden moving something automatically offsets it. I have sent a model with instructions on how to replicate it to another staff member and so I’ll wait to see what they say.