Read by Council Block ID workaround (for more colours)

[Achriel]

Admittedly how the code works is beyond me, but I thought I toss this out in case is was workable (pardon if it's a completely inane idea). I also realize it may be WAY too late in coding to make this change or already suggested (couldn't find it).

Could the building blocks ID be separated from their colour? This would allow a massive palette of block colours without using additional IDs

• A block ID is defined by it's shape but colour ID is 'metadata' unique to each block like its rotation
• The hull blocks using IDs would be: Basic / Standard / Advanced / Crystal / Glass
• When a block is placed we store it's location, rotation and colour
• The colour could be mapped to a graphics palette, texture, template or whatever as set by the server/client (this would allow clients to have different maps than the server default if desired) in some or all cases (another config setting)

Maybe it's done this way already but if not this might help the block ID problem as there are only shape IDs.

/* Flame protection suit on */
[DOUBLEPOST=1454961162,1454960165][/DOUBLEPOST]Kept digging.. found this which explains some BlockID information (hope it's current)

 

[Dire Venom]

+1
No idea if it would work or not though XD

 

[lupoCani]

There's no significant difference between "Metadata" and block bits, it's all ram in the end. If anything, metadata should be far less efficient data storage when used for so many blocks at once.

I have suggested a variation of this- one piece of metadata for every ship, which re-defines the palette for the existent colors. If I want three shades of green but no purple or yellow, I set green, purple and yellow hull to the green shades I want instead. Considering any one ship uses only a fraction of the color spectrum available, and the central nature of the metadata would amount to no more than a few bytes, I think it's a reasonable compromise.

I have heard there are significant technical difficulties with this approach, although I'm still not sure of their exact nature.

 

[jayman38]

As far as I know, the block data diagram is current.

With that said, I have an issue with this suggestion: as shown in the diagram, we have an absolute current limit per block of 24 bits. There is no per-block "metadata". The rotation is stored in the "orientation" bits. There is no room for color data.

There is a chance that the devs might add another 8 bits to the block data for a total of 32 bits, increasing the Block ID range available.

 

[Achriel]

Thinking about the block I had this idea but it would be a significant change in how block IDs are used. We have 10 bits to use for BlockIDs so here is how I was thinking it COULD work. The numbers in the list refer to the 'Bit Offsets; in the above diagram.

0 = LSB (can we use this bit?)
1 = Hull - Yes or No (No being a non-hull pieces, like cannons, modules, computers, etc..)
2-4 = Basic, Standard, Advanced, Crystal, Transparent & 3 new types
5-7 = Cube, Wedge, Corner, Tetra, Hepta & 3 types of slabs
8-10 = 8 options
11 = Is there any HULL blocks with 512 hit points? If not we COULD steal yet another bit.

If we can snarf LSB & 1 HP bit that gives us 32 colours.

With this I think it's obvious we don't have enough bits to add a colour in the Block ID. Might have to consider the 4-byte solution.

 

[CyberTao]

Hey, I remember that image!
As far as I know, it should be current, it was taken from the current Wiki's modding section/info.

I'm sorry to say, but I dont think the bits work in that way. From my understanding, each of the bits are either a "0" or a "1", binary. 10 Bits to the BlockID means each block has a section like 0100011001 that is used to point the game towards a certain section of code or configs, to do it like you suggest would mean something like the following;
[Yes] / [No] - Block?
[Yes] / [No] - Basic?
[Yes] / [No] - Standard?
[Yes] / [No] - Advanced?
[Yes] / [No] - Transparent?
[Yes] / [No] - Cube?
[Yes] / [No] - Wedge?
[Yes] / [No] - Corner?
[Yes] / [No] - Tetra?
[Yes] / [No] - Hepta?

Each section needs a value, so it would need to be a Yes or a No for each check, having them paired like you thought would mean it would have to choose 1 of each set each time.

Again, I don't know much more than you in these coding things, just what I learnt in school. Would need to get Megacrafter127 or Lancake up in here to explain it better, as they know this stuff much better.

 

[Achriel]

Hey, I remember that image!
As far as I know, it should be current, it was taken from the current Wiki's modding section/info.

I'm sorry to say, but I dont think the bits work in that way. From my understanding, each of the bits are either a "0" or a "1", binary. 10 Bits to the BlockID means each block has a section like 0100011001 that is used to point the game towards a certain section of code or configs, to do it like you suggest would mean something like the following;
[Yes] / [No] - Block?
[Yes] / [No] - Basic?
etc...

Ah.. no. Binary doesn't work that way. 2 bit = 4 possibilities... 10 bits = 1024 possible combinations (not 10)

 

[CyberTao]

Ah.. no. Binary doesn't work that way. 2 bit = 4 possibilities... 10 bits = 1024 possible combinations (not 10)

Sorry, I'm tired for reasons I dont understand and I didnt see the edit (page doesnt reload or alert for edits), and I just kinda ran thoughts off the original.
But if you use that 1 bit to decide if it's a Hull or not, you effectively half the IDs that can be used by Non-hulls as well. I have no idea if that'd be worth it in that sense, since I don't know what all is planned and modding options there may be.

 

[Achriel]

But if you use that 1 bit to decide if it's a Hull or not, you effectively half the IDs that can be used by Non-hulls as well. I have no idea if that'd be worth it in that sense, since I don't know what all is planned and modding options there may be.

Sorry you saw the 'intermediate post" (how we got confused, it posted before I was finished). The 'Hull' bit does separate blocks into two 512 groups but that should give Schine plenty for 'functional' blocks that are not hull.

The REASON for this type of delineation is so people can make textures and palettes that are changeable outside of the code itself. Basically it makes mods much easier and you could make the default colours as you see fit. SM default might be a spread of colours but a StarTrek server could go tilt them to allow a different block palette and not break a schematic. Not sure if it'll work, but maybe it'll spawn a better idea in Schine which really knows the code.

 

[Valck]

See also Block IDs vs. Shape/Material/Colour field for a slightly different angle. You might consider that as a subsection of your thread, I'd be open to merge it into here if that's feasible or desirable.

 

[Megacrafter127]

Thinking about the block I had this idea but it would be a significant change in how block IDs are used. We have 10 bits to use for BlockIDs so here is how I was thinking it COULD work. The numbers in the list refer to the 'Bit Offsets; in the above diagram.

0 = LSB (can we use this bit?)
1 = Hull - Yes or No (No being a non-hull pieces, like cannons, modules, computers, etc..)
2-4 = Basic, Standard, Advanced, Crystal, Transparent & 3 new types
5-7 = Cube, Wedge, Corner, Tetra, Hepta & 3 types of slabs
8-10 = 8 options
11 = Is there any HULL blocks with 512 hit points? If not we COULD steal yet another bit.

If we can snarf LSB & 1 HP bit that gives us 32 colours.

With this I think it's obvious we don't have enough bits to add a colour in the Block ID. Might have to consider the 4-byte solution.

LSB stands for least significant bit, and currently it is assigned to the blockid bitfield.