Save world spawn to NBT instead of world.ini

[sphinxc0re]

Vanilla also saves it's spawn coords in anvil

[NiLSPACE]

This has been discussed before, but we choose to stay with ini instead. It's hard to change the settings otherwise.

[sphinxc0re]

No, it's not. You just have to /setspawn and it sets the spawn to where you stand. Otherwise you would have to go into debug mode, remember the coords, go to the file and save it. See? Much more work

[NiLSPACE]

Yeah.. except that the world.ini has 1000 times more things that can be configured.

[ghost]

did you think of both? if the server sees a change it asks which it should use

[sphinxc0re]

@Schwertspize this would most probably collide

@NiLSPACE That's not the point. The point is, that if you for example import a world, most of the time, the spawn point is wrong, because it isn't loaded properly, and ressetting it is a pain in the arse for normal users
http://wiki.vg/NBT#level.dat

[NiLSPACE]

How about, if the server sees an nbt file it exports the settings it can use from that, and puts it in the settings.ini. After that it renames the file to level_original.dat. We'll have to think of something that recreates the nbt back though for if you want the world to go back to vanilla.

[sphinxc0re]

Since we are trying to recreate Vanilla behavior, it would be the best to stick to the original level file and load all loadable settings from there.

[NiLSPACE]

I disagree. If someone doesn't know enough about the server that he just pastes his world in the root folder and enable the world then it wouldn't hurt to use the settings.ini

Also, how the hell do you want the admin's who like experimenting with world settings to be able to change the settings? You'd have to download a complete new program to open nbt files. Changing those means it isn't a complete vanilla file as well, since Cuberite has allot more options.

Don't tell me you want to create a webadmin page or commands where you can change all the options? Because I've tried. After a week it was outdated again. It's probably the most outdated page in the whole Core plugin by now.

We're not completely vanilla, and we shouldn't be. We try to pick the best options we have, and currently that isn't using the nbt file as a settings file if you'd ask me.

[Seadragon91]

@NiLSPACE 👍

[sphinxc0re]

I don't want to store the whole settings file (read the topic) @cuberite/core-team anyone else having another opinion?

[NiLSPACE]

Whoops, just noticed that the title isn't about the whole settings, but only the spawn point, sorry about that.

But I still think it makes sense to just extract those values and put them in the settings.ini + renaming the nbt file. That way we at least have all the settings about a world in one file.

[madmaxoft]

I'd prefer to keep the spawn location in world.ini, but with the following changes in logic:

• if world.ini doesn't contain spawn coords, try to load them from level.dat before generating
• whenever the spawn coords are changed (using a /setspawn command), write to both world.ini and level.dat
• after the spawn coords are read from world.ini, write them to level.dat, too.

This will allow both importing world from vanilla and exporting it back to vanilla, while keeping the format easy to edit by regular users and requiring minimal changes to the code.

[NiLSPACE]

That sounds like the best solution. Some people might be confused when they manually change the spawn coordinates, but that will most likely be really rare.

[madmaxoft]

When the spawn coords are changed manually in world.ini, they will get placed into level.dat upon the next start of the server.

The only confusion might arise if someone changes the spawn coords in the level.dat file, those will get replaced, true.

[tigerw]

Speaking as an user, duplication of settings is pretty high on the omg, what were they thinking list.

On 3 Dec 2015, at 12:06, "Mattes D" notifications@github.com wrote:

When the spawn coords are changed manually in world.ini, they will get placed into level.dat upon the next start of the server.

The only confusion might arise if someone changes the spawn coords in the level.dat file, those will get replaced, true.

—
Reply to this email directly or view it on GitHub.

[worktycho]

I think the options are:

1. Spawn only in world.ini: Incompatible with other tools.
2. Spawn only in level.dat: Difficult to edit, loses backward compatibility
3. Import from level.dat to world.ini: Becomes incompatible with existing tools, and is confusing because level.dat only works the first time
4. have both, but prefer world.ini: Loses edits with external tools.
5. Have both but prefer level.dat: Loses edits with a text editor.
6. Have both and refuse to start on inconsistency: Annoying to the user.

[madmaxoft]

Out of those options, (4) seems the most favorable to me, and that's what I've suggested above. While the world is used by Cuberite, external tools are unlikely to be used for setting the spawn. The server could, upon startup, check both places and if they differ, issue a warning with a guide on how to set the spawn properly.

[tigerw]

I wouldn't mind having to use NBTExplorer to edit configuration. It's essentially what everyone is used to.

[sphinxc0re]

Sorry but I can't seem to understand why anyone ever wanted to change the world spawn by hand. Everyone (Literally) sets the world spawn via the /setspawn command

[NiLSPACE]

I once had a little script (batch) that would generate the world, allow me to login and look at the world and once I stop the server removes the world files and remove the seed and world spawn coordinates. I used it to find a nice seed for my server. This would be hard to do when it's saved in the login.dat file.

[sphinxc0re]

What does this have to do with this issue?

[NiLSPACE]

It means /setspawn isn't always the answer, but now that I think about it more I guess I could just remove the level.dat file. Still, I'm not sure why you're so determined to put the world spawn in the level.dat while option 4 would be the perfect compromise.

[sphinxc0re]

Because changing the spawn point by hand in a config file is the most unintuitive way and the most uncommon way. I suppose there is no reason to keep this behavior since we are the only server doing it this way.

[NiLSPACE]

But if everyone uses /setspawn to set the spawn, then why does it matter where it's saved?

[sphinxc0re]

Because the spawn coords on every other server are saved from and to the level.dat

[NiLSPACE]

I guess that's true, but it would mean we split up the configuration for a world to multiple files. I'd prefer to have it all in one file. What do the others think?

[sphinxc0re]

There are may sections in the anvil format you could think of as configuration. And so is the spawn point. It is data. Nobody would think of blockdata as part of the configuration

[madmaxoft]

I'm still voting for the solution I proposed earlier (store in both, prefer world.ini).
The one use-case I'm thinking about is configuring the world before using it for the first time - before you even run Cuberite, you want to configure everything including the spawn point.

[SafwatHalaby]

What would be the downsides of an NBT-only solution, considering the fact that /setspawn can, and is usually used anyways?

[madmaxoft]

You can't use NBT-only in a human-friendly way in the case when you want to configure everything before even starting the server.

[tigerw]

It's served Manilla Vinecraft perfectly well. And really, what is human friendly anyway? An INI is edited by Notepad, a NBT is edited by NBTExplorer. Both are programs, nothing is special about one or the other. You could really argue the latter is more friendly because it presents structured data, instead of text.

[NiLSPACE]

But to edit NBT data you need a specific program, while most if not all OS's come with a text editor.

[SafwatHalaby]

How about this:

• Keep it NBT only. This maximizes compatibility with the rest of the Minecraft community and prevents the inevitable confusion a duplication would cause. It's also simpler code than the dual solution.
• Have a command line parameter e.g. ./cuberite --setspawn world_nether 50 100 50 which, if set, calls /setspawn right after the server starts.

Now all requirements are met with minimum effort.

• Most players can use /setspawn.
• Full compatibility with other servers and tools.
• Server admins can still configure their worlds on startup.

[NiLSPACE]

I doubt we'll ever be fully compatible with the rest of Minecraft as Cuberite and Minecraft simply don't share allot of settings. Cuberite has way more things that can be altered and tweaked.

A command line parameter isn't really an option either once again because in Cuberite you can configure almost anything. Unless someone is willing to keep the parameter parser up-to-date 24/7.

EDIT:
And once again I forget that this is just for the spawn coordinates..

I think it's best to simply get the coordinates out of the level.dat if it exists, put them in the world.ini and then rename the level.dat file to something like level.original.dat.

[SafwatHalaby]

I am not suggesting we should configure everything via commandline parameters. Only for /setspawn. I am simply searching for a way which is both configurable and NBT-only. Alternatively, the default world INI could have something like: spawnpoint=NBT, If set to spawnpoint = x y z then server would move those to NBT and set it back to spawnpoint=NBT on startup.

[NiLSPACE]

Yeah, I already updated my comment because I once again forgot that this is just for the spawnpoint.

[tigerw]

It really is a stretch to suggest that anyone familiar with Minecraft servers will be unwilling or incapable of using an editor which is required to modify world settings of pretty much all instances of Minecraft out there.

World.ini should not exist; settings.ini, perhaps.

[NiLSPACE]

I assume you mean the world.ini should be removed in favor of nbt?

[tigerw]

Indeed.