Reproduction
While it’s arguable colors are not meant to be set this way, it does seem to be a feature as it works for green and blue just not red.
This is because it splits the string on the commas and then tries to interpret each word as a number, in this case “rgb(52”, “152” and “219)”. When it is interpreting each word, it reads all numerical characters of the word until it reaches a non-numerical character (or it results in 0 if no leading characters are numeric at all).
“rgb(52” does not contain any leading numerical characters => 0
“152” => 152
“219)” contains three leading numerical characters => 219
It doesn’t actually interpret this string as three values enclosed in an “rgb(…)”. It’s just a side effect of how it’s being parsed.
If I enter in ‘52, 152, 219’, I get a blue color with the correct numbers. Is there a reason you’re typing in rgb(##,##,##) instead of just ##,##,##?
I use a palette designed for web-design, so the color values are designed to work with CSS.
I’m referring to the fact that you said you pasted in “rgb(52, 152, 219)” instead of just copying the “52, 152, 219” part. Is there a reason you’re adding the “rgb” to the front or the parenthesis?
I’ve actually has cases where it’s listed like that on websites and it says ‘Click to copy’
Then when I paste in studio it comes out as rgb(r,g,b) so I have to delete the 5 extra characters manually.
Do you have a link to one? A quick google search only shows sites that have an easily copy+pasted rgb value.
I’ve added this to our bug list.
Chose RGB format then paste. Here’s an example: rgb(52, 152, 219)
But those kind of sites always have a hex format output as well (#RRGGBB, and that’s also the default output format it seems) so I would suggest supporting that format for all Color3 fields. “rgb(…)” seems a bit arbitrary to support.
(@Silent137 because I forgot to hit reply:)
It seems like Studio currently attempts to parse #RRGGBB, because when you fill in #FF00FF it outputs (1,0,1) for example. However, there’s a bug with that, which I explain here:
It boils down to the fact that Studio reads the hex input in 0-1 range and then maps each channel directly onto the Color3 value, which should be in the 0-255 range instead. If we get (working) support for the hex input, I don’t think anyone would require the “rgb(…)” variant anymore.
Added that one to our bug list as well!
That’s assuming the site outputs it in that format, I am using a tool I downloaded (not sure where from) as well as sites such as flatui, the tool only outputs in rgb. While easy to convert between the two I think arguing that we should not support rgb(r, g, b) as a string can also be applied to supporting #rrggbb when we already support r, g, b
RandomDev could come in any moment and post “_ format output by websites x,y,z should be supported by ROBLOX!” I don’t want to claim that rgb(r,g,b) is popular (or not) enough to be supported by default, but there will always be formats users want to use that ROBLOX doesn’t support. Even if the format is popular, is ROBLOX supposed to keep adding support for these formats time and time again? Before we get ahead of ourselves, I think leaving it up to the user might yield the best results.
For instance, plugins could have the following API member:
callback plugin.PropertySet(propertyType, setValue)
in which the callback could take both of those and spit out a new value to be used in lieu of the set value, and if it returned nil the property would use the current value. With this you could set up Studio to support any sort of format you wanted, including any used by external tools you might use. It wouldn’t be restricted to Color3 values either.
Perhaps that exact implementation isn’t the best, but allowing this to be controlled by the user is the most flexible option imo.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.