What would be the problem with just treating it like a 255 if any of the values are >1 and treating it like a unit color if all the values are <=1? And also support for hex code…?
How will it differentiate between Color3.new(1,1,1) (0-1 scale) and Color3.new(1,1,1) (0-255 scale)?
Don’t cover for it because no human being can differentiate between C3(1, 1, 1) and C3(2, 2, 2) or C3(0, 0, 0)? I guess if you were lerping mathematically it’d be a problem.
One other idea, I don’t know if this has been suggested, but there could be a Color3.SetMode(Enum.Color3Mode)
with enums
Mode255
Mode01
ModeHex
or somesuch. Obviously bad names are obviously bad.
It would also be a problem when people, who had never used Color3s up until the update, were under the false assumption that Color3.new() was used exclusively with integers from 0-255 and didn’t know they could use decimal values from 0-1, tried to use C3(1,1,1) on a 0-255 scale and couldn’t figure out why their particle was appearing white instead of black. That’s a weird gotcha that isn’t really good design.
2 Likes
I think they should just leave Color3.new be and instead add additional functions for different representations, modifying Color3.new like that sounds like a way too convoluted solution.
Bringing this in from the other thread since this kind of discussion is more appropriate here:
I select colors in terms of 0-255 because that’s what every graphic design program uses – even the properties window. If I use the color picker to find a good color for a specific button and then I want to create that button through a script, I now have to type Color3.new(r/255, g/255, b/255) since the properties window gave me a value in terms of 0-255. Or say I design an interface in an program designed specifically for that purpose (not because ROBLOX is necessarily bad for this, but because these kinds of programs have years of work specifically dedicated to enabling me to do what I’m trying to do). I then want to rebuild it in ROBLOX once I finalize it in the other software, and now I have to convert every single color from terms of 0-255 to 0-1.
It doesn’t matter how screwed up and illogical it is to use colors in terms of 0-255. If I’m manually initializing a Color3 value in a script, it’s because I know what color I want in there. Where did I get that color from? Somewhere that represents colors in terms of 0-255, hex, or hsv (most likely 0-255). Front-end wise, what makes no sense is to use 0-1 for choosing something’s color when the color you have is always going to be in a format other than that. We should be able to define colors with the formats they typically come in without having to do boilerplate calculations to convert them to a form irrelevant to the end-user.
What I’m saying is that it’s sort of silly to manually initialize a Color3 from a script. Generally speaking, it’s often a good idea to separate data from logic.
3 Likes
Here’s my two cents-
-
Color3.rgb(0xFFFFFF)takes one integer, already discussed -
Color3.rgb(255, 255, 255)takes three integers, already discussed. -
Color3.hsv(180, 1, 1)is already on the Trello board. -
Color3.hsl(180, 1, 1)because apparently people like color spaces. -
color3AB = color3A:lerp(color3B, 0.5)interpolates between two colors in HSV space. -
color3A[*/^+-]color3Bshouldn’t happen because that’s operator overload abuse. - Tacking more functionality onto
Color3.newis also a bad idea. - If you have a super obscure use case (e.g. working with an RGB scale other than 1.0 or 255), do your own division.
2 Likes
I think it’s pretty cool that roblox transcends color depth. In 80 years we’ll want another constructor for inputting colors from 0-65535 
YES! A reasonable person with whom I agree!
2 Likes
But in Phantom Forces you manually initialize health settings & spring values (char module), camera offset & bounds (camera module), and shoulder offsets (replication module)? Those are all modules written by you. How are initializing those variables in the script any different from initializing color settings?
@0xBAADF00D ROBLOX employees declare constants in all of the corescripts i.e.
There’s nothing wrong with declaring constants in scripts. I’m pretty sure your outlook on how constants should be defined is an opinion opposed to a definitive “people are doing this wrong” – I could say that spamming ObjectValues inside objects for settings is ugly and defining them in code is 100x better. It all boils down to opinion. Even outside of ROBLOX, languages like C++ and Java allow for the declaration of constants/final variables, and I’d be hard-pressed to believe either declaring Color3 settings is different from declaring constants or that both declaring constants in C++ and Color3 settings on ROBLOX are nonsensical.
I was talking about:
“Not sure. I was just mentioning that 0-255 is really pretty meaningless. You shouldn’t be choosing colors that way anyway.”
No, he’s very wrong about using the value objects. They’re a dumb idea and lead to clutter as well as are super slow to index.
The problem is that making your api perform witchcraft (assumptions) is never as good as just telling it explicitly what to do.
Color3.new(1,1,1) = white
Color3.new (with ugly hack)(1,1,1) = black
1 Like
I mean, that’s fine and all. If it’s truly constant. But things in games rarely are.
It is code, after all. You’re trying to put data into code, so you need to transform it first. Totally makes sense to initialize with 0.0-1.0. It’s already been said that you can just write a small helper. 
BrickColor.new(“Bright red”)
BrickColor.new(21)
BrickColor.new(Color3.new(196/255, 40/255, 28/255))
All of those produce the same BrickColor. Why do those exist? Such blasphemy! We could just write a little helper to convert them to the internal format! It needs to be transformed in the end so it makes sense to initialize it with the internal format! Who in the world would design disgusting constructors like that?!
/sarcasm
Color3 is hardly different from BrickColor – they’re both colors. Why would it acceptable for BrickColor to have the ability to be constructed with multiple formats but not Color3? Transformation doesn’t need to and shouldn’t be handled by the programmer. You’ll never hear someone tell you to program in binary because ultimately a computer needs binary instructions. The very heart of programming is abstracting the creation of computer instructions to a level comfortable enough to a programmer that they can work productively. What you’re suggesting is going against that very nature. Inputs to Color3 can be converted internally – there’s no need for the programmer to go out of their way to convert values that are most certainly, in the majority of cases, not in their 0-1 form. Compare: <196, 40, 28> and <0.768628, 0.156863, 0.109804>. Long trails of decimals are not a proper human-readable format, and programmers should be using workable formats at an interface level.
1 Like
Ideally we’d have
BrickColor.BrightRed
or something along the lines of that. I personally find the brickcolor system really awkward to work with.
For Color3 we should have an rgb, hex and other commonly used formats (especially used in web). It would be awesome for GUIs to have rgba but I don’t see that working without applying weird hacks.
We’re not working with code that takes hours to compile into a giant program. The point of scripts is that they start quickly.
I prefer to put my data in a script (not necessarily in the same script as the logic) because clicking objects in an explorer tree and modifying values in a property panel isn’t what I do all day.
1 Like
In a perfect world we would achieve data/logic separation through stylesheets.
This isn’t a perfect world, so putting parameters at the top of scripts or in a data module works fine.
1 Like
missed BrickColor.Red()
1 Like