So why not just create a “Core” folder in the config folder - so have config/Core/core.conf and config/Core/whatever.conf? In fact, Sponge provides a way to get a plugin specific folder for this very reason. That way, all the config items are still in the config folder within a Core specific subfolder - you have a central place for your plugin config, within the central place for configuration - I’d argue that you really shouldn’t be putting anything other than mods/plugins in the mods folder. Server owners aren’t necessarily going to look in the mods folder for configuration.
Look at this section of the config docs page - it tells you how to put your main conf file into a sub folder (using @DefaultConfig(sharedRoot = false)) - you should be able to then use this to get the central folder for your plugin and put all your config files there.
While I understand it’s your plugin and your choice, I really do urge you to consider using the config folder, and creating a Core folder within it - as the Sponge Docs suggest.
You should be placing all plugin configs in ./config/pluginname/. Do not store any configs in the root config folder as that will just cause clutter. Also, no configs should ever be placed in the mods folder, this isn’t CraftBukkit
I added that! Core’s local sqlite database (if used) will be stored in config/core/data/core.db Pretty sure that’s the proper path to store it then. I just used Bukkit for so long it’s hard to completely switch to Sponge sometimes even if I like it much more already!
From what i understand, all you would have to do to actually add the worlds auto loading on startup is , of course, add a command to “disable” a world, which I’m sure is simple, and add into your database each world that is loaded by command. And on startup, you would just grab the list of worlds and run the function that the command triggers anyways. Thanks, and this is by far, the best Sponge mod I have actually used yet.
The odd thing about this is, that this is currently the way we go. That’s why I will have a look at it first before I create a complete new table just for worlds to load.
Strange, but ok! thanks for the plugin and thanks for responding so fast!
And one other thing, im not sure if you currently have, or are planning to add this, but will there or is there specific world options like difficulty, level, and stuff like that? or are you just going to keep it simple with the world system?
I definitely planned to add control over each world. (difficulty, mob/animal spawning, gamemode, xpboost(??), and much more) I will have a deeper look at this and add it within the next few versions!
And I don’t really know what you mean by saying “Import created world solo?” If you mean that you want a function to import your worlds, thats another thing I have to take a closer look at.
Firstly, markdown ate your <placeholders> because they have angle brackets. Surround them in `these` so they appear.
Secondly, part of what you ask — singleplayer worlds running on a server — is impossible without a very tricky (not to mention user-specific) remote filesystem hack. (Oh, and it’d be slow as all hell.) The worlds must exist on the server’s filesystem already. It’s trivial to upload worlds over (S)FTP, so just do that instead =)
One issue I have noticed with Multiworlds in Core, which may be caused by a shortcoming in the API:
All Worlds seem to share the same time. Set it to day in one, and all get set to day, and so on.
This was an issue with the original Multiverse plugin for Bukkit too (I know, I’m the guy who reported it way back then).
When it is possible, having separate timezones per world would be a nice feature.