Description

Current implementation of world customisation is a custom world type, which results with several problems:

• Users can't create world with large biomes and custom settings without NBT Explorer
• Users don't know that custom world type is not required on server

Current implementation:

Suggested:

I see the Problem. However, since the World Type is a new, DataPack adjustable feature in 1.19, it appears to be the most sensible place to add our custom Generator Modifications and open the configuration of this WorldType to datapacks. We would loose this when just adding the BetterX-Button.

But as I said, I do get the Problem, and would like to have a solution. The first thing that comes to mid would World-Types that combine all default types with the BetterX-Type. However, this could result in too many types.

Another Solution could be to add the overworld to our BetterX-Configuration screen. That way we could allow players to choose the overworld settings from other world-types.

As datapacks world changes are applied only on startup and there is no concept of world type in the world level.dat (which means that is is just a world creation preset) it should not be hard to move that part of customization into a separate button.

Alternatively it can be done as adding a separate page to customisation button (making is a part of each world type), if this is easier to make then it can replace additional button solution

First off, sorry. I didn't realise it was you. :) Otherwise I would have gone into more detail in my original reply.

The main thing is, that the onboarding of a world is very much tied to the WorldType now. That means, that the LevelStem-Registry is properly set up from the very beginning. BCLib dies this by fully embracing that concept. And while it is true that the data is not stored in the level. It is used extensible during the world creation phase.

Changing the UI, would basically just mean to drop the WorldType and implement custom behaviour/hooks into the World Creation screen that would (in the end) replicate the WorldType behaviour and in the end do the same thing: setting up the LevelStem-Registry. This can of course be implemented, but it in-fact requires a lot of time. Not just for implementing the change, but mainly for testing those changes in all possible circumstances (with different supported Mods and Datapacks in different combinations). In my book, the benefit that change would introduce would not justify that time and effort. Especially since it is possible to have mostly the same effect (see below) with much less work.

There is also the UX perspective. This Button is a clear choice by the user, that they want to BetterX-World Type. So all subsequent loads of the world will treat it that way. If new DataPacks or Mods are installed that would change the LevelStem for Nether or End, BCLib will silently enforce those changes during world-load. Without needing to alter the level.dat. And while that choice is not reflected in the level.dat, we still store that initial choice to make sure we can keep the world in a consistent state.

Lastly the changes in 1.19.3 suggest, that this way of handling the on-boarding fits neatly with the new "All is a Datapack" approach Mojang seems to go with now.

For most of the Custom Settings (LargeBiomes and Amplified) it would be sufficient to have a corresponding BetterX-Type. That would also allow me to set some preferences on the world that fit the selection (for example having large Biomes in BetterEnd/BetterNether as well). Types were there is a custom config screens are more problematic, because players would loose that configuration ability. In those cases it may be the simplest solution to add the overworld Customise screen to the BetterX Config as a third option. Depending on how those are implemented, they may automatically apply the correct settings to the overworld without the need for any change.

To make that clear. I am not overly attached to the Better-X WorldType, but I want to preserve certain aspects (as the make developing and adapting the code easier):

1. LeveStem-Registry is properly set up during WorldCreation.
2. It translates well to 1.19.3 and is backward compatible to the current system we use in 1.19
3. Keep all world-related configs store in the world (i.e. no global instance config as we had before)
4. Not invest a lot of time to changing a system that currently works pretty well and can be extended to probably fit something like 90% of use-cases. That time is better spent on other thins :) And yes, this point is subjective, but it is a hard constraint.