I think it is time to loose BrickColors and go with Color3 for everything that has a color property. Color3 in a way is more useful than BrickColors because there are multiple colors you can pick from and use. in BrickColors you only get 64 colors, and the colors that don’t show like Dark red, Metallic grey, etc… when you use them they don’t show in-game, the brick using that color turns into a different color close to the one you picked and it is quite annoying. I also know this will bring a lot of games to break if we are not told about this coming out before hand, but that is why if this feature were to happen, the ROBLOX staff needs to give a weeks notice on the forums here and on the blog so developers can edit their game for the update.
One question I know will be asked about this feature in foresight, “What about the part’s color if the feature were to happen?” Well my answer is simple, lets hope the ROBLOX staff would make it possible for the BrickColor to transfer to Color3 if the feature would ever come out.
Your Brains and Muscles, Luke Shultz (PyroInfinity)
[quote] [quote=“PyroInfinity” post=105801][quote=“777-300ER” post=105798]This has been discussed multiple times and everybody says it would make save files too large.
Sorry dude.
(P.S Drop all of the unneded formatting from your post. It looks kinda tacky and is hard to read.) [/quote]
I told you, I am not so good yet, also Echo is right, if CSG doesn’t make the file size to large, why would Color3? Explain buddy.[/quote]
Instead of one value being stored for the colour, you’re storing 3.
Also, CSG DOES make file sizes huge.[/quote]
There are probably clever ways of optimising it though. Like indexing every colour used when you save and assigning a value to them.[/quote]
That’s exactly how you would do it. Think of Java’s Color object:
“Color(int rgb)
Creates an opaque sRGB color with the specified combined RGB value consisting of the red component in bits 16-23, the green component in bits 8-15, and the blue component in bits 0-7.”
Isn’t it better to have 64 colours rather than a probable 16.8 million for network streaming?
Also are you really saying ‘break every game’ with this post? Abolishing BrickColor will destroy all the old games, and all the games owned by uninformed people.
Also personally I would not go back through all my games to fix this.
What if our game doesn’t stream parts?
All of my stuff is generated locally on the client.
If there are network problems, why are we streaming the name of all parts to the client?
Oh, and not to mention quite a few of these:
Also, after reading the old blog post on featherweight parts, networking should be no problem at all
Even if we continue to use BrickColor, we should at least be given a uniform palette with less arbitrary colors, as well as a corresponding Enumeration
At least give us some temporary instance we can place inside of a part that will modify its color, similar to a mesh. :imagine:
Also this update would be seamless, just deprecate BrickColor
It would not make file sizes that large if they used Hexadecimal representations to store them. It can’t be much worse than using pre-defined LDRAW color indexes across their network code. I mean think about it, roblox has no problem representing basically unlimited values for UDim2s, and those represent much more information than what RGB colors represent, and I’m pretty sure Serverside GUIs are a thing, so its not like they aren’t replicating stuff.
Soooooo why can’t they do it?
The way I see roblox allowing BrickColors into Color3 values, is by transforming BrickColors into a system of Presets for Color3 values.
So basically, BrickColor properties would allow Color3 values as inputs, and BrickColor.new(“Bright red”) would return the color3 value of it.
As for the brick color picker… I’m pretty sure it would work the same. The only difference is, they would include a “Custom Colors >>>” button so you can pick from a Color3 palette. The BrickColors would still be Color3 values, but like I said, it would be like a preset thing.
They seriously need to consider this. I think the idea I have here would work perfectly.
In order to make it efficient on network transferring, they would need to create a event pool for every brick color. When the property changes, they should drop the new value into the packet. I’m assuming they aren’t frequently replicating every color even if it doesn’t change already, so this network idea is probably unnecessary, but for gods sake, a solution to this networking problem is not that hard probably.
One of my my most desired features is Color3 for parts, it kills me to have to compromise on certain colors and sometimes I’ll go as far as using a decal to adjust the shade. I know there was the whole argument over more data when replicating the Color, but wouldn’t that only be apply if you’re instancing new parts or changing their colors on the server? I wouldn’t imagine it’d be a significantly greater amount of data, especially if your smart about it.
It would be better using a byte array to do it - because bytes can represent 256 values (0-255) - you would only need three, versus six when using hex to represent them.
The solution could be to keep the BrickColor system, but allow colors to be set to Color3’s at runtime, so the client downloads the brickcolors but a script can change it all as required. It’s a bit hacky, but it seems to solve any issue I can see.
As I remember seeing someone mention previously, the workarounds required right now if one decided they absolutely needed this take up a lot more than what simply sending a Color3 takes. SurfaceGUIs are a possible workaround, but a terrible idea performance-wise. Decals are a possibility, but use tons of pixels. Meshes with textures are another workaround, but also use a ton of pixels, and need mesh data on top of that if they are loaded from the site. A simple Color3 instead seems like a small amount to send in comparison.
