Minecraft 1.13 / MCDungeon Future discussion thread.

[JiFish]

This resource will be handy: A completely incomplete, super early preview of everything that will definitely break your maps in 1.13

[JiFish]

The above linked page has been updated.

[JiFish]

Consider marking treasure hunts as unsupported. I don't know about anyone else, but I'm worried I won't have time to keep up with 1.13's changes, let alone having to dive in to fixing new issues turning up in the hunts. Don't see a need to chuck it just yet, but a 'use with caution' may be appropriate.

[orphu]

Calling @sshipway

Do you think you'll have time to give this portion some love with 1.13?

[sshipway]

Hi - I'm still lurking on this project, though I've not had time to do anything useful due to other commitments for ages. However I've been looking at the changes for MC1.13 and there are quite a few; the functions in particular look really useful for things. It may well be possible to make the treasure hunts strict in survival mode (IE, like locked chests in adventure mode) somehow now. I might be able to spend some time on this in December/Jan the way things are going now. I'm going to have to recreate my whole devleopment environment again, I'm so far behind... One thing that would help would be to ass a 'THunt' tag in the issue tracker to help track specific treasure hunt problems.
I know that the landmark rotation code will have a lot of issues under 1.13, from what I see in the changes list, but the new functions could make it easier to do.

[JiFish]

It may well be possible to make the treasure hunts strict in survival mode (IE, like locked chests in adventure mode) somehow now.

That's been possible for a while! :) Just replace the treasure chest with a shulker box. If you mine a shulker box it just drops the box, not the items inside. Making the key a necessity.

a 'THunt' tag in the issue tracker to help track specific treasure hunt problems

Great idea. I'll add it.

[sshipway]

Im finally with some free time, and have re-set-up the development environment.
To get myself into the mood I've first updated the dynmap-mcdungeon plugin for Bukkit to the latest version and made it support the new YAML-format cache files -- all is working in v2.1.

Will start on the numerous treasure hunt bug reports shortly...

[orphu]

Awesome!

[JiFish]

Has anyone tried running it at all with the most recent snapshot? I was wondering if the block ID changes from 17w47a changed the way block data is saved to disk? Since one of the change notes is "The upper limit of the block ID has disappeared." and I'm unsure how that's possible without a change to the chunk format.

[orphu]

Looking bad! Our version of pymclevel / nbt.py can no longer read the chunk format. This is a freshly generated 1.13 world on snapshot 17w50a:

MCDungeon 0.18.0 startup complete. Chunk cache missing, or is an old version. Resetting... Finding good chunks: Pass 1: 100%[========================================================>] 0:00:00 Pass 2: 0%[> ] TBDException in main loop. Exception info below: Traceback (most recent call last): File "mcdungeon.py", line 2177, in sys.exit(main()) File "mcdungeon.py", line 1936, in main (cx, cz, result, biome, depth) = classifyChunk(c) File "mcdungeon.py", line 531, in classifyChunk chunk = world.getChunk(cx, cz) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\infiniteworld.py", line 1486, in getChunk chunkData = self._getChunkData(cx, cz) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\infiniteworld.py", line 1448, in _getChunkData root_tag = nbt.load(buf=data) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 519, in load return _load_buffer(try_gunzip(buf)) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 543, in _load_buffer tag = TAG_Compound.load_from(ctx) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 298, in load_from tag = tag_classes[tag_type].load_from(ctx) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 298, in load_from tag = tag_classes[tag_type].load_from(ctx) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 438, in load_from tag = tag_classes[self.list_type].load_from(ctx) File "C:\Users\T\Documents\src\mcdungeon\pymclevel\nbt.py", line 298, in load_from tag = tag_classes[tag_type].load_from(ctx) ChunkMalformed: Chunk (-62, 39) had an error: KeyError(136,)

[orphu]

Related info:

https://minecraft.gamepedia.com/Talk:Chunk_format#1.13_chunk_format_changes

There's a new tag (long array).

[orphu]

Looks like the great block ID change is happening in 1.13. Old numerical data values are no longer supported. Lots of stuff has been split into separate blocks. We will definitely need to finally find a new way of loading/saving maps. Either write our own or update pymclevel.

Lots of blocks will change, and materials will need to be reworked.

More discussion:

https://minecraft.gamepedia.com/1.13/Flattening

[JiFish]

Old numerical data values are no longer supported.

I've been trying to get a hard answer on what this actually means for years. Obviously IDs are completely hidden from users. But presumably numerical IDs must still be used when saving chunks to the disk? (Otherwise the size of chunks would balloon massively.) So does that mean that the saved-to-disk IDs are no longer consistent from save to save? Is it some sort of dictionary approach? Or are IDs untouched, just never referenced via commands?

As per usual, the official Mojang changelogs are useless for finding this information.

MCEdit appears to be pushing forward with an update, so hopefully we can still pull those changes in (despite their extremely disappointing choice to no longer treat pymclevel a separate component.)

Depending on the answer to my first question, it looks like it's going to be somewhere between a lot of work and an impossible amount of work. :/

[orphu]

I'm sure details will begin to surface. Most things that read maps appear to be broken now.

From what I can tell, the biggest change is that block IDs are now mapped from an numerical ID on disk to a string ID on load. Each chunk contains a small lookup table that maps the ID used in the chunk to the string ID equivalent. This means that there are virtually an infinite number of block IDs, and the actual IDs used on disk can change from chunk to chunk.

Also, all the block variants that used to be defined by a data value have been converted to a unique block ID (since there are no longer any restrictions on the number of block IDs).

Info on removing data values and converting to unique block IDs:

https://bugs.mojang.com/browse/MC-121742

EDIT: Also, several block entities are removed and replaced with a unique block.

[orphu]

https://www.reddit.com/user/Dinnerbone/comments/6l6e3d/a_completely_incomplete_super_early_preview_of/

Key bits:

• There is no such thing as item data value or item damage value in 1.13
• Damage, where applicable, is being moved into nbt
• Any other information is either a separate item or a property in nbt

[orphu]

The key part of the disk format change is in my comment above linking to the talk section in the wiki on chunk format changes.

The Sections list in the chunk removes Data, Add and Blocks (Byte Arrays) that used to contain numerical block IDs, DVs, etc, and adds an arrays called BlockStates (Long Array) and Palette (List Array). Y, SkyLight, and BlockLight remain.

Palette lists all block states that exist in the section. (Up to 4096 unique blocks for each 16x16x16 chunk section-- this is where "unlimited" block IDs comes from. Block IDs are now defined per chunk section). Each entry is a compound tag with the string ID name of a block, plus a compound with any properties. Index zero is always air, even if there is no air in the chunk section.

BlockStates Contains the actual block data, but maps these as the index ID from the Palette array.

Worth noting that a long type array (type 12) is new to the NBT format, so any NBT libraries will need to be updated to read this.

[JiFish]

Unfortunately, I haven't had much time to look at this and I probably won't have any for a while.

It does look like MCEdit-unified does now support the new long array type: https://github.com/Khroki/MCEdit-Unified/commit/ee5b8b96eeb7efc189e6cd5a062b27c54f33212b#diff-0ffe815f4c80de07e690db505e92eac3 So maybe those changes can be pulled in?

[JiFish]

I was hoping to pull in MCEdit-Unified's version of pymclevel to see just how complicated it would be to get the code running on Minecraft's 1.13 snapshot. Due to lack of time - and waning interest in Minecraft among my friends (one of my primary motivators for working on MCDungeon) - it's simply not happened.

If anyone out there is looking at getting MCDungeon running with 1.13 snapshots, I'd suggest this is the place to start.

[JiFish]

Minecraft 1.13 pre-releases have started.

[orphu]

Real life job/life has been bonkers for a while now for me, leaving little time for personal projects. I'd really like to dig into this refactor at some point, but it won't be soon.

[JiFish]

Understood.

Might be worth putting a warning here an on the forum that it is definetly not compatible with 1.13. Other than that, people will just have to wait.

[MikeyCarter]

Just wondering if you guys were thinking of using structure blocks and functions for 1.13. with functions at least ... don't have to take the server offline to implement a new dungeon. ;)

[JiFish]

with functions at least ... don't have to take the server offline to implement a new dungeon

That would require much of the software to be rewritten. So I doubt that will ever happen.

At this point I wouldn't even hold my breath for a 1.13 compatible version, let alone one that uses 1.13's whistles and bells. Without a 1.13 compatible version of pymclevel, it going to be an insane amount of work just to get it running again.

[JiFish]

I've pinned some issues, edited README.md and the 0.18 release to provide notice that MC1.13 is not supported. Just a note to remember to clean this up if development ever resumes.