Picking what mods to load

[astroboy820]

The other day, I downloaded and subsequently deleted RemoteTech. I loved the concept, it truly made for a better experience in sandbox mode, but in career mode, it was a disaster. My suggestion would be to let us be able to choose what mods we load in what games. For example, on my KASA sandbox game, I would like to be able to use RemoteTech but in my FSA career game, I would like it disabled.

Edited December 29, 2013 by astroboy820
Spelling

[KvickFlygarn87]

Yes yes, and all my yes.

[Lewiskerbington]

Something like a menu that pops up when creating new saves, which would allow the player to select which mods they want to use, would be nice. Also, integrating the SpacePort into the game so that it worked similarly to Steam workshop would be another cool feature.

[Nuke]

yea pretty much all this. but i think ive heard it before.

[Murph]

Great idea, although it needs a more rigorous standard of mod packaging before the game can actually identify individual mods. Right now, there's no way for the game to positively identify individual mods, as there can be more than one mod per sub-directory, when they are installed as GameData/Author/Mod in some cases and just GameData/Mod in other cases. Ideally, there also needs to be a mechanism to cover mod dependencies (e.g. B9 requires various plugins packaged outside its subdirectory).

[Nuke]

a standard is easy to create and enforce if it comes straight from squad. dont follow the standard and it just wont work with space port integration, this will make people who download it very angry and will result in your mod having a horrible rating. this would encourage people to get it right.

dealing with dependencies is an issue, but a resolvable one. id prefer a system where mod makers only need to concern themselves with their own assets, which makes licenses easier to deal with. you dont have to include licenses with 3rd party stuff since its not in your pack, they get downloaded separately and have their own license. but you do need to list dependencies (name and version should suffice) so the space port can retrieve those as well. if you try to download a mod that requires mod x, version y, you would be asked to download it first, and then the mod you actually requested would be downloaded.

you could use an archive layout that maps to the game dir. or you could include a spaceport.cfg in the root of the archive. this would specify what files in the archive get copied where in the game dir, mod name, author, license info, version info, dependencies (name and version), where to get the source (if its in the archive, give an option to save it somewhere, otherwise provide a link to the source host, such as github), any documentation that comes with it, etc. this data could also be viewed in game or at the space port, and since it comes with the archive, would greatly simplify uploading of mods.

[Murph]

Yeah, it wouldn't be too difficult to have a suitable standard for mod packaging, none of the issues are really difficult to solve, just need to be looked at carefully to ensure that it covers all the bases. E.g. the dependency stuff needs to have a mechanism to cope with subsets of a complete mod, such as the B9 example where it needs the Firespitter plugin, but not any of the Firespitter parts.