mojira.dev
MC-303966

Dimension definitions take priority over dimensions defined in world preset definitions

When defining a custom world preset (data/<namespace>/worldgen/world_preset), the dimension definitions are explicit inline definitions, not references. However, the presence of a custom data/minecraft/dimension/overworld.json file overwrites this explicit definition.

I understand this may be intended behaviour, but would like clarity on it if this is the case, since it seems unintuitive to me. It makes sense to make it easy to override default overworlds with a single dimension file, rather than overriding multiple presets. However, in the case that a custom preset is provided, this override limits possibilities (as you must either override the default world*, therefore not having independent presets, or only use presets in order to have them meaningfully seperated, not both), and also creates potential cross-pack conflicts.

My suggestion is that the file should overwrite only the default preset definitions (or preset definitions in the minecraft namespace), and leave external definitions as-defined.

Behaviour also seems present on 1.21.1 upward, possibly more, haven’t tested.

I have attached a minimal datapack demonstrating the issue - it contains a dimension file which overrides the overworld to only use forests, and a custom world preset (which is added to the presets button), which overrides the overworld to only use plains. As you can see in both screenshots (first one created on the normal preset, without clicking the button, second created on the custom preset), neither contain a plains biome within the dimension, whereas I would expect the latter world to be plains-only, under the logic I outlined above.

* The reason I point to this is that the current presets system ignores preset definitions until the player has clicked the preset button at least once, instead defaulting to an internal preset which can only be modified via an explicit dimension file, not via presets - changing this behaviour (to always use the defined presets) would be an alternate fix, allowing modification of both the default world, and also having independent presets

Attachments

Comments 1

Can confirm this weird behavior. Can also see many use cases to changing/fixing this behavior.

EnigmaTek

(Unassigned)

Confirmed

Platform

Low

Custom Worlds

1.21.10, 25w45a

Retrieved