Recommended Mod Layout Discussion

[linuxgurugamer]

This is a thread to discuss a recommended folder layout for mods.  There has been discussion about this elsewhere

[DStaal]

For reference, the discussion had been focusing on where the 'PluginData' folder should be located.  Options mentioned:

• KSP/GameData/modname/PluginData (currently common)
• KSP/GameData/PluginData/modname
• KSP/PluginData/modname

----------------------------

My personal opinion is that the currently common use is fairly stupid: It makes it hard to seamlessly update mods, as you can't just replace the GameData/modname folder with the new one - you lose your settings.  Either of the other two options separate the settings from the mod code itself, allowing you to replace the mod easier. 

@Lisias is pushing for the last option, as it means that KSP/GameData should never need to be written to during a KSP run.  (So therefore making it easier to spot/contain mods that are malicious, if such exist.)

[Lisias]

Additionally, the "last option" has the merit of being similar to the "Unix Way" - that even Windows is using nowadays.

/usr, /usr/local and /home should be in different separated file hierarchies. Even Windows uses /Program Files ., /Users/<login> and /Users/<login>/Program Files .

This make backups and management incredibly simple and straightforward. And less prone to errors.

The GameData/ hierarchy should be sacred land - once KSP fire up, nothing should be allowed to change anything on there.

[linuxgurugamer]

I believe that the source of this is the fact that if you just use the game xml functions, then it writes the following:

GameData/modname/dlldir/PluginData/dll.xml

where:

• dll = the dll of the mod
• dlldir = directory where the dll is

An additional advantage of using a common PluginData directory is that it is easy to backup.

The proposed solution as I understand it is:

KSPDIR/PluginData/modname/datafiles

I would like to hear from some of the Squad people, such as @bewing, @JPLRepo and others, before any decision is made. 

So, I've written up some proposed guidelines.  I will admit that items 3, 4, 5, 6 are how I usually set things up.  I find that it makes it easier to find files with this kind of organization.  Obviously, if a mod has only a single dll, there would be no real need for a plugin directory, although it doesn't hurt.  

Proposed Community Mod Install Guidelines

1. Mods are installed into the KSPDIR/GameData/ directory (required by the game, put here for completeness)
2. Dynamic mod data is in the KSPDIR/PluginData/modname directory
3. It is strongly encouraged to have a .version file in the main mod directory.  Forgetting anything else, this makes it easy to identify which version of a mod is installed
4. It is recommended that all parts supplied by a mod be in a single directory called Parts.  ie:  KSPDIR/GameData/modname/Parts
5. Files which are not to be read during the game startup can be put into a PluginData directory in the mod directory.  ie:  KSPDIR/GameData/modname/PluginData.  This is a directory that is ignored by KSP during startup
6. It is suggested that DLLs be put into their own directory inside the mod directory.  Common use suggests that it be called Plugins.  ie:  KSPDIR/GameData/modname/Plugins/

 

[Lisias]

I would want to add something to that: KSP usually creates an <KSP>/PluginData on every installment I have. (There're also a Plugin and a Resource directories, always created by default).

I had the idea to use this when I first realized them - I thought it was on purpose, by the way, and got confused when I saw people writing settings merged to the plugins data/executables.

[bewing]

1 hour ago, linuxgurugamer said:

some of the Squad people, such as @bewing

I've never played modded myself, or ever created any mods -- so I know nothing whatsoever about the subject. Some of the others may have useful input though.

 

 

[Nightside]

What happens if I delete a mod but forget to delete the corresponding pluginData file?

my guess is nothing bad, just curious.

[Lisias]

40 minutes ago, Nightside said:

my guess is nothing bad, just curious.

If you downgrade plugins and the file format from the previous version is different, you can have problems - it will depends of the plugin's resiliency - by experience with a lot of source code from the last months, most will recover nicely, as most of them have the defaults embedded on code.

Other than that, what will happen is you reusing your old settings when you decide to reinstall it.

Edited November 21, 2018 by Lisias
hit "Save" too soon.

[Lisias]

6 hours ago, DStaal said:

 (So therefore making it easier to spot/contain mods that are malicious, if such exist.)

The main reason is other (but I got a misbehaving add-on once - programming bug, created some garbage on the dir).

Think DevOps. If the add-on's code/static data is readonly, it can be symlinked/junctioned. You have a lot of installations (I do)? You can have a pool of add-ons on a special place, and symlink/bind/mklink what you want on where you want. On demand.

I can't tell how much easier and faster it's to create test beds for testing specific bugs or add-ons across multiple KSP versions this way. I know, it's how I do it nowadays now that everything I have used KSPe for file routing (what renders my GameData immutable between launches).

Switching versions is recreating symlimks/binds/mklinks. Deleting Making History is deleting a symlink. Reinstalling it? Recreating the symlink. 

OPM, Origins, or some othe huge planet pack? One physical copy, multiple symlinks/binds/junctions.

Life could not be simpler. :-)

[linuxgurugamer]

10 hours ago, Nightside said:

What happens if I delete a mod but forget to delete the corresponding pluginData file?

my guess is nothing bad, just curious.

Assuming that you dont install another version of the mod, nothing will happen.

9 hours ago, Lisias said:

Think DevOps. If the add-on's code/static data is readonly, it can be symlinked/junctioned. You have a lot of installations (I do)? You can have a pool of add-ons on a special place, and symlink/bind/mklink what you want on where you want. On demand

Even though I understand this, most people won’t.  In fact, most people don’t even know what a symlink is, and in windows, you have to do it from a command line.

So, for those who are confused, a bit of explanation:

From Wikapedia:  

Quote

A symbolic link contains a text string that is automatically interpreted and followed by the operating system as a path to another file or directory. This other file or directory is called the "target". The symbolic link is a second file that exists independently of its target. If a symbolic link is deleted, its target remains unaffected. If a symbolic link points to a target, and sometime later that target is moved, renamed or deleted, the symbolic link is not automatically updated or deleted, but continues to exist and still points to the old target, now a non-existing location or file. Symbolic links pointing to moved or non-existing targets are sometimes called broken, orphaned, dead, or dangling.

 

So what this means is that for people who want to use them, can create a library of files and directories, and rather than cluttering up your hard disk or SSD with multiple copies of the game and mods, you can simply use symlinks to create an install with symlinks and just use a minimal amount of space.  It can also make it easier for developers to quickly throw together a new game install for testing purposes.

Edited November 21, 2018 by linuxgurugamer

[Ruedii]

I noticed that some developers used the two tier trend where they put all the mods they started (not necessarily ones they maintain) in a single directory with subdirectories for each mod.

This goes with the mode directory as:
GameData/Developer/Mod/

I honestly like this layout because it reduces clutter and prevents conflict if two devs accidentally chose the same name for their mod.

 

[sharpspoonful]

Why are the proposed layouts any better than dropping mods in their entirity into the GameData folder? Mods are self-contained, and in an easily recognizable and easy to find folder. yes load times are long with 100+ mod lists, but for the average player most of these proposals seem overly complex and time-consuming. That doesn't even begin to touch the havoc caused to 3rd party utilities and sites like Curse, Space Dock and CKAN.

[DStaal]

16 minutes ago, sharpspoonful said:

Why are the proposed layouts any better than dropping mods in their entirity into the GameData folder? Mods are self-contained, and in an easily recognizable and easy to find folder. yes load times are long with 100+ mod lists, but for the average player most of these proposals seem overly complex and time-consuming. That doesn't even begin to touch the havoc caused to 3rd party utilities and sites like Curse, Space Dock and CKAN.

Most mods are entirely self-contained - and this wouldn't touch those mods.  What's really being discussed is mods that have user-created files - settings files and the like.  Typically they are also put into the mod's folder, but this has the unfortunate side-effect of making it harder to upgrade the mod.  When you do, you have one of two choices:

1. Carefully merge the new and old folders, making sure to delete all the files that have gone away in the new version of the mod (if there are some), and leaving the settings file(s) while replacing all the rest of the mod's files.
2. Replace the whole folder with the new one, and lose your settings.

The discussion is about having a different designated location for those settings files from mods.  This makes upgrading and maintaining mods easier, as you won't lose your settings, and it makes discovering that a mod has settings easier for those mods that have text-file only settings.

This won't affect load times, would only minimally affect CKAN, and wouldn't affect Curse or SpaceDock at all - you'd download the same zip file, and it's only slightly different on the first install.  (Where you might have to put the settings files in place.)

-----

The above makes me think about one advantage of the GameData/PluginData/modname strategy over the PluginData/modname strategy: It's a simpler transition.  For the normal 'merge contents of zip file into GameData' install process it's about the same, as the 'install root' hasn't changed.  (Of course, a bad merge tool is more of an issue - older versions of MacOS had trouble merging to depth, which would mean that all other settings could get wiped out on a merge, for instance.  But I believe this is fixed in the last couple of versions of the OS, and I'm not aware of any other merge tools that have the issue.)

32 minutes ago, Ruedii said:

I noticed that some developers used the two tier trend where they put all the mods they started (not necessarily ones they maintain) in a single directory with subdirectories for each mod.

This goes with the mode directory as:
GameData/Developer/Mod/

I honestly like this layout because it reduces clutter and prevents conflict if two devs accidentally chose the same name for their mod.

I'll admit I'm not a huge fan of that either, as it just means another level of merging when trying to install - but I don't actively find it harmful, and there's only a few mod authors that use it.  (And they typically have very complicated structures, so it's useful for them.)

[linuxgurugamer]

39 minutes ago, Ruedii said:

I honestly like this layout because it reduces clutter and prevents conflict if two devs accidentally chose the same name for their mod.

They shouldn't do that, it just causes confusion

37 minutes ago, sharpspoonful said:

That doesn't even begin to touch the havoc caused to 3rd party utilities and sites like Curse, Space Dock and CKAN.

I don't see how an upload/download site like Curse and Spacedock will be affected by this.

and CKAN will work quite nicely with this, as long as the metadata is correct

[Lisias]

7 hours ago, Ruedii said:

This goes with the mode directory as:
GameData/Developer/Mod/

I have mixed feelings about this one.

On parts, the textures and models "names" are derived from the filesystem path where the asset are. Things will work for that add-on, but other add-ons willing to access the same assets will bork.

For while, I only use a "Vendor" subdir (as I call it on KSPe) for add-ons that doesn't have parts. Impossible Innovations, on the other hand, will be in the GameData/ImpossibleInnovations so anyone that had used an asset from II in the past will continue to use that asset without modification.

Edited November 21, 2018 by Lisias
Kraken damned autocompletes! =/

[linuxgurugamer]

2 hours ago, Ruedii said:

I noticed that some developers used the two tier trend where they put all the mods they started (not necessarily ones they maintain) in a single directory with subdirectories for each mod.

This goes with the mode directory as:
GameData/Developer/Mod/

I honestly like this layout because it reduces clutter and prevents conflict if two devs accidentally chose the same name for their mod.

 

First off, it's not necessary.  There should never be two identically-named mods.  Even if a mod is forked, the fork should (usually required by license) change the name, and therefore should also change the directory.  

Secondly, what about someone like myself (and others)?  Should I create more than 160 directories inside a LGG directory?  Many of my mods have been adopted, and have their own directory layout, which other mods are expecting.

There is no need to change the layout of the GameData directory for static data (ie:  parts, textures, etc).  It will just cause problems.

[DStaal]

It should also be noted the 'Developer/Mod' structure makes it harder to write MM patches that affect the mods cleanly.  (Not impossible, especially with the most recent versions of MM, but more difficult.)

[Tonka Crash]

As a player that often tweaks my local install, I hate the GameData/Developer/Mod layout. It hides mods under directory names that may not be obvious. If you want your name in the tree make it GameData/Developer Mod

One that I dealt with yesterday is the ZZZ_RadioTelescope which is under GameData/MunSeeker/ZZZ_RadioTelescope currently maintained by linuxgurugamer. I have no idea who MunSeeker was since I've only been playing about 6 months. 

[Tyko]

17 hours ago, linuxgurugamer said:

I would like to hear from some of the Squad people, such as @bewing, @JPLRepo and others, before any decision is made. 

@RoverDude would be a good resource too.

[Ruedii]

1 hour ago, DStaal said:

It should also be noted the 'Developer/Mod' structure makes it harder to write MM patches that affect the mods cleanly.  (Not impossible, especially with the most recent versions of MM, but more difficult.) 

That's probably the biggest argument against it.  I didn't think of that.

 

[linuxgurugamer]

1 hour ago, Tonka Crash said:

As a player that often tweaks my local install, I hate the GameData/Developer/Mod layout. It hides mods under directory names that may not be obvious. If you want your name in the tree make it GameData/Developer Mod

One that I dealt with yesterday is the ZZZ_RadioTelescope which is under GameData/MunSeeker/ZZZ_RadioTelescope currently maintained by linuxgurugamer. I have no idea who MunSeeker was since I've only been playing about 6 months. 

Sorry about that, it's slated to be moved up soon

[Tonka Crash]

35 minutes ago, linuxgurugamer said:

Sorry about that, it's slated to be moved up soon

I wasn't picking on you specifically, it was just the most recent mod where I had the issue.

[linuxgurugamer]

1 hour ago, Tonka Crash said:

I wasn't picking on you specifically, it was just the most recent mod where I had the issue.

I wasn't offended

@RoverDude @Angel-125 Could you take a look at this link (2nd or 3rd in this thread) and add your comments here?

 

[DStaal]

1 hour ago, linuxgurugamer said:

Sorry about that, it's slated to be moved up soon

I figure you get a pass on that, as you're picking up the mod and have to deal with the structure already there.  You'll likely fix when you get a chance.

(There's also one mod author out there who used the structure of 'GameData/Developer' - note no mod folders - for multiple mods.  That's a mess.)

[linuxgurugamer]

3 minutes ago, DStaal said:

I figure you get a pass on that, as you're picking up the mod and have to deal with the structure already there.  You'll likely fix when you get a chance.

(There's also one mod author out there who used the structure of 'GameData/Developer' - note no mod folders - for multiple mods.  That's a mess.)

Is it an active mod (ie:  uptodate)?