A bit of background:
Custom dimensions can be defined by adding a file to a datapack with the path
data/NAMESPACE/dimension/DIMENSION_NAMEWithin this file are two keys "type" and "generator".
The "type" key defines the height of the world along with some other data.
There are two ways of defining this key.
One way is to define it as a compound tag which simply contains the data.
The second (and I believe preferred way) is to define this as a resource identifier which refers to another file at the path
data/NAMESPACE/dimension_type/DIMENSION_NAMEwhich contains the previously mentioned compound tag.
The issue is that the contents of the first file are embedded in the level.dat file exactly as it was defined.
For the first case outlined above this is perfectly fine. The level.dat file contains all the required information for the dimension to exist. If the data pack is deleted the level is still accessible.
In the second case the height settings are not embedded in the level.dat file. I assume the game has to load them from the data pack each time. If the data pack is deleted in this case the game does not have enough information to fully define the dimension and the player gets kicked back to the overworld and the custom dimension is inaccessible.
The solution to this is if "type" is a resource identifier, load the dimension_type data from the file and embed it in the level.dat file instead of the original resource identifier.
level.dat file snippet created with the first method (compound)
[media]The level.dat file created with the second method (resource identifier)
[media]
Attachments
Comments 4
I hadn't considered being able to modify the data pack after the world has been created. I don't know if this behaviour is supported or if it is just a quirk of the system.
For most of the settings this is harmless such as the generator settings which will only take effect on newly generated chunks.
The major issue is the minimum and maximum height values.
Most of the chunk data is sub-chunk (section) based with fixed altitudes so this does not matter but the biome data is stored as one array for the whole chunk.
Changing the min_y after the chunk is generated will change which sub-chunks the biomes relate to and changing the height will mean a different size array would be expected.
I assume the plan is to move the biome data in with the sub-chunk data to remove this issue. I don't know why that hasn't been done already.
I can't confirm this issue. For you (gentlegiantJGC), does this issue still reproduce in 1.19.3 and 23w03a?
Can confirm.
Using the dimension_type file, the dimension fails to load if that file is absent, unlike the in-dimension-file definition, upon deactivating the data pack and restarting the world.
I think the better fix would be to store the dimension types in level.dat separately from the dimension data (so it doesn't create tons of duplicate data, while still storing it "permanently").
Pasting my thoughts expressed to the poster, from Twitter
I doubt strictly embedding it all would be the ideal solution. The ideal solution would to have an internal database storing those references. This is a win-win situation because mods starting in 1.16 (ideally) also add dimensions through datapack means.
This way, everything still in storage and anything that's a reference still remains a reference. If the dimension itself is fine but one of the references errors, it simply has a backup for that reference, instead of defaulting entire dimension to the backup.