Constructing Color3 variables is a mess. Every single piece of image editing / graphic design software I use uses a scale of 0-255 for r, g, and b. Even in the Studio properties window this format is used. When we get into the script editor though, all hell breaks loose and the convention we’re used to everywhere else in graphic design goes out the window – in ROBLOX code, color values go from 0-1 instead of 0-255.
Why? Because it’s easier to store internally that way? It’s fine if it’s stored that way, but RBX.Lua is a front-end interface for ROBLOX developers. All exposing 0-1 to us does is force us to use boilerplate code where we divide each number in Color3.new() by 255. Seemingly randomly using 0-1 instead of the graphic design convention of 0-255, which is used everywhere except in RBX.Lua – including the properties window, is bad. I don’t want to have to append /255 to every value I put into Color3.new(), and I shouldn’t have to waste time converting back and forth between the script editor and the properties window / image editing programs.
We’re obviously past the point of changing Color3.new()'s arguments, but what we can do is add a different constructor. Color3.fromFull(r,g,b), Color3.from24Bit(r,g,b), etc – something like that where I can use Color3.fromFull(123, 52, 254) without having to add /255 to each number.
Edit: Color3.rgb(r, g, b) sounds like a much better alternative than Color3.fromFull. Color3.hsl & Color3.hex would also be good counterparts to accompany Color3.rgb should it be implemented.
Whenever I write a wrapper for this I find that I can only justify calling it if it has a really short name. Typing /255 is really easy, so the function has to be even easier. I’ve always used .new2 but I don’t like the sound of that for an official API. fromFull is much harder than /255. Not sure what a good name would be…
What about Frame.BackgroundColor3 = ColorUnit.new(0.5,0.8,0.2) and it just converts it to Color3
Color3 is Vector3
While Unit is a Vector3 but each number is 0-1
Yeah, it could be shorter – I’m not sure what the best naming would be. Either way, fromFull isn’t harder to type than three /255s. Color3.new(123/255, 52/255, 254/255) is 36 characters, while Color3.fromFull(123, 52, 254) is only 29. Even if one of the values is 255 or 0 (can be shorthanded to 1 and 0), fromFull is still less characters.
The problem is having to convert 0-255 to 0-1 either mentally (waste of time since Color3.new is the only one that uses 0-1) or by boilerplate /255s. This doesn’t help because you’re still having to convert 0-255 (standard) to 0-1 (only used in RBX.Lua).
Those are the constructors I’ve heard a lot of requests for:
Color3.rgb(R,G,B) Range from 0-255
Color3.hex("#defead")
Color3.hsl(H,S,L) Range H would either be 0-360 or the equivalent in radians Range S and L would be 0-1 since nobody uses 255 for that It’s L right? I forgot if it’s HSL or HSV. Hue, Saturation and Lighting?)
Using lowercase names since that seems to be how it is for constructor table stuff. (Only exceptions are CFrame.Angles, Instance.Lock and Instance.Unlock) (Not that the latter 2 even matter) (Angles is actually an alias for CFrame.fromEulerAnglesXYZ, so eh)
This may have weird consequences though. When I say Color3.new(0x000001), it will become Color3.new(1) and thus Color3.new(1,0,0), meaning bright red while I wanted black with a very very faint tint of blue.
Color3.new will just see the input as a number variable, it can’t distinguish between it being hexadecimal or decimal because the difference is only there before parsing.
True but this would be a behaviour change, so it could modify the behaviour of existing code if people relied on the fact it appends 0 for arguments not given. I have no clue if people do that, so I’m not going to assume they don’t.