Author Topic: Why has the default colorset never changed?  (Read 2683 times)

There are hundreds of amazing colorsets that are vastly superior to the base-game one. I was wondering why it has never been replaced.

Most of them load default builds with incorrect colors, that's probably why. And some colorsets that expand on the default tend to stick in uneccesary/ ugly colors .

Why would it need to change? I make plenty of use bending them around my imagination while I build, but with some people I guess it's vice-versa. 

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

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

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

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

I think it's due to network limitations.
It's faster to send a number from 1-64 than a colour code.

I like the default
it's nice an easy to find which color I want

I like the default
it's nice an easy to find which color I want
It has a nice range of colors (excluding purple), but lacks in shades of those colors.

I think it's due to network limitations.
It's faster to send a number from 1-64 than a colour code.
It's also faster to send a 32 bit integer that can represent every color-code humanly possible.

I would rather have larger color palettes than being able to use any color. I feel like color matching would be difficult and annoying if it was possible to use any color.

I would rather have larger color palettes than being able to use any color. I feel like color matching would be difficult and annoying if it was possible to use any color.

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.

Unfortunately, I'm pretty sure Blockland's color system wouldn't allow it.  From what I understand, each color requires its own datablock (maybe more than one).  Setting aside an indefinite number of "custom color" datablocks simply would not be feasible due to datablock limits.

I think it's due to network limitations.
It's faster to send a number from 1-64 than a colour code.
Have the server keep track of the 64 most frequently used colors, send that list to the client, and any bricks using those colors can be sent with that. Other colors can be sent on a case-by-case basis. Could bump the number up to 128 or so if necessary, like on a freebuild server where everyone uses a different colorset.

Unfortunately, I'm pretty sure Blockland's color system wouldn't allow it.  From what I understand, each color requires its own datablock (maybe more than one).  Setting aside an indefinite number of "custom color" datablocks simply would not be feasible due to datablock limits.
Actually each color requires tons of datablocks because the game basically creates a new spray can item with its own particles and such for each color. Probably room for optimization there, too.


Unfortunately, I'm pretty sure Blockland's color system wouldn't allow it.  From what I understand, each color requires its own datablock (maybe more than one).  Setting aside an indefinite number of "custom color" datablocks simply would not be feasible due to datablock limits.
That's the way it is now, yes, but it could allow any possible color and wouldn't need any datablocks if Badspot modified the c++.