Why has the default colorset never changed?

[Greek2me]

Or you could just get rid of the color-changing spray can.

[Ad Bot]

[-Jetz-]

Or you could just get rid of the color-changing spray can.

Aww, come on, that's the boring solution. Perfect opportunity to implement recoloring images on the fly, and subsequently projectiles, emitters, and explosions too.

[Zeblote]

Aww, come on, that's the boring solution. Perfect opportunity to implement recoloring images on the fly, and subsequently projectiles, emitters, and explosions too.

this

And while you're at it allow images and shapes to be mounted to each other.

[Hammereditor5]

All that extra color data would have to be sent over the network.  It takes 6 bits to represent 64 colors, but 32 bits to represent arbitrary RGB color. 

Now here's where it gets interesting.  Say you have 10,000 bricks in a scene, thats an extra 260,000 bits to go from 6 bit to 32 bit color.  On the "DSL" network setting, the packet size is 350 bits.  Thats 743 packets to send the extra color data.  The packet rate for the "DSL" setting is 20/second.  It would take 37 seconds to send all of that extra color data.  And that's in an ideal scenario where you're maxing out each packet.  In reality, it would probably take about a minute. 

The bottom line is that 64 is more than enough unless you're trying to build some kind of goatse mural.

Adding just 2 more bits for each color would make the maximum colorset size 256 instead of 64, which is a huge improvement. That would be 20,000 extra bits instead of 260000, so it would take no longer than 5 seconds.

[Plexious]

The most colors we would need is 128, which is just 1 more bit.

[Farad]

Old builds would suddenly look weird

[Xalos]

Brick colors aren't actually rendered through their color ID, they're already implemented as full RGB.


So let's say that, instead of having a fixed colorset, the server and client have a "virtual" colorset that is used to send colors of groups of bricks. Barring mass spam, which is going to take up bandwidth anyway, the vast majority of bricks in the same area will tend to be in the same group of 64 colors or so.

As a result, any old builds take up the same amount of network bandwidth - the colorset already has to be sent anyway - and any hosts that don't like the idea of anyone using any color can still trivially disable it.


There are other reasons that full RGB would be undesirable, but using network concerns as one doesn't really stand up on its own.

[Jay the Cartoonist]

Even just 8 more colors would make me happy 

Currently, the 64 colors are split unevenly by rows of 9, which is the default standard row, and you're left with a weird 1 color row.  I usually find when making colorsets that I really only wish for 1 more row anyways.

[Zeblote]

Try joining with a new client now. It probably won't work.

[Blockzillahead]

Why do we even have colorsets? It should be easily possible to allow any color on a brick.

yeah but how would this system work? like how do we paint the bricks? the spray can wont work because it has fixed colors. manually entering the colors for each brick is also very tedious

[Zeblote]

yeah but how would this system work? like how do we pain the brick? the spray can wont work because it has fixed colors. manually entering the colors for each brick is also very tedious

No, the server would allow any color to be used, but your client could still have a colorset of default colors. (like MS Paint, Paint.net, etc. do)

Then there can be a color picker tool for matching custom colors.

[gr8dayseth]

There still needs to be a non-transparent purple in it.

[Xalos]

Try joining with a new client now. It probably won't work.

Because the color is sent and saved as a color ID, but it isn't stored on the brick as one.