Block ID shortage solution maybe

[Raisinbat]

Ok so there's about a 1% chance Schine hasn't thought of this and about a 99% chance i'm just too clueless to understand why this won't work, but in the spirit of unlikely scenarios i thought i'd post a suggestion on how to resolve the limited block ID's.

I'm not a real programmer though, so a large reason for me posting this is to get some insight into what I'm not understanding if it sucks, or what alternatives are more desirable. It's probably a shitty suggestion and i'm just curious. :p

• Keep a master ID list for all blocks and make it any size
• Each entity belongs to a separate ID list limited to 256 IDs

With several entities sharing the same ID list; for example all asteroids would belong to a single ID list as would planets, and spawning multiple copies of the same blueprint they should all belong to the same list as well.

I don't know how this will affect rendering though, or really what any of the other pitfalls are, would just like to hear some discussion on the topic, and i think it still belongs in the suggestion forum, despite its dubious value.

 

[Ithirahad]

If I understand your idea correctly, that means no more building bases on planets because bases would use ship blocks (Planets would use the same values for other things), and no more asteroid materials as floors because they belong to asteroids. Whut?

 

[Raisinbat]

Sorry that isn't worded very well; there would be lots of lists, as you build on planet/asteroid it gets a new list with the ids of the blocks you add until you add 255 types of blocks, then it wont let you add anymore

EDIT: Sorry for the quick edit, but think i overcomplicated how the lists were made. Basiclly every entity has a unique list associated with it by default, but entities that CAN use the same list should.

 

[Ithirahad]

...Well, but that's not how voxel grids work... They HAVE to draw from the same 'list' because each voxel is, in essence, just a list of values that fits inside an allocated amount of information per space in a 3D coordinate array. Block ID is just one segment of this amount of information in each block.

 

[Raisinbat]

I don't know anything about voxel grids and I don't quite understand what you're saying. What prevents the list of block IDs from being unique to each entity? I'd assume each entity has its own voxel grid, if that's not the case then yeah this would be impossible.

 

[kiraen]

You're talking apples and orangutans.

The BlockID list is all the types of blocks you have in your bucket.
The entity is what you actually build with those blocks. They all use the same bucket.

If we have a separate ID list for each entity, we end up with multiple non-interchangable blocks. A shield for ships, shield for stations, shield for planets, etc. This would bloat the database and completely defeat the purpose.

Further, another byte would have to be used to tell the game which type of entity each block belongs to. That means an added byte per block to every entity. Making the data that needs to transfered and shared increase significantly, causing more lag locally and increasing server load and choking bandwidth.

This second point is actually why blockIDs are limited to begin with. Increasing the number of blockIDs would mean adding another byte. A single byte doesn't really sound like much when we have tarabyte drives and gigabyte bandwidth, but just think about how many thousands of blocks are in the new starter station alone. Now add in the blocks for planets, asteroids, pirate stations, trade guild and pirate ships....and now you need to build your own ship.

A sandstorm is only made of grains of sand.

 

[Raisinbat]

If we have a separate ID list for each entity, we end up with multiple non-interchangable blocks. A shield for ships, shield for stations, shield for planets, etc. This would bloat the database and completely defeat the purpose.

So close but i think i still haven't explained it right. I drew this incredible graph to illustrate what i mean:

... just means more; each ID list would be 256 items i think. They would not refer to different blocks and there would be a fuckload of redundancy, that's absolutely true, BUT! This way, as far as i know:

• the masterlist can contain any amount of blocks, only the entity lists would be limited
• all blocks are contained in the masterlist, entity lists are subsets containing elements from the masterlist
  
• There would be no difference in data per block; the entity list is kept as a seperate object with a reference from each entity to whatever list it belongs to
• Many entities with different setups belong to the same list; you dont need the 256byte list saved on each ship.

As for how lists get edited

• When you add a new block to a ship, the list it belongs to is checked to see if this block is allready on the list, if not it's added
• If the list is full, check if the ship uses all the blocks in the list; if not a new list is created and the blocks not on the ship removed from the list. If all the blocks are on the ship, the ship uses 255 unique blocks and no more new block types can be added.
• If no entities are linked to the list, the list is removed

There's probably more stuff needed for it to actually work, but this was what i had in mind. Sorry about the bad explanations

 

[kiraen]

The limit to blocks is in the master list.

 

[Raisinbat]

The limit to blocks is in the master list.

And why does this need to be limited? A block in entity A can have ID 5, which means shield capacitor in entity A's ID list, while entity B can have a block with id 5 which is mushrooms in entity B's ID list.

No entity actually refers to the master list, they all refer to the other lists so there should be no need to limit this.

Sorry if i don't get what the problem is, i have very little understanding of voxel engines, but from what i know each block ID just looks up the block from the masterID currently with a function looking something like

function(id1 entity1 id2 entity2)
dostuff(getblock(id1),getblock(id2) entity1 entity2)

instead of

function(id1 entity1 id2 entity2)
dostuff(getblock(id1,entity1.idlist),getblock(id2,entity2.idlist) entity1 entity2)

I don't see a conflict in having different blockIDs for each entity. Is there some functionality that demands two entities have the same IDs for blocks?

 

[Blaza612]

And why does this need to be limited? A block in entity A can have ID 5, which means shield capacitor in entity A's ID list, while entity B can have a block with id 5 which is mushrooms in entity B's ID list.

No entity actually refers to the master list, they all refer to the other lists so there should be no need to limit this.

Sorry if i don't get what the problem is, i have very little understanding of voxel engines, but from what i know each block ID just looks up the block from the masterID currently with a function looking something like

function(id1 entity1 id2 entity2)
dostuff(getblock(id1),getblock(id2) entity1 entity2)

instead of

function(id1 entity1 id2 entity2)
dostuff(getblock(id1,entity1.idlist),getblock(id2,entity2.idlist) entity1 entity2)

I don't see a conflict in having different blockIDs for each entity. Is there some functionality that demands two entities have the same IDs for blocks?

The problem is that you're proposing a suggestion that's meant to solve one problem (having a limited amount of block types/IDs) while creating a solution to a different problem that doesn't exist. :p

 

[Raisinbat]

The problem is that you're proposing a suggestion that's meant to solve one problem (having a limited amount of block types/IDs) while creating a solution to a different problem that doesn't exist. :p

Nope still don't get it. You can have 20.000 ID's in master list (More ID's) This way the limited number of blocks would be moved so you can have 255 unique blocks per entity, with each entity having a different 255 blocks that are unique to it. Having 2000 different cosmetic blocks would be doable, you just can't put them all on the same entity. Am i misunderstanding the problem?

 

[Blaza612]

Nope still don't get it. You can have 20.000 ID's in master list (More ID's) This way the limited number of blocks would be moved so you can have 255 unique blocks per entity, with each entity having a different 255 blocks that are unique to it. Having 2000 different cosmetic blocks would be doable, you just can't put them all on the same entity. Am i misunderstanding the problem?

It appears you are misunderstanding the problem. The problem is that the master ID list has a limit. The reason it has a limit is because each individual block has to account for all of the possible types it could be, which are determined by the types. At the moment, they take up 3 bytes each, which accounts for the ID list, logic, and something else (can't remember) and if we want to increase the limit, then we'll have to add another byte for each block, which would lower the amount of blocks that can be present before problem happen, however the game will run faster/more efficiently when it isn't at that point. The thing that prevents us from adding this fourth byte, is the fact that the game is already getting to that point, without having the lowered limit, so adding that byte would cause major problems for anything that currently exists, and the scale in general will have to be knocked down significantly.

 

[Raisinbat]

The reason it has a limit is because each individual block has to account for all of the possible types it could be

Which is 256, because the types are specified by the entity's own ID list, NOT the master list. The master list's ID's are only used by the entityID lists when they're updated. Come to think of it i'm not sure the masterlist would need to contain ID's at all, although it's probably easier when looking up blocks to update entityID lists.

It appears you are misunderstanding the problem.

And i still am

 

[Blaza612]

Which is 256, because the types are specified by the entity's own ID list, NOT the master list. The master list's ID's are only used by the entityID lists when they're updated. Come to think of it i'm not sure the masterlist would need to contain ID's at all, although it's probably easier when looking up blocks to update entityID lists.



And i still am

That still wouldn't work. The blocks would need to know what kind of block they are in the first place in order to add it to the entity list, thus making them rely on the master list still. Either way, the problem exists strictly with the master list and the individual blocks memory usage.

 

[Ithirahad]

The limit is not 256, it's 1024... Also, the 3 bytes accounts for rotation, block health/damage, the ID, and the on/off state for logic. (On/off state and some of the damage values are sometimes co-opted for other things, but that is besides the point)

 

[Raisinbat]

That still wouldn't work. The blocks would need to know what kind of block they are in the first place in order to add it to the entity list, thus making them rely on the master list still. Either way, the problem exists strictly with the master list and the individual blocks memory usage.

Ok here's something i hadn't thought about. When placing a block it comes from the inventory though, inventory items don't need to be blocks until they're placed. If the masterlist's IDs are used for inventory items that are then placed, isn't it possible to check if the masterlist's block for that ID matches one of the blocks in the entitylist? (Running of the assumptions that inventories dont have to worry about the same limits, i know minecraft has seperate itemID and blockID)

something like For A( if lookup(masterlist,ID) = lookup(entitylist,A) return true, if A = 256 return false)

That would let you assign new blocks to the entitylist i think. Removing is trivial and not sure if there is anything else that's missing.

Thanks for schooling me on this stuff :p

 

[The Judge]

I think you can add more ID's to the game, but performance will be severely affected and 32bit won't work.

A.K.A as RIP Laptops

 

[StormWing0]

I'd just use a SQLite DB and call it a day, different table for each of the needed information if additional tables are even needed. Than setup a super faster searching code and just sit back and watch. Does have some overhead but if setup right you only search it once or twice normally only when new entities are made since the game would keep track of created entities and their blocks they have.

 

[Megacrafter127]

and 32bit won't work.

False. The JVM will ensure types of more than 32bits will be composed of smaller types, when needed.

I'd just use a SQLite DB and call it a day, different table for each of the needed information if additional tables are even needed. Than setup a super faster searching code and just sit back and watch. Does have some overhead but if setup right you only search it once or twice normally only when new entities are made since the game would keep track of created entities and their blocks they have.

I don't know if SQL databases are fast enough to serve this purpose.

The blocks would need to know what kind of block they are in the first place

Does "Blaza612" define every property of you? No, it is just a pointer, that is used when people are referring to you, but don't want to list up all properties of you(most of which they probably don't even know or care about). An ID has the same purpose, it is a pointer at what has the ID, so everyone interested in it knows where to look it up. The "master list"(which contains all blocks AND items right now) uses 16bit integers, and not 11bit integers for IDs.(although no currently used ID exceeds what could be stored in 11bits. In addition, 11bit integers don't 'naturally' exist in almost all current computers, so internally 16bit integers are used, whenever calculation with the ID is required)

On another note, all the entity's list would need to do, is linking 1 internal ID to the external ID[used in the "master list"].
However, all those lookups will likely slow the game down. And redundancy is ALWAYS bad. The more redundancy there is, the more likely it is, that the database will fail due to stuff, that is supposed to be the same, being different.

 

[StormWing0]

I don't know if SQL databases are fast enough to serve this purpose.

I would say Big Data Database but that's true Overkill at that point and it'd take too long to setup. As for how to make a SQL DB super fast I'm going to have to look that up again since I haven't been programming in a while.