More block colours

[Yrjosmiel]

Simple as that. Better yet, when buying blocks, there will be a screen with a preview of the colour and an RGB input. AKA Custom colours.

I'm not sure about the custom colours requiring more data but if that's so, at least just add more colours.

loliwantthatpinkswagship

 

[starhaiden]

we have all the colours we need.
red, yellow, blue, green, purple, orange, brown, black, white and grey.
All the 1st and secondary colours, black, white and grey and brown

 

[CyberTao]

Hull colours take up a lot of IDs, so they aren't just going to add 50 shades of red on a whim. If you have a more specific colour in mind, then ask for it. They kinda pick and choose colours so that they have a greater variety between them.

 

[jorgekorke]

Yet I would like the grey color to be divided on light and dark shades, like Minecraft does.

 

[Reilly Reese]

The only color I request is a cyan hull.

 

[Yrjosmiel]

we have all the colours we need.
red, yellow, blue, green, purple, orange, brown, black, white and grey.
All the 1st and secondary colours, black, white and grey and brown

but pink

 

[kiraen]

More colors would be nice just for the greater variety. Might be simpler to have color be an overlay texture and let us paint our ships. Additional textures can then be added by server owners depending on server resources.
But I think more shapes is more important.

Any way you look at it this falls under 'eye candy', cosmetic stuff that doesn't really change the game. Low Priority.

 

[Blaza612]

Actually, what if we completely change the colour system? A part of his suggestion was a color picker/wheel type of thing, if we have something like that, then we can reduce the amount of IDs that the hulls use up.

At the moment, each colour takes up it's own ID, the way the new system would work is we select the colour we want the hull to be in some place, that then places the standard hull which only takes up 1 ID, but that hull changes it's colour based on the selection, storing that selection within the block itself. The amount of IDs used would be reduced to what a single colour variant requires, and will completely change the looks of ships. I'm probably going to write this as it's own suggestion. :P

 

[starhaiden]

maybe schema wants you to work for pretty things.

 

[Blaza612]

And I made the thread. :P

The Colour Thread

 

[Titansmasher]

With regards to a colour slider:

This has already been requested multiple times, and has been rejected each time due to the amount of data that would need to be stored.
IIRC there is currently 3 bytes of data per block, relating to its position, ID, health etc. There isnt room within the current data structure to add this, and to add selectable colours would mean the bytes per block would have to increase, in turn causing a drop in performance.
For example, a full 255,255,255 R,G,B colour slider would require a byte per colour, doubling the space needed per entity effectively.

And with regards to more IDs:
Again there is the issue with data. There is currently a limit with the number of ID's possible due to the 3 byte limit on blocks. IIRC this comes to something like 2048 different IDs. This may sound like a lot, but from my time working on the block config (around a year ago) we were already up in the hugh 800s for ID values. Quite simply, there isnt room within the current block structure to allow for a multitude of colours without reducing the amount of possible expansion for the rest of the game.

To add anything like this would require a restructure of the entire block system to have it work effectively in the long run sadly.

 

[kiraen]

IIRC this comes to something like 2048 different IDs. This may sound like a lot, but from my time working on the block config (around a year ago) we were already up in the hugh 800s for ID values.

If I understand what you are saying, we could have twice as many blocks before we actually start running into issues? Looking at the number of blocks in the shop and knowing that some are going to be removed, my question is this: Where is the issue?
(and yes, I realize that some 'blocks' may take up multiple IDs)

To add anything like this would require a restructure of the entire block system to have it work effectively in the long run sadly.

If it's really that big an issue and constraint, then maybe it should happen sooner rather then later. It'll be easier to do it now than after another year of adding more blocks which will need to be converted.

 

[Titansmasher]

If I understand what you are saying, we could have twice as many blocks before we actually start running into issues? Looking at the number of blocks in the shop and knowing that some are going to be removed, my question is this: Where is the issue?
(and yes, I realize that some 'blocks' may take up multiple IDs)



If it's really that big an issue and constraint, then maybe it should happen sooner rather then later. It'll be easier to do it now than after another year of adding more blocks which will need to be converted.

Yes we do have many ids available before star made will run out, but at the rate of expansion (300 ids in the space of a few months when I last worked on it) it doesn't make much sense to be using them up on different colours of hull.

And while yes it would be a good idea to change the block system now, that is under the assumption that there is a more efficient method that schema can use. From what I heard the current data structure is highly efficient for the storage of blocks. I am not too sure how it could be improved upon.

 

[kiraen]

Yes we do have many ids available before star made will run out, but at the rate of expansion (300 ids in the space of a few months when I last worked on it) it doesn't make much sense to be using them up on different colours of hull.

I'm not saying they need to be added now. Just, eventually. But I don't really see limited space being a concern at this point.

And while yes it would be a good idea to change the block system now, that is under the assumption that there is a more efficient method that schema can use. From what I heard the current data structure is highly efficient for the storage of blocks. I am not too sure how it could be improved upon.

If Schema and Schine really do consider this to be a valid argument at this stage of development then this is something they really need to start looking into. It's going to cripple the game otherwise.

 

[Visitor]

I am perfectly happy with the current palette. In fact, most often I ignore majority of colors during construction outside of color-designation markings etc.

The whole block mechanics apparently does have a few limitations and thus should be up for improvement, no matter the colors.

 

[friendofvampires]

So I'm confused as to the issue with the data storage system of color wheel systems. sure if you store the three numbers separately it would take up all the space, but why not just use the hex value? I don't know the storage of a hex value, but I assume it could be stored in a byte, and one byte shouldn't be an issue, unless I dramatically misunderstand how the system works

 

[Valiant70]

NO MORE COLORS until we get category-based storage filters! It takes far too long and is far too tedious to set up a full sorting system now.

 

[alterintel]

So I'm confused as to the issue with the data storage system of color wheel systems. sure if you store the three numbers separately it would take up all the space, but why not just use the hex value? I don't know the storage of a hex value, but I assume it could be stored in a byte, and one byte shouldn't be an issue, unless I dramatically misunderstand how the system works

one bit is a 1 or a 0. one byte is 8 bits. one byte in binary looks like 0000,0000 to 1111,1111 which in decimal is 0 to 255. One hex value is 0 to F, which in binary is 0000,0000 to 1111,1111. One hex value takes 1 byte. and one block is only 3 bytes. It just wouldn't fit.

Having the block size so small is what makes Starmade work.

 

[friendofvampires]

one bit is a 1 or a 0. one byte is 4 bits. one byte in binary looks like 0000 to 1111, which in decimal is 0 to 7. One hex value is 00 to FF, which in binary is 0000,0000,0000,0000 to 1111,1111,1111,1111. One hex value takes 4 bytes. and one block is only 3 bytes. It just wouldn't fit.

Having the block size so small is what makes Starmade work.

then maybe compress the colors, like, instead of the full 255/255/255, do like 100/100/100, and compress it to a one byte overlay, coz this will open the colored blocks id's, while keeping the size the same data size and providing at least SOME customization

 

[alterintel]

I was wrong in my previous post. one byte is 8 bits not 4. I've corrected my previous post.

then maybe compress the colors, like, instead of the full 255/255/255, do like 100/100/100, and compress it to a one byte overlay, coz this will open the colored blocks id's, while keeping the size the same data size and providing at least SOME customization

it would take up a considerable amount of room in the block data, I'm not sure if there's any room left.

Context:
3 bit color (1/1/1) (38% of a byte, or 13% of block data) gives you 8 colors
(Primary and Secondary colors. red, green, blue, yellow, purple, orange, black, white)
4 bit color (50% of a byte, or 17% of block data) gives you 16 colors
5 bit color (63% of a byte, or 21% of block data) gives you 32 colors
6 bit color (3/3/3, or in binary 11/11/11) (75% of a byte, or 25% of block data) gives you 64 colors

6 bit color would give you the most customizable colors, as you would be able to select how much red, green, or blue you want in each color. It would allow you to select 0%,33%,66%, and 100% for each color.