So we officially need a bigger block ID already :D

[Cervator]

With his latest shipment of snazzy blocks metouto has officially rolled over our puny byte-based block ID - I was wondering where all the leaves went

... "Sandy":126, "Silty":127, "DarkLeaf":-128, "GreenLeaf":-127, "RedLeaf":-126]

(non-technical explanation real quick: A Java byte can hold 256 values, but is signed so they range from -128 to 127 and you can roll over from 127 to -128)

I figure we could fix up the code to where we can use negative IDs real quick, but that doesn't buy us much time anyway with the rate new stuff is coming in. So I think it is time to revive the block ID and metadata discussion - relevant threads:

viewtopic.php?f=4&t=173 - data type and block metadata mention
viewtopic.php?f=4&t=242 - block dynamics
viewtopic.php?f=4&t=171 - block integrity

The issues has been raised on how we easily extend per-block data storage via mods. I was hoping to eventually just use the existing TeraArrays to power some interesting contents, but certainly hope we can use something even snazzier eventually.

So how do we do it and is anybody burning to do it now? Metouto can keep making more blocks, but the world in his branch will start missing more and more pieces!

 

[eleazzaar]

I'm not a coder, but from my experience with mine craft, i had some ideas how to make blocks from different mods worked together. I haven't installed a Mincraft mod since 0.7 or so. These thoughts are born from my frustration with the awkward way mine craft then dealt with multiple modded blocks

Mod blocks wouldn't claim block IDs directly. They would have a unique ID (or something long enough that it could plausibly be unique). Like if i was a modder, i might make "EleazzaarsMod-block1" and "EleazzaarsMod-block2". The mod internally would refer to it by it's long name.

However, maps need much more compact names. Let's say you reserve half of the block IDs for mods. Each world will have a list (lets call it the manifest) of modded blocks and the ID number they are assigned in a world.

When a player attempts to add a mod block to the game, the game will check the manifest, to see if that block has already been given a block ID in this world. If not, it will be assigned the next block ID. Maybe "EleazzaarsMod-block1" gets block ID 256. But 256 won't necessarily be the same thing in another world, or on somebody else's computer. And that block ID isn't even taken until i actually place such a block.

* The point is that you only had to reserve enough block IDs for however many modded blocks the player will have in a particular world-- Not enough IDs for all the modded blocks available on the internet.
* Conflicts between block IDs are very unlikely, if modders follow the practice of prefixing their long blocks names with their mod name or nick.

And for the failing gracefully part: Suppose somebody installs "Eleazzaar's Mod", places a few blocks, and decided the mod is junk-- and deletes it. Now there are block ID 256's in the world without the mod that describes their properties. The game could have an "Unknown Block" texture something obvious with a "?" on it. All "Unknown Blocks" could be destroyed with 1 hit. Still the player could re-install "Eleazzaar's Mod", since the 256 is linked to a particular block in that mod, and the block would be as if the mod was never uninstalled.

 

[Immortius]

Sorry eleazzaar, that is more or less how things already work.

The concern is more that we don't have enough ids for what seems like a typically modded game. 256, -1 for air, with some blocks using multiple ids for rotations and variations. The suggested bookshelf with 17 variations from empty to full, if it can be rotated 4 ways, uses a quarter of those ids alone. Switching to a short gives us plenty (probably too many) at the cost of double memory usage for chunks. Obviously there are some tricks like inferring block rotation from context that would save some ids, but those come at the cost of control.

A slightly different selection regarding what to do when a mod is deactivated, each block could have a fallback core block it can act like when its mod is unavailable. This information would have to be saved with the world.

* Conflicts between block IDs are very unlikely, if modders follow the practice of prefixing their long blocks names with their mod name or nick.

This will be enforced even.

 

[eleazzaar]

Sorry eleazzaar, that is more or less how things already work.

That means the idea is good

 

[ironchefpython]

The concern is more that we don't have enough ids for what seems like a typically modded game. 256

Maybe I'm overly ambitious, but I would be very disappointed in a world with only 256 types of blocks in it. Even 65,000 might be too limiting, if each combination of material, orientation, state, etc. required a unique block id.

at the cost of double memory usage for chunks

Well, we do have some opportunities there. We can look at ways to reduce memory usage in ways that minimally degrade serial access at the cost of slower random access. Even something as basic as RLE would reduce world memory sizes for most chunks by a couple orders of magnitude. Adding a per-chunk block mapping dictionary with Huffman encoded keys is another possibility.

But it's easier to simply go to a short, and hope that by the time TS is done, every has gotten a memory upgrade.