Autodownloading configurations about cuberite HOT 14 CLOSED

This would be good, something I've wanted for a while.

We could also perhaps get rid of the install folder 😄

from cuberite.

Also, loads more comments showing all the options in the configs would be nice too 😃

from cuberite.

I don't think that's such a great idea.
Which configuration options will be added and which won't? How will you decide? And what if the configuration options change in the future?

I think we're already good enough in this regard - for all the values the server has already the defaults that is uses; for the critical options it also writes those defaults into the INI file so that next time they're there, and the user may change them.

The world generator, on the other hand, doesn't write defaults into the INI, but produces clear warning messages to indicate what the admin needs to do to set them. I see this as a behavior preferable to silently writing a default into the file - what if the admin was trying to get something working, we'll just keep resetting his work back instead of giving him hints about what to do.

The config values should be primarily documented in the wiki, since there's not enough space (in the "reasonable format" limit) in the ini file to document everything. The ini files should already point to the wiki in their header comments.

from cuberite.

Especially bad idea would be to centralize the options, because what does the cRoot know about what world generators have been compiled into the executable? Nothing. So it cannot set reasonable defaults. It makes sense to provide the defaults at the same place that defines their usage.

from cuberite.

Alright, bearbin’s idea:

What about downloading the configs from github if the server can’t find them?

[Windows Mail App]

From: Mattes D
Sent: ‎Sunday‎, ‎11‎ ‎August‎ ‎2013 ‎12‎:‎49
To: mc-server/MCServer
Cc: Tiger Wang

Especially bad idea would be to centralize the options, because what does the cRoot know about what world generators have been compiled into the executable? Nothing. So it cannot set reasonable defaults. It makes sense to provide the defaults at the same place that defines their usage.

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

from cuberite.

If it was to be pulled from online, it should probably also incorporate the Plugins folder, so you could have executable-only distributions 😃

from cuberite.

We already have the ability to read *.example.ini file instead of every *.ini file we're reading, so distributing those example files should be enough.

To add to that, if you make it downloadable from the net, how will you tell which version will support what? What if the default will change to something only the newer versions support?

from cuberite.

You could make it download only the files from the commit the build was compiled with. It should be possible, but IDK how.

from cuberite.

And how often do you reckon those files will be modified? Hardly ever, because we're already spitting out builds like crazy.

from cuberite.

so we should make it just download the latest version?

from cuberite.

Updated description, shall I try?

from cuberite.

I still fail to see any benefit, I see only problems. Also I fail to see any proper use-case. What's the point of downloading anything off the internet, when it is already included in the base distribution package?
We've ruled out updates - that's never gonna happen to old versions, so the content is static.

from cuberite.

Okay then, I will make it so that the server uses example.ini, warns, and doesn't try to write half-formed settings.ini files if they aren't present.

from cuberite.

The server already uses example files if the ini files don't exist. This behavior is coded in ReadFile and is turned on by default, so you don't need to do anything for it.

from cuberite.