Two blocks in the same space with only one additional byte per block

[Malacodor]

This is a combination of various suggestions, that work hand in hand. #1 and #2 are old suggestions, while #3 is new. Also, this is meant as an expansion of T1651. For a detailed explanation, see below.

1. Give shaped blocks reduced HP and mass, for example 50% for wedges.
   
2. Instead of producing all the different shapes, factories only produce block parts, which can be used to create the desired shapes when building.
3. Only allow combining blocks with the same shape and properties, for example hull and glass, but not hull and crystal armor. Treat two combined blocks as one block for damage calculation and logic, add up their HP.

Advantages:

• Door/glass and hull wedges could occupy the same space, allowing for rounded doors and windows
• More variety in hull painting
• Inverted corners could be made by combining two corners
  
• Potentially less entities, which are currently needed to combine multiple blocks in the same space

Disadvantages:

• Little flexibility regarding new shapes and colors, unless more than one extra byte is used
• People will want to combine more than two blocks in the same space
• The needed limitations could confuse players
  
• Additional work load for

1. Shape-dependent HP and mass

For shape-dependent HP we either need fractional numbers or values divisible by 12, mass is fractional already. I suggest the following changes for block HP to avoid fractional numbers:

1. Blocks with 5 system HP: Simply reducing it down to 0 would bring hull and armor in line with doors and force fields, which already have 0 system HP. Alternatively we could double all system HP, since it works percentage-wise anyway. Then an increase from 10 to 12 wouldn't be that much.
2. Change HP, system HP and armor HP values like this: 10->12, 25->24, 50->48, 75->72, 100->96, 250->252. Perhaps increase HP of standard armor from 100 to 120, I think it could need a buff.

Then the HP of the various shapes would be reduced to the following fractions:

• Wedge: 6/12 = 1/2
• Corner: 4/12 = 1/3
• Hepta: 10/12 = 5/6
• Tetra: 2/12 = 1/6
• Quarter slab: 3/12 = 1/4
• Half slab: 6/12 = 1/2
• 3/4 slab: 9/12 = 3/4

This might look like it was discouraging slopes (as stated by Sven_The_Slayer), but it would make it actually fairer. Slopes ARE already discouraged. Wedges have ~30% less HP per surface area than cubes. Wedges with 50% HP plus an additional layer of cubes had 6% more HP than a single flat (=non-sloped) layer of cubes, a significantly smaller deviation.

A diagonal slope with heptas and wedges has more HP per surface area than flat cubes IF tetras are hit, less if not. So diagonal slopes are awefully luck-dependent. This could be mitigated a lot by diminishing the role of the tetras. With heptas reduced to 5/6 HP, an additional layer of cubes and ignoring the unreliable tetras we had about the same 6% more HP per surface area than flat cubes.


2. Block Parts

Again, I try to avoid fractional numbers. Instead of producing one cube, factories would make 12 block parts instead, which would be the required number for creating a full cube when building, either manually or automatically in shipyards. Other shapes would require fewer block parts, according to the list above (wedges = 6 parts and so on). We wouldn't have to produce all the different shapes in factories, but we could simply select the desired shape when building, like it's already possible with slabs.

The icons for block parts could simply look like the current multi slot icons. This would indicate that they can be used for different shapes.


3. Combining blocks

Now comes the tricky part. There are up to 24 different possible orientations for blocks, depending on their shape, requiring up to 5 orientation bits. But if we combine two blocks, the number of possible orientations for the second block is far lower. The highest number is seven for two corners, if I didn't make a mistake. Thus we only need 3 orientation bits for a second block in the same space (1 for a third, 0 for a fourth).

We don't need additional HP bits, we just add the HP of the second block to the first one. This is possible since the combined HP will never exceed the maximum HP of a full cube, due to reduced block HP for non-cube shapes. Both blocks live and die together as one, which makes it necessary for them to have the same armor value to avoid exploits.

To get along with the promised 8 bits, we only have 5 bits left for the ID. To achieve this we need to categorize the blocks:

• Category 1 (19 blocks per shape): Hull, Glass, Glass Door, Alloyed Metal Mesh, Metal Grill, Scaffold, Ice
  
• Category 2 (16 blocks per shape): Standard Armor, Hazard Armor, Plex Door 16
• Category 3 (28 blocks per shape): Advanced Armor, Crystal Armor, Blast Door, Force Fields 28
• Category 4 (11 blocks per shape): Lights
• Category 5 (17 blocks per shape): Crystals, Ice Crystal, Ingots
• Category 6 (24 blocks per shape): Motherboards, Circuits, Charged Circuits

If we limit combinations to two blocks from the same category and the same shape, then 5 bits will suffice. If we have a hull wedge, for example, then the 5-bit-ID refers to a lookup table for category 1 wedges, of which 19 exist. For each category and shape, that exists in that category, we need another lookup table to translate the 5-bit-ID into the actual ID. Lights would share the activation bit, since we can't connect logic to subsections of a block. So with two lights combined either both are on or both are off. If that's possible, the categories 1 and 4 could be combined. Also, since the categories 5 and 6 only have cubes, slabs and wedges, it might be possible to exchange one orientation bit for an additional ID bit and combine both categories.

The biggest disadvantage would be, that we couldn't add more than a certain number of colors or patterns, only 4 in case of category 3. Also, adding more shapes would be a problem, since those might have more than 8 different possible orientations when combined (half corners, for example). And this extra byte had to be added to each and every block, no matter of it's a solo or double block, so the total block data would increase by 33%, which could be used for more IDs instead.

 

[NeonSturm]

You speak about "categories" and using bits differently based on category.
That's why I like your post!


It's all a matter of

1. how accurately you want to be able to track exactly which block and type gets killed.
   • Or if you choose the alternatives: rounding down for a 2x2x2 volume
     
     • optionally add voided damage to critical hits (on your entity, on the shooting weapon, …).
2. how much flexibility you want to provide
   • Reducing IDs from 8→4 in 2x2x2 gives 28 bits for shared HP.
3. If HP bits are stored in the block or meta-data (the block only needs 3 for 8 different damage-states: "dead + 7 lives")