Higher world packet interface of version 1.17+ - partially fixed

[TACGqwq]

In version 1.17+, mojang gave a packet interface that can reach a height of 2032, but now all map to obj tools can't run perfectly. Architects have a lot of grand ideas that require this higher height, so I hope you can make such a function, thank you. Thank you for your contribution to the community over the years

[TACGqwq]

My english is not good, forgive me

[erich666]

Thanks for your kind words.

Yes, in 1.17 beta Mojang allowed higher heights and greater depths, but then removed that functionality for the release. The page on 1.17 says "increased world height were removed on 21w15a, and are set to release for 1.18." Mineways supports the feature in the betas that had it, allowing a range of -64 to 319, inclusive, when those world versions are opened.

1.17.1 has a maximum height of 255, as before. I don't know anything about a planned height of 2032 - do you have a link to information on this? Are you using a mod?

[TACGqwq]

No, 2032 height is a function implemented by the data package, and no mod is used.

min_y controls the minimum Y coordinate that the terrain starts to generate, height controls the total height of the terrain generation, min_y + height cannot be higher than 2032, so its maximum value is 4064 or 4080 Click this link to view

[erich666]

Aha, I see, there's min_y and height in https://minecraft.fandom.com/wiki/Custom_dimension. Up until today I didn't know data packs even existed! Anyway, interesting feature, but Mineways certainly doesn't support data packs at this time.

I'll see if I can support this feature in a reasonable way - thanks for pointing it out.

[TACGqwq]

Thank you very much for considering your support for the data package!

[erich666]

Ugh, looking into this, the min_y and height are stored in "data//dimension_type/.json" - storing it in a JSON file (and I'm not sure which one) is no fun. It means digging these two numbers out of who-knows-where files, files that could move. I'm pretty amazed that Mojang supports this, without putting something in the level.dat file tipping the program off that these have changed for the world they're applied to (and what it means if the data pack is ever turned off).

[TACGqwq]

Yes, Mojang put it in the "data//dimension_type/.json" file, which is very unfriendly to the identification file. You can try to publish a data package adjusted to the 2032 grid height limit, only Players can only be recognized after installing this data package. This experimental feature does not need to be very general. According to my test, the world will fall back to its original default height after the data packet is deleted, and all items outside the default height will be deleted.

[TACGqwq]

Because many data packets can be added, the workload for identifying files is huge. Perhaps only by publishing a data packet with a specific path can this problem be solved.

[erich666]

Thanks for the research! Hopefully they'll figure this out a bit better for 1.18 and codify min_y and height somewhere else, better. As it is, they changed the data format for 1.18, so now 1.18 beta worlds don't read in at all to Mineways - I hope to fix that soon.

Anyway, I'll leave this one open, as a reminder, though am unlikely to touch it.

[TACGqwq]

I also hope so, Mojang should put min_y and height as options when the world is generated instead of using datapack, which is really a headache.

As far as I know, the reason why Mojang changed the data format is because they changed chunk loading method from square to round.

[erich666]

they changed chunk loading method from square to round

What? I'm not sure what that loading method is. And out of curiosity, why would that matter? Anyway, thanks for your expertise, you clearly are following this area much more closely than I am! How do you do it? Mojang announcements, some forum, following Reddit, or all of these?

[TACGqwq]

To correct it, it was changed to a cylinder instead of a circle. There was an error in my translation just now. This is an update announcement from 21W37A https://feedback.minecraft.net/hc/en-us/articles/4409293520269-Minecraft-Java-Edition-Snapshot-21w37a

[erich666]

Thanks. And, the more I think about this one, the more I'm not going to try to fix it - the feature seems way too flaky and niche. I hope that Mojang someday supports it more directly, by include min_y and height in the level.dat file itself. But, that conflicts with their current system.

I could try to have Mineways "learn" what the minimum and maximum heights are, from the data read, and dynamically readjust. But that's a ton of work for a feature that looks to be used by a tiny number of users, so I am labelling this one "wontfix" for now.

[TACGqwq]

Thank you for your answer, I will bring this news back to the community, there may be other authors interested in the feature

[erich666]

Oh, and the one good thing of note: Mineways 9.01 supports the 1.18 alpha data format (which changed from 1.17). 1.18, as you likely know, supports a height of 384.

[TACGqwq]

I have just downloaded Mineways 9.01 and I am using it now，Your update speed is really unimaginable fast

[erich666]

I noticed that jmc2obj has "Support for extended height 1.17 worlds" - not sure what all that means, but give it a try: https://github.com/jmc2obj/j-mc-2-obj/releases

If you find out it works the way you want, please do let me know! I'm happy to point people at the "competition" for this stuff.

[TACGqwq]

我注意到 jmc2obj 具有“支持扩展高度 1.17 世界” - 不确定这意味着什么，但试一试： : https //github.com/jmc2obj/j-mc-2-obj/releases

如果您发现它以您想要的方式工作，请告诉我！ 我很高兴向人们指出这些东西的“竞争”。

Yes, it can be confirmed from my actual test and his updated code that jmc2obj now supports the 2048 height world

[erich666]

Thanks! I wonder how they do it, i.e., whether they check the JSON or what.

[TACGqwq]

No, they are not checking JSON, but instead checking anvil

[erich666]

No, they are not checking JSON, but instead checking anvil

I decided to make a 1.17 world with extended height, using https://www.curseforge.com/minecraft/customization/deeper-world-and-expanded-build-height. It worked, the world has extended height and depth. I can see the chunks storing the extra data.

But, I don't see anything in level.dat or other parts of the Anvil world description files that give the minimum and maximum height values in any way for the world.

Looking at jmc2obj, I see they have a GetYMinMax() function here. From looking at that, it appears they read a chunk twice, once to determine its height bounds, the second time to fill the block data array.

This would be doable in its own right in Mineways. The main headaches is that the height slider might need to adjust its bounds if they're found to be larger than originally set, and that the offset into data could vary from chunk to chunk. It also sounds like it would slow down map loading and export - each chunk is in part read twice.

Basically, this sounds like a lot of work for a relatively obscure feature, so I'll likely pass on doing it - there's plenty otherwise to keep me busy. Also, jmc2obj does this at this point, so I'd use that. :) Really, looking over their whole system, they're doing a lot of cool stuff - you can load custom models, models from mods, textures from resource packs. If I didn't like exporting PBR textures to make USD files so much, I'd probably give up updating Mineways at this point!

[erich666]

I have a question on this feature, @TACGqwq. Does it work in 1.18? From what I see in https://www.curseforge.com/minecraft/customization/deeper-world-and-expanded-build-height, it's for 1.17 only, and there hasn't been an update for 1.18 (even though this data pack allows a larger range than 1.18 vanilla).

If this extended height feature is not a part of 1.18, it makes me question if I should bother trying to support it, since it will die out.

Update: I just read the comments on that page, sounds like this feature for 1.18 is a long ways off. Yeah, I think I'll pass on this feature, since he's received only 1017 downloads of this thing total. I tend to divide by 100 for how many actual users are interested. :)

[TACGqwq]

我对此功能有疑问，@TACGqwq。它在1.18中有效吗？根据我在https://www.curseforge.com/minecraft/customization/deeper-world-and-expanded-build-height中看到的内容，它仅适用于1.17，并且没有针对1.18的更新（即使此数据包允许的范围大于1.18 vanilla）。

如果这个扩展的高度特征不是1.18的一部分，这让我怀疑我是否应该费心去支持它，因为它会消失。

更新：我刚刚阅读了该页面上的评论，听起来这个功能对于1.18来说还有很长的路要走。 是的，我想我会传递这个功能，因为他总共只收到了1017次下载。我倾向于除以100，以实际用户的数量感兴趣。:)

He was effective in 1.18. What the comment said there is still a long way to go. It means: "1.18 adjusted the algorithm of world generation. If you want to adjust the world generation through data packets, it is equivalent to rewriting the entire world. World generation part", but I want to remind you that although the higher height is very useful for construction players, it will only be used by a small part of the population, because most people do not have such a good computer to render

[erich666]

Version 9.10 now supports extended heights, from -128 to 511. More or less. See the release notes for limitations.

[erich666]

Closing this one since it seems to be fixed. If you find there's a problem, let me know. Thanks again for working through this!