minecraft-dotnet/Substrate

Blocks dont support ID higher than 256...

privjacinta opened this issue · 11 comments

The current anvil standard has block ID up to 4095 supported.

From http://www.minecraftwiki.net/wiki/Anvil_file_format:

The maximum Block ID has been increased to 4096 (was 256) by adding a 4 bit data layer (similar to how meta data is stored).

While vanilla still dosent use the extended range, a number of the mod communities do....

Yes, this is a pretty outdated way of handling blocks. I'll see if this can be resolved without too much pain.

Some extra info ...

Each section also has a “AddBlocks” tag, which is a DataLayer byte array just like “Data”. The “AddBlocks” tag is not included in the converter since the old format never had block ids above 255. This extra tag is created whenever a block requires it, so the getTile() method needs to check if the array exists and then combine it with the default block data. In other words, blockId = (addBlock << 8) + baseId.

Fortunately everything is hidden behind an IDataArray3 interface, so this could be solved by just adding another layer. On the downside it's a little slower now. Maybe that can be solved in the future by not assuming the raw NBT data is the underlying data store.

I've pushed a new changeset, see if that works out for you. It seems to be doing the right thing in the limited testing that I did.

Looks Good.

A couple of minor things.. In FusedDataArray you are shifting by the datawidth of Array0 in the getters, but bitshifting by the datawidth of Array1.

I believe this should array1 in both cases

public int this[int x, int y, int z]
{
get { return (_array0[x, y, z] << _array1.DataWidth) + _array1[x, y, z]; }

public int this[int i]
{
get { return (_array0[i] << _array1.DataWidth) + _array1[i]; }

And possibly not related, but since using this patch, having an issue with SpawnData not being in the _tags Dictionary with TileEntityModSpawner (line 115).

Good catch, it's a bug.

As for the other issue, do you know the last changeset or tagged version you were using where this wasn't a problem?

the tagged release 1.3.6. All run it against it again just to confirm and let you know.

Confirmed 1.3.6 runs without the TileEntityModSpawner Issue.

P.S. Running on a fairly heavily modded world file, so may be that as well..

Okay, I think i understand the issue now. There was a contribution augmenting TileEntityMobSpawner that recently got merged in, and while it correctly flags the data as optional in the schema, it does not check to see if it exists before trying to load it. I'll get to it later tonight, but it should be an easy if/containsKey fix if you want to get running sooner.

I have the IDs working correctly. thanks very much. I did make some other tweaks, which I will share with you (once I get back home). Mostly around the Tag name. But I dont know if the tag im using is Forge only, or the base minecraft one :)

Fixes for both issues should now be checked in.

For a "Forge" world (one using forge based mods) the "AddBlock" node, actually needs to be "Add". This node dosent exist in the Vanilla build minecraft world.

But at least for me the code is working perfectly and allowing easy access to block id's.