Rework world/dimension storage

[Machine-Maker]

New Structure

root/
	server.properties (with level-name=world)
	world/
		level.dat (PRIMARY, LevelName=world)
		DIM-1/
			level.dat (SECONDARY, LevelName=world_nether)
		DIM1/
			level.dat (SECONDARY, LevelName=world_the_end)
		dimensions/
			machine_maker
				test/
					level.dat (SECONDARY, LevelName=machine_maker_test)

Things to note

Only the PRIMARY level.dat file has values for WorldGenSettings, DataPacks, Modded, and ServerBrands. That way they are read once, and there's no confusing about which level.dat controls what. All the other level.dats only have per-world settings for their world. (I'm not sure if ALL of them are actually per-world, but I think they all can be at some point.

This fixes all those issues where data packs can't modify the default worlds, and removes the need for jmp's levelstem fix.

Unanswered Questions

• I think we should really deprecate all things "level name". World's should not be referred to by that, only by their namespaces keys. That means deprecating all the world creator methods relating to it, Bukkit.getWorld(String), etc. The level name can be exposed for sure, but I think it should be a different method to highlight the incorrect use of World#getName() over World#getKey().

TODO

• [ ] migrations from current system for vanilla/custom bukkit worlds
• [ ] check the threaded world upgrader is still using the right directories for stuff
• [ ] more...?

[jacksyyy]

is this the hard fork? i can not go back to spigot with this.

I do not know why getName() is bad??

[electronicboy]

a) downgrading is something that has never been supported, and not something we're going to favour over vanilla features b) This is going to use the vanilla world layout, so if spigots migration logic actually works this will be a none issue anyways

2. Worlds use resource keys internally, given mojangs push towards resource keys and the fact that this can matter in regards to datapacks,

mymagicalpack:world mymythicalpack:world

would both conflict in bukkits way of doing stuff, whereas in vanilla with datapacks, that is perfectly valid

[electronicboy]

this is a draft PR for a set of changes which has 0 implications on our compat with upstream

[PhilCCMG]

It would be a bad idea to entirely change the structure from a server administrator perspective.

The idea of the CraftBukkit world system is to allow servers to be easy to develop, build upon and enable community collaboration.

With over a decade of tutorials, guides, and community worlds created on the likes of Planet Minecraft, MCMarket et al., for younger or newer server operators it would create confusion as all the guides etc would have to be adapted to explain the world naming scheme.

Additionally, not naming the worlds in a human readable format, regardless of where the dimension data is actually stored, would be a step backwards.

This type of move should not be made until the so-called "hard fork" of PaperMC is finalised. Paper is currently a fork of Spigot, and thus should have continuity in the structure of the API and folders.

Until such a time, it drastically increases the work required by the Paper team each minor and major update, and is highly likely a large amount of developers on private server distributions will simply revert this patch to a system which has been tried and tested for over a decade.

The reason for making such a change has its merits, namely data pack support but I feel like there's a way to fix data packs without breaking the consistency of the platform which has existed for over a decade...

I'm aware this is "for future", just I'd appreciate clarity as to when "future" may be here.

tl;dr this makes a lot of work and breaks consistency, and shouldn't happen until a so called "hard fork"

[electronicboy]

1. The idea of the craftbukkit world system is that it existed, not much more, not much less; This was added before vanilla added their own system and was preferred at the time as it made a lot of sense to just maintain their own set of stuff given that it was fairly minimal in its invasiveness and the fact that it existed first

2. The game moves forward, what was once a trivial set of changes to add a feature to the game, and then maintain its quirks past the addition of the vanilla system, has massively blown in complexity, while we did wanna maintain CBs system, see 4

3. the world naming thing is a technical limitation, back in the past, the name was a unique thing that was consistent, couldn't be duplicated, now they can; pack1:overworld pack2:overworld couldn't exist within craftbukkit, however, is 100% perfectly valid in vanilla, I do wanna add a display name to worlds for plugins to take advantage of given that resource keys aren't pretty and the key is no longer the unique constraint that it was in the past; in order to keep the "name" as valid and still allow this, we'd either need an inconsistent hack to allow minecraft:overworld to be looked up using overworld (and, even, "world"), its behavior here would be widely inconsistent in the wider scheme of things

4. "The future" is already here, the CB world changes are basically wholely incompatible with the Minecraft world system, in the past, that was a none issue as nothing really derived too much that CBs breaking change was too much of an issue, however since the introduction of datapacks, practically every update has resulted in another set of patches so that core vanilla features work

The entire system is widely inconsistent with vanilla and is generally unmaintained by upstream leading to various levels of incompatibility even within itself, for the past 2 years or whatever each update has generally resulted in more patches to hack together the widely diverting codebases of the two mechanisms in which constant decisions around "how do we maintain this "are tossed around, each with its own set of side-effects which break or make vanilla compat vs other goals; we're slowly getting to the point where there are more lines of hacks to maintain this vs those which exist for the actual feature itself

[for clarification] This is the files structure of a world created using a datapack within paper, you'll note that the world structure created here is NOT compatible with a CB loaded world in any form or capacity, it's missing core things, such as the level.dat file, the folder structure is widely broken, as is the case in other none primary worlds (e.g. the end/nether)

However, this is likely not going to happen soon, there are many wider discussions to be had here,but, I think it's important to state the real scope and goal of the changes here, there are discussions that we could in part maintain some, if not all, aspects of the file structure changes, but, even upstream is broken there

[FawksX]

I agree with phil

[jacksyyy]

All checks have failed 1 failing check @github-actions Build Paper / build (17) (pull_request) Failing after 7m — build (17)

I think the check has failed. why? invalid??

[Owen1212055]

All checks have failed 1 failing check @github-actions Build Paper / build (17) (pull_request) Failing after 7m — build (17)

I think the check has failed. why? invalid??

This is due to missing annotations, this is irrelevant however as this is a draft PR.

[Owen1212055]

https://canary.discord.com/channels/289587909051416579/925530366192779286/986800481550631012 Consider the handling of symlinked world directories.