[Discussion] New modding plan

[svmnotn]

I do not want to seem unreasonable as @ttyz has already done a lot of work on making the game modable, however I feel that for simplicity of all the subsystems, and for the betterment of modding it would be far better if we took a different approach than we do now.

The Plan

1. No more Mods/.
2. Take all the contents of StreamingAssets/ (excluding Mods/ as that will be deleted) and move them into StreamingAssets/TeamPorcupine/.
3. Make all the subsystems ask for a place to be loaded from.
4. Make something that runs before anything else is loaded and loads all the 'mods'.
5. Make the game load StreamingAssets/* and use every folder as a different source to load all the subsystems from.
6. ...
7. Profit!

   The inspiration

   • Kerbal Space Program.
   • Minecraft (At the very least Forge mods, as they all share a similar structure even though they are kept in a mods folder. Actually this implementation shares more similarities with the current system than with the new one, so this is more of an inspiration of what not to do).

     Why is this better than a Mods folder?

Well that is because this way, the core of the game _is_ a mod. The earlier we do this, the better that modding the game will be.

Furthermore, once modable UI is in place we should be able to only have 1 controller in the whole SCENE by default. It will do all the loading and setting up, just like when KSP is run. Which makes it very obvious that the scene should not be changed.

Unless anyone else wants to, and finishes doing this, I will get to it after getting the Job system to a better state.

[TomMalbran]

Great suggestion. This will make loading the assets better, since we will not have separate codes for mods and for the core. I have a couple of ideas:

1. Maybe each mod should be under a directory like: StreamingAssets/<mod_creator_name>/<mod_name> so that we don't end up with a folder for each mod under Streaming Assets. If we would want to split the content inside StreamingAssets/TeamPorcupine/PorcupineBaseinto several mods, all can be store under the same folder. And when there are mod packs, all the mods can be inside the same folder.
2. We should start thinking of a Package.xml file (or with any other format) with important information about the mod (name, description, version, author, project porcupine supported version and that stuff). The file should be on the root folder of the mod and have that name, so that the Mod Manager can load it. Inside the Package.xml we can also store the paths to the different files (eg: a path to where the xml for the furniture prototypes is), so that we can get rid of the hardcoded paths and names, and have a flexible system.

[svmnotn]

I like the flexibility argument, I'm just not entirely sure about some implications. If we do have a Package.xml I would advice against downloading anything from any URL specified in that file. Something hardcoded like how the localization is now is fine. But making things that simple would not turn out well.

I think that aspect really needs a lot more discussion than it has been given as in the end of the day it could end up making the game run code from an unknown place that we have no control over, and that the user would not necessarily know.

If we do address that vulnerability in a satisfactory manner then all is good. However, until then I will not be adding any download code, nor will I change the download location of locale to a different place due to these concerns.

Oh and about the <mod_creator_name>/<mod_name> I think it would not be a problem to just dive in until we find a specific file/folder name.

[RodRitter]

Also something to bare in mind is that we eventually want to have a mod manager that can activate/deactivate certain mods before the game in loaded (main menu).

[vogonistic]

I think mods on the base level should be fine and if they are in a <something>/<mod> pattern, we should assume it's a mod-pack and group them under <something> in the UI. A Package.xml with author name, version and whatnot sounds great.

Basically, I agree with what you guys said.

[TomMalbran]

@svmnotn When I am talking about the paths in the Package.xml file, is all internal paths. My idea is that you could create a tiny mod with a new furniture and have the structure of the mod be like:

<mod_name>/Package.xml
<mod_name>/MyFurniture.xml
<mod_name>/MyFurniture.lua

And in Package.xml you can specify that the Furniture file is at MyFurniture.xml and the Lua file is at MyFurniture.lua.

A more complex mod could have multiple files per furniture at a Furniture folder and it can specifiy that the Furniture xml files are in that folder.

If we have a Package.xml file, it would be easy to have mods at <mod_creator_name>/<mod_name> and mods at <mod_name>.

[svmnotn]

@TomMalbran I know that, and I love that idea. I was just pointing out the security flaw before anyone commented "Hey let's make the mod auto update from an update URL in the Package.xml".

[TomMalbran]

Just so that everyone knows. I am working towards this. I've been trying to move towards the use of PrototypeManager and FunctionsManager, when needed, and moved the loading to the ModsManager. I am almost ready to make the change once some of my latests PR get merged.

[mikejbrown]

How is this now? This is currently assigned to v0.1. Are you close or do you want to bump it to v0.2?

[TomMalbran]

I am waiting on #1469 to get merged. After that I think that I am ready for to do this. At least the first step. Might be a week more. Since I don't expect modding to start on 0.1, as this is just a concept. It can be moved to 0.2. If 0.1 was a bit more playable, then this was good to have in 0.1 to start modding.

[mikejbrown]

@TomMalbran Ok, moving off 0.1 then.