Color3.fromFull(r, g, b)

Feature Requests Engine Features
#42

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[*/^+-]color3B shouldn’t happen because that’s operator overload abuse.
  • Tacking more functionality onto Color3.new is 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
#43

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 :stuck_out_tongue:

#44

YES! A reasonable person with whom I agree!

2 Likes
#45

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.

#46

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.

#47

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
#48

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. :wink:

#49

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
#50

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.

#51

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
#52

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
#53

missed BrickColor.Red()

1 Like