Essentially, setting the color of a part with Color3.new() sets the RGB values slightly incorrectly, which can lead to a big difference if set repeatedly. I’ll give an example below:
Steps to reproduce:
Imagine we have two parts, Part and Part2.
“Part” has a Color of (25, 255, 0).
If we print that value we get (0.0980392, 1, 0) in the normal 0-1 range.
Now, we set “Part2”'s Color to Color3.new(0.0980392, 1, 0) [or Color3.new(0.098, 1, 0) to save characters.]
If we now print Part2’s Color, we get (0.0941176, 1, 0), or the equivalent of (24, 255, 0).
As you can see, the Color changed from (25, 255, 0) to (24,255,0).
This is quite a big issue in my game, Obby Creator , where parts’ colors are saved and loaded back in repeatedly. Eventually, the color becomes (0, 255, 0) which is just completely wrong.
NOTE: This only occurs with RGB values < 26, as seen in the image below where I use the equivalent of (26, 255, 0). I assume it’s something to do with the value being < 0.1 in the 0-1 range, but I may be wrong.
Machines aren’t always perfect, floating-point errors are small “artifacts” that keeps appearing time to time in certain work with computers, creating imprecise representation of something. This affects incredibly large and small numbers.
