Crystal wedges, no extra IDs needed

[ltmauve]

A lot of people want wedges for lights and crystals. This has been vetoed because of concerns about block IDs.

However, if we could combine all the block shapes into one, we actually gain IDs. I have determined a method to do this that (based on what I know) works with the current system.
Pros:
> Gain plenty of IDs.
> Half-slabs added
> Better-looking terrain (since it's smooth)
> All shapes for all blocks
> You can see different transparent blocks behind each other
> Angled docking modules
> Angled gravity

Cons:
> Damage may occasionally be weird
> Future shapes will have to be added in different blocks.
> Importing to a new version will take forever.

However, this is based off of a few bits of information on the engine that Schema provided, so it might not be accurate. This is going to be a wall-o'-text post

http://starmadedock.net/threads/smedit-situation.746/page-2#post-9929
Schema made this post for the purposes of SMEdit. The bits that describe a single block are distributed like this:

Blue is block ID bits: 11 bits, 2048 possible values.
Red is HP bits: 8 bits, 256 possible values.
Green is Activation bits: 1 bit, 2 possible values.
Yellow is orientation bits: 4 bits, 16 possible values.

Now, how many orientations does each type of block have? Cubes can have 6 different orientations. Wedges can have 12 different orientations. Corners can have 24 different orientations. Pentas and Tetras can each have 8 orientations. So there are 6 + 12 + 24 + 8 + 8 = 58 different orientations. You'll notice the corner has more possibilities than the orientation bits would allow; I'm pretty sure that it uses the activation bit as well.

Here's my proposed changing of the bit allocations.

Blue is block ID bits: 11 bits, 2048 possible values.
Red is HP bits: 6 bits, 64 possible values.
Green is Activation bits: 1 bit, 2 possible values.
Yellow is orientation bits: 6 bits, 64 possible values.
Now, we condense solid block, wedge, corner, penta, and tetra into a single block. There are 58 possible combinations from that. We have another 6 orientation values we can use, so we can slip slabs in there as well.
This actually removes block IDs from use: 229 IDs are currently used for the shaped blocks.
Also, that's a heck of an inventory improvement (no need to carry five blocks for one color)

Spoiler: Additional idea that gives us even more IDs

It may be possible to have entities reference a large list with their own blockIDs, meaning that while a ship only can have 2048 different block types, there could be 65,000 blocks that you could choose from. This would be more practical with this because shape only depends on the orientation bits, not the blockID, which should reduce strain on the physics engine a bit.

Now of course, this comes at the cost of block HP. I propose this is mitigated through a change to the armor system. Currently armor goes from 0 to 99 and is calculated through( damage * (100 - armor) / 100).

Armor should go from 1 to whatever and be calculated through (damage / armor). Then add a global armor value that block armor is multiplied by. So really the calculation would be (damage / (block armor * ship armor * global armor)). However, if we set global armor to 4 in order to compensate for the loss in HP, we wind up with 1-damage cannons being worthless.
So, ships need a way of making the small stuff count. A new property called surplus will be added to entities. It tracks surplus damage that was lost due to armor. block damage =((damage + surplus)/(block armor * ship armor * global armor)) and surplus =((damage + surplus)%(block armor * ship armor * global armor)) where % is the modulus operator. This way small cannons aren't useless, and armor actually does something.

 

[El_Poulpy]

that's brilliant, that would be a wonderful change and freed some space in inventories. It could be done i think but it would need a hell of a work (long and boring) to make the conversion of the old block in the new format to keep saves of ships and stations. Only the dev team can answer.

 

[NeonSturm]

I especially like the idea with surplus.

Maybe blocks could dedicate 1-2 bits to their 2x2x2 cube to store surplus? It would make 2 guns firing at different spots with the same fire rate less random.

Or store surplus in guns? as crit dmg?

 

[ltmauve]

The surplus is data stored on the ship to prevent weak guns from being totally pointless. Let me give an example.

Global armor is 4, Ship armor is 1. I'm firing with 3-damage cannons at the ship. On my first pass, I sweep past some normal hull (armor now 4). The product of armors for that is 16. After 6 rounds hit the hull, (18 total damage) one block is damaged by 1 and the target has a surplus of 2. In order to destroy that block I need to do 400 damage (25 hp* 16). That will take 134 rounds and have 2 surplus on the ship left over. Now I shoot at a faction block, armor 100 (armor product 400). I will keep shooting at that block with the surplus rising until it breaks 400 surplus (134 shots) at which point I will do 1 damage. However, If I build up that surplus and then shoot out a light (armor 1, armor product 4), all that surplus would go into the light and blow it up.

Note that the armor values above are just conjuncture on what the new values would be.

 

[NeonSturm]

What I meant was: you have 2 guns (or gun outputs).
1 hits block X, the other block Y which are 10 blocks away from each other.

One hits block X and adds 0 dmg, 2 surplus.
The other hits block Y and adds 1 dmg, removes 2 surplus.
Repeat

Only block Y gets damaged???
That is the glitch I was talking about.

 

[ltmauve]

Yeah, I know, that's a consequence of the system. But then, when the first block is destroyed, the second block will get hit first and take damage. And honestly, in the middle of combat a situation where everyone is moving aorund, you would be unlikely to notice anything, and that problem with only one block getting damage might not be a problem.

 

[Malacodor]

I'm not sure whether Schema likes it when people mess with his bits, but I think this is a good idea.

 

[Malacodor]

Now, how many orientations does each type of block have? Cubes can have 6 different orientations. Wedges can have 12 different orientations. Corners can have 24 different orientations. Pentas and Tetras can each have 8 orientations. So there are 6 + 12 + 24 + 8 + 8 = 58 different orientations. You'll notice the corner has more possibilities than the orientation bits would allow; I'm pretty sure that it uses the activation bit as well.

Hull cubes only have a single orientation. So it should be possible to combine cubes, wedges, tetras, and pentas into one ID. This way the number of required IDs for hull blocks could be reduces by 60%. The OP's suggestion has a reduction of 80%, but mine doesn't require changing the bit pattern.

 

[ltmauve]

Hull cubes only have a single orientation. So it should be possible to combine cubes, wedges, tetras, and pentas into one ID. This way the number of required IDs for hull blocks could be reduces by 60%. The OP's suggestion has a reduction of 80%, but mine doesn't require changing the bit pattern.

Yes, but then you wind up having to have corners as a separate block. It would feel weird to only have one shape while the rest are handled in one ID. Also, if you want plexlight wedges or crystal wedges that you can turn on and off using the logic system, you need to have the activation bit free.

 

[Ithirahad]

Yes, but then you wind up having to have corners as a separate block. It would feel weird to only have one shape while the rest are handled in one ID. Also, if you want plexlight wedges or crystal wedges that you can turn on and off using the logic system, you need to have the activation bit free.

You don't need all of the shapes for crystals... Just blocks and wedges would be fine.




...Also, on an unrelated note, we finally have a definite number for how many IDs we have. Good to know, kind of puts things into perspective.

 

[ltmauve]

You don't need all of the shapes for crystals... Just blocks and wedges would be fine.

If we can do it, why not? also, this means terrain shapes as well, so better-looking terrain, also maybe weapon and functional blocks that are shaped as well, all of the decorative blocks.

 

[oninoni]

This is brilliant!

 

[NeonSturm]

Is it also possible to have one "connector/cable/switch/control block" which uses some bits to store activation status of adjacent?

If yes, it will be another choice for schema

 

[ltmauve]

Is it also possible to have one "connector/cable/switch/control block" which uses some bits to store activation status of adjacent?

If yes, it will be another choice for schema

Um, maybe. We would have 6 "orientation" bits that we could use, so one for each face.

Anyway, to everyone who points out that we don't need to change the bits to get combinations of block, wedge, penta, and tetra: you can't get the activation bit then. With this, the activation bit on the blocks would be free, so we could make crystals work with the logic system (and plexlights could get wedges and still work with the logic system.)

 

[NeonSturm]

Why not use orientation as HP too?

Current bits: 8/24 hp, 4/24 orientation, Corners use activation bit?
Sub-Blocks (while(hp<0){ remove one, hp+=hp_per_sub_block }) hp per sub-block could be 1/8 of full block hp -> 3 hp bits less used -> 7 orientation bits.

But only hard hulls requires all 8 hp bits. They would now use the logic bit as eight hp bit and lock it dependent on ID

-> +1=8 orientation bits and many more possible shapes (0.5m walls, hollow 2m walls, wedges which are wedges from top-right and bottom-left...)
-> easier build mode edit (edit as blocks, shape is chosen automatically or displayed as sub-blocks if not available...
-> IDs can overwrite behaviour for more blocky look (stairs)
-> IDs can choose to use activation bit or up to 4 orientation bits for hp additionally to their 4 bit in the new system.
-> IDs can choose to use up to 5 orientation bits as additional logic bits.

+ Everybody would be happy.

 

[ltmauve]

Sub-blocks? Stored in the orientation bits? But then you can't use them for extra shapes! The entire point of this was that you condense all the shapes into one block type. If you use the bits for HP, you can't do that. Now, the ID/blockconfig should have different shapes (or at least ways of texture mapping) Also, perhaps some shapes could use different textures based on the orientation bits (like the light poles)

 

[NeonSturm]

Sub blocks have 1/8 hp. thus you need 3 bits (8 states) less hp bits -> 3 more bits for sub-blocks.
3 0
3 3 = wedge

3 1
3 3 = penta

3 1
2 3 = opposite penta

3 1
1 3 = transition wedge left <-> wedge right

3 0
0 3 = double-wedge / ramp

0 3
3 0 = other orientation for a ramp

3 0
3 0 = 0.5m wall

0 0
3 3 = catwalk

3 3
0 0 = 0.5m higher ceiling.

3 3
1 1 = wedge on ceiling. diagonal side at front.

legend: 3: F|R, 2: Front, 1: Rear, 0: no block in that depth-line.

 

[ltmauve]

There is a finite amount of information that can be stored in computer bits. How is your system going to work when the blocks get damaged? The values start changing, which means the orientation changes, which means that some shape is going to have the least HP. I have no clue where you got "sub-blocks" from or how you think it will save information. Please do a much better job of explaining.

 

[NeonSturm]

Currently hard hull has 200 hp (requires 8 bits hp, 1/3 of the 3 bytes)

With sub-blocks each hard sub-block has 200/8 = 25 hp (5 bit).

while( hp < 0 ) hp += 25, sub-blocks -= random 1.​

You need to store a blueprint for the repair beam, but we need this feature anyway.


Just look at how many new orientations this would give (non-existing (aka wedge/penta) will be replaced by visible sub-blocks with not visible edges for diagonals).
And how much easier it would be to edit corners wedges (you add/delete sub-blocks like blocks rather than needing to orientate).

And then tell me it is not worth it.

 

[ltmauve]

Except you need to store 5 bits for each of the 8 sub-blocks. That's 40 bits. As opposed to 8 originally. The new armor+surplus system is designed to fudge the HP so that you can reduce the number of bits in HP, and then condense all of the blocks into one ID that uses all possible orientation values.