Atm I am doing this
PrimaryColor = {Primary.Color.Value.r, Primary.Color.Value.g, Primary.Color.Value.b}
However, this saves a long number (like 0.234235324634634) for example. Now that’s a lot of characters for something that should only be a max of 3 characters (0-255) as that’s the max for each RGB scale
Multiply the numbers by 255 then floor it.
For some reason the R, G, and B properties are based on the Color3.new constructor which takes inputs from 0-1.
So you would divide by 255 then round it down.
PrimaryColor = { math.floor(Primary.Color.Value.R*255), math.floor(Primary.Color.Value.G*255), math.floor(Primary.Color.Value.B*255) }
It’s more precise as a decimal, and that’s how Color3s are actually stored in-game. It’s not just “for some reason,” there’s plenty of good reasons to store it that way.
Fair enough. But using the color picker and in properties, you use 0-255 numbers and not 0-1
And basically everyone is wanting to use the former, e.g Color3.fromRGB, saving (like OP), and more. It is just more readable.
It’s more readable, but I don’t see why it would be stored in the most readable format. People rarely just input 12 numbers to a CFrame, but that’s how it’s stored. The storage method should be what’s most practical or compact, not what’s maximally user-friendly.
It is what it is, though. Roblox certainly can’t change it now for backwards compatibility reasons, so I guess it doesn’t really matter what my opinion on it is.
I concur. When I was beginning scripting it heavily confused me why everything turned black or white when I was trying to change color on things. Took me a while to figure out it was because certain things take different color constructions like that.
Never really understood why there’s a discrepancy.
This is the tidiest way I’ve seen to handle colors for data storage and table indexing. I don’t know what it does to accuracy but odds are it won’t be enough to matter in most cases.
