Invalid NBT tag with world minecraft 1.14

[tanaka141]

i just also launch c10t and the .png is black

with --debug option, i get this text : /home/minecraft/serveur/world/region/r.-1.1.mca(-15,47): dequeued OK

and in c10t.log, i got : "/home/minecraft/serveur/world/region/r.-1.-4.mca(-17,-116)": Not a valid tag type during 17999 lines with region and x/y changing

[tanaka141]

I have allready use c10t, and had some work on NBT tag, but never with so many change...

[udoprog]

So either it's a tag type which is not supported because c10t is rather outdated, or the region file is corrupted.

I'm not maintaining this project actively, but I'll review any changes coming in.

[evildeeds]

@tanaka141 try some hands on digging by adding

if (!(type >= 0 && type <= TAG_Int_Array)) {
    std::cout << "BAD TAG: 0x" << std::hex << (int)type << std::endl;
}

before line 411, see below https://github.com/udoprog/c10t/blob/3874582abaf3a9e71da27d70c8786176563f4f2c/src/nbt/nbt.hpp#L411

[tanaka141]

The result is : BAD TAG 0xc

As this :

/home/minecraft/serveur/world/region/r.-1.1.mca(-19,42): dequeued OK
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
/home/minecraft/serveur/world/region/r.-1.1.mca(-9,42): dequeued OK

Or this :

BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
BAD TAG: 0xc
/home/minecraft/serveur/world/region/r.0.1.mca(12,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(13,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(14,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(15,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(16,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(17,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(18,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(19,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(20,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(21,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(22,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(23,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(24,41): dequeued OK
/home/minecraft/serveur/world/region/r.0.1.mca(25,41): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-53,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-52,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-51,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-50,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-49,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-48,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-47,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-46,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-45,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-44,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-43,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-42,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-41,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-40,42): dequeued OK
./home/minecraft/serveur/world/region/r.-2.1.mca(-39,42): dequeued OK
/home/minecraft/serveur/world/region/r.-2.1.mca(-40,42): dequeued OK

Notice the point "." which appear some time

[udoprog]

So we don't have support for TAG_Long_Array.

See: https://minecraft.gamepedia.com/NBT_format

[evildeeds]

@tanaka141 nice work there with PR #306

[evildeeds]

Now that we support TAG_Long_Array we need to figure out the new map format. A quick glance suggest that BlockStates contains ids referring to the order of Palette content, also the description from https://minecraft.gamepedia.com/index.php?title=Chunk_format#Block_entity_format states BlockStates: A variable amount of 64-bit longs, enough to fit 4096 indices. The indices correspond to the ordering of elements in the section's Palette. All indices are the same size in a section, which is the size required to represent the largest index (minimum of 4 bits). If the size of each index is not a factor of 64, the bits continue on the next long.

      Compound() {
        LongArray(BlockStates): (256 longs)
        List(Palette, TAG_Compound, 3): [
          Compound() {
            String(Name): minecraft:air
          }
          Compound() {
            String(Name): minecraft:lime_concrete
          }
          Compound() {
            String(Name): minecraft:black_concrete
          }
        ]
        ByteArray(SkyLight): (2048 bytes)
        Byte(Y): 0x6
        ByteArray(BlockLight): (2048 bytes)
      }

[evildeeds]

So blocks are now referenced by a Palette Name string after lookup rather then an ID?

[tanaka141]

As explained in the wiki description, Blockstates is where all blocks informations are, but :

• in it, this is only a number which give an index to Palette
• Palette give the name of each block that is in the section
• Blockstates is a part of section which is a sub-chunk of the initial chunk
• we have 16 section in one chunk, numbered from 0 (bottom) to 15 (top)

if my english is so bad, this is because i am french, near fluent, but i miss some word to explain

[evildeeds]

Yeah but then the internal block type lookup and rendering handler needs a rewrite to support the name string scheme, plus a default pallet for old maps

[tanaka141]

Perhaps add some code with a test of DataVersion, where DataVersion < 1976, use the old system, in other case, use the new one for the rest ?

After this, the new code will be to transform all new blocks informations in the same way of the old one for all c10t code point of view

[evildeeds]

DataVersion should absolutely be used, I was thinking about implementing a new more dynamic handling for blocks and rendering mode selection before, see https://github.com/udoprog/c10t/issues/301#issuecomment-330282872, to support the old system would just load a default Pallet if DataVersion requires it. Then a color data file containing entries of "<block name>,<color>,<side color>,<boolean darken>,<rendering method>" or something similar

[tanaka141]

cool

[evildeeds]

Here is a list of Data vs BlockStates changes https://minecraft.gamepedia.com/1.13/Flattening and was apparently introduced in version 1.13

[tanaka141]

Hi,

Because i am not a long time c++ programmer (know very good PHP and Java, c++ was one of my first programming program), i needed to read all lines of this code.

What i saw during this walk around, that all are in level file (header/source) where we must work.

To do something good, i think, we must forget to make one c10t able to read all minecraft version.

The master branch must be for the lastest minecraft version, and old ones versions must be in different branch.

[evildeeds]

I think it is safe to close this ticket; @tanaka141 you did great, your changes were merged and the tag is now supported