1 byte for 8 sub-blocks (shape) and byte-logic

[NeonSturm]

2*2*2 = 8 blocks = 8 bits = 1 byte.

Can it be freed for different tasks per block category?

I am talking about

• the ability to make a block with 8 possibly 8 smaller sub-blocks.
  • full-blocks, wedges, corners, ... not needing different IDs or orientation bits - you make them by using different numbers and arrangement of sub-blocks.
  • a 1m thick floor inside a 2m thick wall, just by sub-block arrangement.
  • more details with blocks that do not convert into wedges.

• The ability to create logic blocks for 1 byte instead of 1 bit.
  • (0101'0101 -> and (0101'1010 sub blocks) -> 0101'0000 signal)
    
  • This would greatly reduce the block count of more complex systems (and memory requirements).

#1
This suggestion is about how shapes are created - maybe a breakthrough in advanced build mode (speed of editing wedges, make corners without rotating)


#2
This is not necessarily a suggestion to add a forth byte to each block, but to use orientation, activation, some-hp bits differently for different block categories (Logic, hull, deko, ...)

Logic:

8 sub blocks are 8 bits. Maybe saves one or the other redundant circuit, saves memory/blocks and speeds up processing of many same-complexity-circuits​

Hull, door:

for shapes (+ losing hp = losing sub-blocks = losing shape gradually)​

Structural full-block:

use bits for: injected power stripes, reinforced, injected shield, injected lamps (1 bit for r, 1 for g, 1 for b), ...​

Computer/Display full-block:

3 bits direction, 5 bits for type, active, ..something..else..​

Conclusion:
ID bits define how HP, activation and orientation bits are used (different code branches for 4 categories Logic, Hull/door, structural/internal block, computer/display)

 

[Calbiri]

I dont claim to know exactly how the bits are used all the time (I dont code and sometimes converting to binary logic trips me up)
Doesnt 3 bits of information, taken seperately only acheive 3 possible sub-bits (not the multiplicative 8 bits if you considered them in tandem)?
Also, another unfortunate issue is that an entire byte per block is dedicated to the location of the block (not its orientation) within the mesh/grid or whatever you prefer to call it. This means that using 8 sub-bits, while reducing the data cost per block by 7/8 bits, is still increasing that data by 8/8 bits (i think??)
Its a cool concept, and i have suggested microblocks to schema in the past to try to get more shapes for the same or less data, but apparently its not as straight forward as i had thought. I know some players may mention a certain Space game that uses a set of small and large blocks in the building of their voxel ships, but in essence, their small blocks are the same as ours, with a giant astronaut running around (and the large blocks are essentially the same as our "mass place" advanced build cubes) In the end, it would be great though, wouldnt it, if we could get more detail while at the same time reducing data usage? Here's to optimism!

 

[NeonSturm]

We need 6 (primary side of a block) * 5 (secondary side) = 30 options = 5 bits for orientation.
If blocks need either activation or orientation, but not both, we have a 6th bit.
And we get 2-3 bits from hp (on average 4 sub-blocks = 2*2 = 2 bits. 8 sub blocks: 2*2*2 = 3 bits).

So we can get 8 bits, maybe 9.
The functionality given by these 8-9 bits will be restored in how we use blocks.


We would have double-pentas, blocks which allow thin floors/ceilings or walls, double-wedges /aka thin ramps) + still full orientation & hp (you lose sub-blocks by taking damage, may need advanced blueprint-restore stuff, but we need that anyway)
But we would not need orientation - we just add and subtract sub-blocks which also change the shape (and add hp)


Most blocks which need activation bits do not need the full set of shapes.

• Exception: For plex-doors & lamps, that would mean that activating them
  1. toggles the 1-bit in their ID (one for open and one for closed)
  2. take another (a third) hp bit or the 9th bit (lamps+doors+wedged computers would not be the most resilient blocks and remember that we needed 2-3 hp, but 8 sub-blocks are worth 3 bits)

All full-blocks which don't need orientation take profit from 8 (not 9) possible states.
Rotate-able full-blocks only need 3 bits and still have 3-5 left

• In exchange for having 2 bits less hp, thus having a maximum of 63.
• But with the new hp system vital blocks never have more than 50. (You can still increase armour or use on these block types a damage multiplier which not affect punch-through/pierce)

You don't lose any bit

• You gain many options and sacrifice one possible case.
• Not possible would be: >127 hp without >4/8 sub blocks while 1 active bit is used and when you don't want to increase armour instead.
• Not possible too would be using all 8 bits AND orientation | >63 hp, but logic blocks don't need orientation or more than 63 hp (as sub-blocks on these need to be locked for individual edit or damage).

Possible would be 3 bits orientation, 2 hp and 5 activation for computers.

That was the suggestion. Use 8 bits differently depending on block ID (block category).


Imagine:

1. Logic-LED: block access bit-mask of (&0000'0111 == 7) = (1 bit for each of r,g,b) Now logic could set color white, red, green, blue, red+green, ..., off -- but an enabled logic bit-mask disables sub-blocks.
   
2. Crystals: Shape-able (sub-blocks) with a disabled bit-mask of (&0000'0000) always on
   
3. Shape-able lights (1 ID each color), scarifies 1 HP bit for on/off state.

 

[Qweesdy]

Also, another unfortunate issue is that an entire byte per block is dedicated to the location of the block (not its orientation) within the mesh/grid or whatever you prefer to call it.

Um, what?

You're saying that to find the block at (x, y, z), which is something that would happen extremely frequently (every time any block is added or removed/destroyed or damaged or ...), the game has to search for a block with matching location data and can't do anything fast (like "block = chunkDataArray[x][y][z]")?

If this is what you're saying; then the game is a hideous pile of shit.

 

[NeonSturm]

No. He meant that my suggestions uses 1 byte (8 bit) to see which of 8 sub-blocks are set. But that is not as bad as it sounds, because you save

• 5 bits for orientation
• 3 HP bits by assigning HP to single sub-blocks and storing only 1 HP value, which can be drained up to 8 times - killing a block each time it reaches zero.

 

[WaffulMann]

Bump for sub-blocks since I don't want to create another thread.
On the subject of small blocks, maybe the game could:

1) scan normal areas for small blocks, like how they do it with plexstorage, only on a smaller area
2) don't use 8x IDs for the rest of the blocks
3) I don't see any FPS dropping apart from it loading it in initially, an people who don't use small blocks can act as if this was never a thing.
4) Hp would not be required for each individual block. One shot would destroy the entire 1*1*1 block and every 0.5*0.5*0.5 block inside that block, and I'm 97.37% sure no one would notice since a) debris would be everywhere and b) You wouldn't notice an extra sub-block missing when half your ship has been torn off.

Though I'm not sure how memory works so this may be completely wrong.
I don't see why logic would be needed in small crafts, so maybe that could be a thing that can only be used in "normal sizes". That would also save a lot of 20th century-era computers.