OMG, you're getting rid of /plugins?

[Dale_Mahalko]

@Inscrutable

make sure that the plugins folder doesn’t contain bukkit plugins

I’m assuming this is going to be a non-issue. No API methods will be present to support Bukkit plugins, so it won’t load. All that is necessary is to have a sufficiently informative error message in the console log, that can steer people in the right direction.

“Error loading plugin, no API support available. If this is a Bukkit plugin, it cannot be directly used with Sponge, and a shim loader is required to provide backwards API support. Bukkit shim loaders can be found in the Sponge plugins repository.”

(And where is Pore expected to be putting its bukkit plugins? In /mods too or someplace else? I assume someplace else.)

(Edit: add quote ref)

[MoeBoy76]

IMO configs should definitely stay in the /config folder (plugins should use a /plugin-name if they have more than 1 file), if you’re using a FTB/etc modpack then the config folder is already chaos that you should be managing anyway

On Pore: it loads from /bukkit-plugins

[Dale_Mahalko]

@MoeBoy76

if you’re using a FTB/etc modpack then the config folder is already chaos that you should be managing anyway

MoeBoy76, why so obstinate? It’s currently effortless to deal with modpacks under Cauldron right now. All mod configs are in /config, all plugin configs are in /plugins. Kept completely separate, easy to deal with.

Can you explain in more detail why you feel this way?

[Inscrutable]

Can you make a good use-case for having both sets of configs separate? It does not seem overly inconvenient to have all the configs in one place. Generally configs need updating, rather than global replacement as a batch, so the need for partitioning is diminished. Having them in one place makes them a little easier to integrate too, imho.
I’m not saying it’s a bad idea, but it’s far less of an issue than partitioning mods/plugins.

[Dale_Mahalko]

@Inscrutable

Can you make a good use-case for having both sets of configs separate?

The primary reason for mod/plugin /config separation is when modpack updates occur.

As mentioned previously, Modpack authors can change anything from one update to the next. They may add mods or remove mods. They may also add or remove configs. The removal of configs in new modpack releases, is the main problem.

Some config files might be optional for very complex modpacks, and if the pack author drops a config from their pack, it will persist and not be deleted if we simply try to overwrite files in the /config directory. This may have unexpected results if their updated modpack is now still finding a config file, that should no longer be present.

,

One excellent example of this is MineTweaker, which is sometimes used to work around mod bugs such as a recipe not present, and an iterm uncraftable due to a mod developer error. So they release a patched modpack, using a MineTweaker script, swapping an alternate custom recipe they have defined just simply to allow access to the uncraftable item.

Okay, next modpack release. The bug in the mod is fixed! And wouldn’t you know it but the mod developer actually decided to use a recipe all their own, that the pack author didn’t consider. but fine, whatever, overwrite all the files in /config with the latest pack release.

But what is this? On brand-new Sponge server installs of the modpack, you find the new recipe that the mod author specified. However, on existing Sponge servers that are simply overwriting the /config dir, they still have the old recipe. Because the MineTweaker script is not present in the new modpack release but it persists, mixed in with everything else old and new, in the combined copied-over /config directory.

MineTweaker remains in use in their modpack because perhaps it is applying other fixes for this next release, under a new script name, and this new Minetweaker script will again not be removed on the next fixed-mod overwrite-update, compounding these differences and weirdness between what the modpack author intended players to be able to do, and what’s actually out there in the field that players are seeing on Sponge servers.

This is just one mod, and one example where modpack servers are going to develop problems due to just copying over the top and mixing it all together… unless we Sponge server admins manually pick through the /config dir and then try to figure out which of the hundreds of config files were not included in this last modpack release we just installed…

[Dale_Mahalko]

Also, this is why I’d like to see Sponge plugins and their configs stored in directory paths completely outside of /mods and /config, because the best thing to do on each modpack update is to nuke /mods and /config and use the ones provided in the next modpack release.

Except it’s not going to be very easy to do that if we have to step around these various Sponge files that HAVE to be in /mods and /configs and must not be removed for any reason.

As I understand it, with the change that was just approved, what we are going to be seeing will look like this:

/mods/
/mods/SpongeForge-1.0-RELEASE.jar
/mods/plugins/
/mods/some_mod.jar
/mods/1.8.10/
/mods/1.8.10/mod_in_here_cuz_pack_author_put_it_here.jar
/mods/1.8.10/why_they_did_it_dunno_but_allow_anyway.jar

/config/
/config/forge.cfg
/config/forgeChunkLoading.cfg
/config/Sponge/
/config/Sponge/global.conf
/config/Sponge/worlds (…)
/config/WorldEdit/ (…)
/config/config_for_some_modpack_mod.cfg
/config/dir_for_some_modpack_mod/
/config/more_modpack_stuff_mixed_together/

With the above we have to delete all the modpack jars and directories in the mods folder, BUT leave alone SpongeForge.jar and /plugins. That’s going to be fun to do from a SSH linux command line, and no GUI to simply highlight and select folders. BUT it is at least going to be much easier to deal with now, with all plugins corraled into a single directory.

Posit:
/mods/
/mods/SpongeForge-1.0-RELEASE.jar
/mods/plugins/
/mods/plugins/WorldEdit-3.14.jar
/mods/FTB-InfinityPlusOne/
/mods/FTB-InfinityPlusOne/some_mod.jar
/mods/FTB-InfinityPlusOne/1.8.10/
/mods/FTB-InfinityPlusOne/1.8.10/mod_in_here_cuz_pack_author_put_it_here.jar
/mods/FTB-InfinityPlusOne/1.8.10/why_they_did_it_dunno_but_allow_anyway.jar

/config/
/config/forge.cfg
/config/forgeChunkLoading.cfg
/config/Sponge/
/config/Sponge/global.conf
/config/Sponge/worlds (…)
/config/plugins/WorldEdit/ (…)
/config/FTB-InfinityPlusOne/
/config/FTB-InfinityPlusOne/config_for_some_modpack_mod.cfg
/config/FTB-InfinityPlusOne/dir_for_some_modpack_mod/

This allows deletion and replacement of modpack mods and configs because they are isolated in separate directories away from everything else, don’t have to “step over and avoid” stuff related to Sponge and Forge.

(I do admit to a problem with this. If the modpack includes it’s own Forge configs, those will be ignored as they are in the modpack’s subdir and don’t overwrite the default Forge configs in the /config root. However on public servers we usually end up defining our own ForgeChunkloading.cfg limits to deal with resource hogging players, and we want those chunkloading limits to persist from one modpack update to the next anyway.)

[Dale_Mahalko]

EDIT EDIT EDIT:

Eh, the problem is not that plugins are all mixed together with the mods, it’s that the mods are all mixed together with the plugins and Sponge itself.

Meanwhile what an admin that is new and all thumbs needs, is a way for their modpack customizations to easily persist over the top of the modpack updates, basically substituting for the contents of the modpack’s /mods and /config with whatever they need to persist for their own public server’s purposes.

The original Cauldron directory layout was much less complex to manage, and apparently didn’t need such a huge change, mainly just cleanup the root Minecraft directory.

I do not expect to see the following implemented. I am simply talking at this point. I think it is probably far too late to even suggest this:

/root/Minecraft.jar
/root/Forge.jar
/root/Sponge-1.0-RELEASE.jar
/root/Sponge/
/root/Sponge/Sponge.cfg
/root/Sponge/plugins/
/root/Sponge/plugins/Pore-1.0-RELEASE.jar
/root/Sponge/plugin-configs/
/root/Sponge/plugin-configs/Pore/
/root/Sponge/plugin-configs/Pore/default.cfg
/root/mods/
/root/mods/only_default_modpack_stuff_here.jar
/root/mods-overrides/
/root/mods-overrides/persistent_mods_the_site_admin_needs.jar
/root/mods-overrides/disabled_mod_that_breaks_Sponge.disabled
/root/mods-overrides/FastCraft.disabled (matches any FastCraft* in /mods)
/root/config/
/root/config/only_default_modpack_configs_here.cfg
/root/config/Forge.cfg (included with modpack)
/root/config/ForgeChunkloading.cfg (included with modpack)
/root/config-overrides/
/root/config-overrides/persistent_mod_configs_the_admin_needs.cfg
/root/config-overrides/forgeChunkloading.cfg
/root/config-overrides/rftools/main.cfg
/root/config-overrides/cofh/core/common.cfg
/root/Bukkit-plugins/
/root/Bukkit-plugins/Lockette.jar
/root/Bukkit-plugins/Lockette/ (Need to do this? Can Pore set new config path?)
/root/Bukkit-plugins/Lockette/config.yml

For modpack updates, delete /mods and /config. Insert new /mods and /config.
Start server… by launching Sponge, same as with Cauldron / MCPC+.

I have no idea if it is even possible to talk Forge into being able to deal with mod/config file substitutions from alternate override directory paths.

,

EDIT 9: I guess such /mods and /config override functionality would not necessarily need to be included within Sponge itself. It could be implemented by Forge itself directly, so that people who run private servers without Sponge could also easily have modpack customizations persist across modpack upgrades, and without them also having to repeatedly reapply their own private customizations after every modpack update.

Though still, it is unhelpful to be forced to have Sponge stuff always sitting directly within /mods and /config when all those files and configs could have just as easily been designed to live outside those locations like it was with Cauldron, to allow for easy modpack /mods and /config delete and replace upgrades.

[mumfrey]

The config root is technically movable but isn’t currently exposed as an option so there’s currently no way for it to be moved by an end user (unless they want to compile sponge from source of course). However it could potentially be exposed as a command-line argument or something. The issue with moving config pretty much just boils down to where to store the config option to move the config, since it’s a bit chicken/egg in nature.

I feel like this is a lesser issue than the plugins though because configs are in their own separate folder by default, so they don’t really intermingle with the mod configs anyway.