Block ID shortage solution maybe

[Blaza612]

Since handheld weapons each store their own stats[the OPgun is just a rocketlauncher with a modified damage per shot tag AFAIK], pretty much all data of all the tags has to be displayed in the dropdown. Those can be many, but the number of items in the stack will be even greater[again, 500 items stack e.g.] Have fun searching for the 1 item you wish for in a stack of 499 other random items.
As for copying the data of one item over another, that would easily allow duping[a design metaitem is pretty much free if you have a shipyard. Put it onto a stack of say an OPgun, bam, 2 OPguns. Or (assuming only metaitems of the same type will be stackable), put an empty blueprint onto a filled blueprint → 2 filled blueprints.

I see where you're coming at. I don't really have much knowledge of Java and how Starmade works, been working primarily with C#, Unity and Visual Studio :p

 

[Zaphord]

Tl;Dr

If I were to suggest how to save block ID, I'd make the different color blocks of hull and armor part of the basic three or four types, not sure if crystal armor is just transparent advances armor or if it has different stats.

Basically, have hull, standard armor, advanced armor, and crystal armor with the color being a variable of that block type instead of having separate block types for each color.

Default color would be grey for hull and armor, and white for crystal armor (clear). You could then just apply paint to those blocks to get the color you want.

Could be that I'm totally wrong on this, since I have no clue how the game sorts out the different color blocks, so correct me if I'm wrong.

 

[Blaza612]

Tl;Dr

If I were to suggest how to save block ID, I'd make the different color blocks of hull and armor part of the basic three or four types, not sure if crystal armor is just transparent advances armor or if it has different stats.

Basically, have hull, standard armor, advanced armor, and crystal armor with the color being a variable of that block type instead of having separate block types for each color.

Default color would be grey for hull and armor, and white for crystal armor (clear). You could then just apply paint to those blocks to get the color you want.

Could be that I'm totally wrong on this, since I have no clue how the game sorts out the different color blocks, so correct me if I'm wrong.

I've already suggested this before and learned that it would take up too much memory in the individual blocks to be able to store all of the different types of colour. We'd need to at least get a 4th byte of data for each block which would significantly increase lag while decreasing the amount of blocks the game can handle at any one time.

 

[Ithirahad]

Not only types have to match, each metaitem also contains their own stats[in regards to handheld weapons]. Also, have fun stacking 2 logbooks with different text-content onto each other, erasing one of them :p

Remember that I was originally talking about scrap alloy and scrap composite... Those would not have any attributes that can vary from item to item. They're just unplaceable so I see no reason they should be taking up block IDs. If we were trying to stack other metaitems that actually have data attached to them, even if we could resolve the technical issues it would be strange. How, for instance, would you get the right gun out of the stack if you had several? I suppose that blank logbooks could stack, though, but their texture should change when something's written in them and they should no longer stack. Likewise with unused marker beams.

 

[Megacrafter127]

Remember that I was originally talking about scrap alloy and scrap composite... Those would not have any attributes that can vary from item to item. They're just unplaceable so I see no reason they should be taking up block IDs. If we were trying to stack other metaitems that actually have data attached to them, even if we could resolve the technical issues it would be strange. How, for instance, would you get the right gun out of the stack if you had several? I suppose that blank logbooks could stack, though, but their texture should change when something's written in them and they should no longer stack. Likewise with unused marker beams.

Scrap(both kinds) are not metaitems, the fact that they are able to stack pretty much proves it. Same goes for ores, and for that matter any stackable, but unplacable item. As for not having them use up blockIDs, as long as blockID=itemID, that can't change. However, as the itemlist uses 16bit integers, and not 11bit integers[as those don't exist in any nonexperimental computer], any itemID above or equals 2¹¹ would cause overflow when being placed. So why not leave all those IDs to unplacables, while reserving all below 2¹¹ for placable items?

 

[Ithirahad]

Yes, I know they aren't metaitems. I was asking whether or not it was possible to turn unplaceable items like scrap that currently use block IDs into metaitems, with some modifications to the metaitem system (including a system that would allow metaitems of the same type, that do not have attached attributes, to stack)

On a sidenote, didn't Schema say something about only 2^10 IDs being actually available/usable?

 

[Megacrafter127]

On a sidenote, didn't Schema say something about only 2^10 IDs being actually available/usable?

The highest ID entry in the Blocks.properties file in data/config is
"CUSTOM_ID_255 = 2047"
2048=2*2^10=2^11
2047 thus is the highest number displayable in 11 bits.

 

[Ithirahad]

Ah, okay. I thought there was some trouble with signed Java types or something, but apparently not! ^^

 

[Megacrafter127]

Ah, okay. I thought there was some trouble with signed Java types or something, but apparently not! ^^

There is, but only in native types(8bit, 16bit, 32bit, 64bit integers). 11bit fits into 16 bit without using the sign-bit.

 

[Blaza612]

Would it at all be worth converting to 14 bits? We'd reduce the junk load, allowing more IDs to be present, and aligning to even storage parameters, increasing loading speed, but I'm not sure how badly it'd reduce the number of blocks that could be present at one time.

 

[Megacrafter127]

Would it at all be worth converting to 14 bits? We'd reduce the junk load, allowing more IDs to be present, and aligning to even storage parameters, increasing loading speed, but I'm not sure how badly it'd reduce the number of blocks that could be present at one time.

And where would the 3 extra bits come from? There are only 2 possible options:

1. Take them from an extra byte, which is added. In this case, why not use the whole extra byte?
2. Take them from something else [block-hp(8-bit), orientation(4-5 bit), logic(0-1bit)].

 

[StormWing0]

I'd just go all the way to 16 bits at that point although yes you are going to have some left over no matter what you do at that point. >_>

 

[Blaza612]

And where would the 3 extra bits come from? There are only 2 possible options:

1. Take them from an extra byte, which is added. In this case, why not use the whole extra byte?
2. Take them from something else [block-hp(8-bit), orientation(4-5 bit), logic(0-1bit)].

???

What? Am I missing something here? Your're already only using 1.3 bytes, saying why not use the whole extra byte would apply to that, and increase the junk overload. There is no extra byte to add when it comes to getting 3 bits, as 8 bits = 1 byte, which would ultimately bring us up to 1.75 bytes if we used 14 bits, meaning that we don't need an extra byte, as it's already been added. The reason we don't use the whole thing, is an attempt to minimize the stress on storage all the while allowing more types of blocks, and increasing performance significantly with a smaller junk overload as well as a more aligned storage system.

I'm probably missing something obvious, but I'm 95% sure that increasing to 14 bits would be ultimately beneficial, all I don't know is how badly this would reduce the max number of blocks that can be loaded at one time.

 

[Megacrafter127]

???

What? Am I missing something here? Your're already only using 1.3 bytes, saying why not use the whole extra byte would apply to that, and increase the junk overload. There is no extra byte to add when it comes to getting 3 bits, as 8 bits = 1 byte, which would ultimately bring us up to 1.75 bytes if we used 14 bits, meaning that we don't need an extra byte, as it's already been added. The reason we don't use the whole thing, is an attempt to minimize the stress on storage all the while allowing more types of blocks, and increasing performance significantly with a smaller junk overload as well as a more aligned storage system.

I'm probably missing something obvious, but I'm 95% sure that increasing to 14 bits would be ultimately beneficial, all I don't know is how badly this would reduce the max number of blocks that can be loaded at one time.

Block data is stored in 3 bytes a.k.a 24 bits. 11 of those bits are for the BlockID, 8 for blockHP, and depending on the block, 4 to 5 bits for orientation and 1 to 0 bits for logic-state.
Case 1: 11+8+4+1 = 19+5 = 24
Case 2: 11+8+5+0 = 19+5 =24

 

[Blaza612]

Block data is stored in 3 bytes a.k.a 24 bits. 11 of those bits are for the BlockID, 8 for blockHP, and depending on the block, 4 to 5 bits for orientation and 1 to 0 bits for logic-state.
Case 1: 11+8+4+1 = 19+5 = 24
Case 2: 11+8+5+0 = 19+5 =24

Ah, I see, I WAS missing something really obvious. :p
[DOUBLEPOST=1447049866,1447049794][/DOUBLEPOST]How much does each variation of orientation take up?

 

[Megacrafter127]

How much does each variation of orientation take up?

In case of most full cubes, there is only 1 orientation, so 0 bits there.
In case of wedges, there are 3*4 = 12 different rotations (4 rotations per axis, 3 axes), so 4 bits there (2^3=8<12<16=2^4)
In case of tetras or heptas, there are 8 different orientations(1 per corner of a cube), so 3 bits there.
In case of corners, we have 6*4 = 24 different orientations(4 per side, 6 sides for a cube), so 5 bits there (2^4=16<24<32=2^5)
In case of the few cubes, which are a littlebit orientable, 6 different orientations, so 3 bits.
In case of the few fully orientable cubes, 24 orientations, like the corners.

However, taking the unused bits from case 1 and 3 and 5 and assigning them to blockID won't work, as the blockID is used to determine amount of bits used for orientation. A variable cannot be used to determine its own size, because if for some reason the next bit(outside the variable) is set, there are 2 possibilities for the size of the variable. The size it has when it would have that extra bit, and the size it would have when it wouldn't have that extra bit.
We have 2*2 possibilities:

1. The variable has size n(without extra bit)
   1. The value stored in the variable indicates the variable has size n
   2. The value stored in the variable indicates the variable has size n+1 [contradiction, as n inequals n+1]
2. The variable has size n+1
   1. The value stored in the variable indicates the variable has size n [contradiction, as n inequals n+1]
   2. The value stored in the variable indicates the variable has size n+1

When a contradiction occurrs, we will either get an infinite loop, a crash, or corrupted outcomes.
Ignoring the contradictions:

1. The variable has size n
   1. The value in the variable indicates the variable has size n
2. The variable has size n+1
   1. The value in the variable indicates the variable has size n+1

However, we can construct a sequence of bits, so that both 1 and 2 are true.
However, 1 and 2 mustn't be both true, as n inequals n+1.
Thus we will either get a crash, or corrupted outcomes.