Recommended Mod Layout Discussion

[DStaal]

6 minutes ago, linuxgurugamer said:

Is it an active mod (ie:  uptodate)?

Just parts, and it was active through 1.4.3, so it's not really out of date.   REKT and PicoPort.  (SHED/Steelcrudgeun.)

I tried a PR once to start a cleanup for him - it was even accepted, but mangled...

[linuxgurugamer]

2 minutes ago, DStaal said:

Just parts, and it was active through 1.4.3, so it's not really out of date.   REKT and PicoPort.  (SHED/Steelcrudgeun.)

I tried a PR once to start a cleanup for him - it was even accepted, but mangled...

Hmmm.  He actually made the PicoPort for me and decided to release it as it's own mod.

He also hasn't been around since August

Let me reach out to him, if he doesn't respond, I'll adopt it and fix that issue

Edited November 21, 2018 by linuxgurugamer

[RoverDude]

tbh no real skin in the game either way wrt PluginData.  Folder wise, I'm good to go with my current folder structure.

Maybe another way of looking at this is what problem are you trying to solve?  Getting more than two developers to agree to stuff is like herding cats, unless there's an interop issue to be solved that is causing them pain (i.e. CTT/CRP/CCK).

[DStaal]

10 minutes ago, RoverDude said:

tbh no real skin in the game either way wrt PluginData.  Folder wise, I'm good to go with my current folder structure.

Maybe another way of looking at this is what problem are you trying to solve?  Getting more than two developers to agree to stuff is like herding cats, unless there's an interop issue to be solved that is causing them pain (i.e. CTT/CRP/CCK).

I think the main idea at this point is to have a recommendation actually come out, instead of just what the tools default to.  Even if no one changes things to follow it, having it out and somewhat agreed as a good idea would be something developers could be pointed to in the future.

Also, being able to replace mod folders easily without replacing the settings files would likely help maintenance and troubleshooting - it's easier to just tell people to replace the mod folder when there isn't *anything* they might have changed in it.

[Lisias]

18 hours ago, RoverDude said:

Getting more than two developers to agree to stuff is like herding cats, unless there's an interop issue to be solved that is causing them pain (i.e. CTT/CRP/CCK).

I agree. User wise problems usually are solved by forking, and the developers perceiving people migrating to forks where the desired feature is implemented and then, merging the features to their products.

Essentially, it was what drove Open Source products ahead in the past - from EMACS to every new Linux distro still in existence.

[Gurki]

On 11/21/2018 at 10:03 PM, DStaal said:

Also, being able to replace mod folders easily without replacing the settings files would likely help maintenance and troubleshooting - it's easier to just tell people to replace the mod folder when there isn't *anything* they might have changed in it. 

As someone that have to deal on weekly basis on software upgrade that tend to garbage most of their manually customized configuration each time ... I can't agree more on that.

Clear separation of statics and configuration in a way that allow a dumb upgrade (delete folder then extract the new one) should always be the way to do as it make end user's life easier.

In this idea, I prefer the "KSPDIR/PluginData/ModName" way.

 

On 11/20/2018 at 10:48 PM, Lisias said:

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

In that case, a cache folder should also be defined outside the GameData directory as few mods rely on file cache (MM, Kopernicus/PlanetPacks).

 

[Benjamin Kerman]

I think throwing everything that is static in PluginData and recommending that no folders inside GameData/ModDir be called PluginData is a little confusing. For example: the images that are used to make the toolbar buttons for the mods. Where should those go? I've put them in my GameData/ModDir/PluginData folder because it's data that's specifically used by the plugin (hence the name :p). 

What I would say is have the recommended static mod Settings folder be located at KSPDIR/AddonSettings/ModName/... (This could be replaced to make it KSPDIR/PluginData/ModName but I think that having it named AddonSettings makes the purpose a little more clear)

This is a little more complex but it maintains the semblance and structure of the GameData folder while making it easier to find your file without having to worry about someone else using a settings file called settings.cfg :p

[DStaal]

I don't necessarily think that anyone's suggesting there shouldn't be any folders with the name 'PluginData' inside GameData - just that they shouldn't have dynamic or user-modified content.  So your images example wouldn't be affected.  (Note that 'PluginData' with GameData already does have one other special effect: MM will skip those folders.)

And while I agree AddonSettings is a clearer name, the normal KSP install already includes a KSP/PluginData folder.  (That is empty.)  Using an existing folder over creating a new one - assuming there's no conflicting use - makes sense to me.

[Lisias]

1 hour ago, Gurki said:

In this idea, I prefer the "KSPDIR/PluginData/ModName" way.

In that case, a cache folder should also be defined outside the GameData directory as few mods rely on file cache (MM, Kopernicus/PlanetPacks).

I have a MM prototype doing exactly that. It works flawlessly. I got some issues with some mods (needlesly, by the way) accessing the cache files - funny thing is that the 'fix' was just to remove that code, as whatever they were trying to accomplish, KSP already had done that (verified, I provoked the problem they were trying to  prevent and double checked it).

However….

Mods that creates CFG (and other assets) that need to be accessible by the KSP engine from the GameDatabase, they *need* to be on GameData somehow. So I got that "/usr/local" idea . Since KSP usually load things ordered by name (probably using linq, by the way, I managed to simulate exactly the ordering by using linq), I choose to put all of that on a directory name to something that would be loaded last for sure - mainly due UbioWelding. So I'm playing with "GameData/__LOCAL/<mdname>/<what_the_mod_wants>".

Not so "perfect" as keeping the GameData writeless, but at least all the "local data" are confined on the same place, and GameData continues to be in pristine condition.

This idea is in production on my KSP for some months now. Including the __LOCAL stunt. I moved the KerbalKonstructs's NewInstaces to GameData/__LOCAL/KerbalKonstructs/NewInstances and symlinked it to the original place - not the best of the ideas, as now things are loaded twice and I didn't cared to though on the problem yet. One possible hack is to use GameData/__LOCAL/PluginData/KerbalKonstructs/NewInstances for that, but I didn't test it yet.

40 minutes ago, DStaal said:

And while I agree AddonSettings is a clearer name, the normal KSP install already includes a KSP/PluginData folder.  (That is empty.)  Using an existing folder over creating a new one - assuming there's no conflicting use - makes sense to me.

And for the ones willing to take their chances with KSPe  this is not a problem, as add-ons using KSPe open files using a internal mechanism that derives the name using introspection  and the root for that sub filesystem can be changed to anything in the World without affecting the client DLLs.

1 hour ago, Benjamin Kerman said:

I think throwing everything that is static in PluginData and recommending that no folders inside GameData/ModDir be called PluginData is a little confusing. For example: the images that are used to make the toolbar buttons for the mods. Where should those go?

It's a user setting? It's a file that the user is expected to edit (as config.xml from KJR, to activate the debug mode)? So it should be on a different place.

It's something that is never changed by the user? It stays where it is.

47 minutes ago, DStaal said:

 (Note that 'PluginData' with GameData already does have one other special effect: MM will skip those folders.)

Just MM or KSP too? The info I got above is that KSP would ignore such directories. This information is vital to me, as this can force me to rethink some things, as the one I proposed on this (merged) post.

[linuxgurugamer]

On 11/24/2018 at 1:29 PM, Lisias said:

ust MM or KSP too? The info I got above is that KSP would ignore such directories. This information is vital to me, as this can force me to rethink some things, as the one I proposed on this (merged) post

Both