Mods dumping files in another mod's folder

[Mipe]

That has to stop.

Thank you.

[RainDreamer]

Usually that means one of them is a dependency of the other and without the extra files in the correct place the whole thing wouldn't work correctly.

[magico13]

I'm curious what examples you have and what problems you see with it. Mods don't tend to put things in other folders for no reason. Even so, I'm not sure why it would be that big of a deal if they did.

[sarbian]

Peoples dumping post without context.

This has to stop

Thank you

[Mipe]

It is bad form, period. Updating the mods that have dirty files from other (dependent) mods is a pain - you can't have a clean update by deleting the folder first, because you'd lose the other mods' files that way (typically configs and whatsnot) and you'd have to reinstall those, but then they try to overwrite the updated mods' DLL with their own outdated DLL.

Case in point: Karbonite trying to force its own Firespitter dll and dumping configs into dependencies' folders. As awesome RoverDude is, I wish he'd be a little neater about things like this!

He's not the only culprit; in the course of several days, I've found several. Those are typically mods that provide more than one folder in their package, containing other authors' dependencies. It's nice of you to want to provide an out-of-the-box install solution, but this makes things complicated (installing and maintaining dependencies separately).

And whenever I decide to uninstall the mod, I am left baffled as to what to do with those "dirty" files. Which ones are from that mod and which ones are from others? I end leaving those files alone, knowing fully well they may cause issues in the future.

Is there really no way to keep your configs (EVE, etc.) in your own folder? Do you really have to bundle individual DLLs (firespitter, module manager etc.)? You can just instruct the user to install the dependency as well and maintain it.

Clean it up and we'll all hold hands and sing Kumbaya.

[sarbian]

Is there really no way to keep your configs (EVE, etc.) in your own folder? Do you really have to bundle individual DLLs (firespitter, module manager etc.)? You can just instruct the user to install the dependency as well and maintain it.

- No, since most of those mods require the file to be in specific folders

- No, since we get more post about users messing up dependency install than post about dependency cleaning.

Use CKAN.

[Mipe]

I am trying to use CKAN, honestly. But it won't let me install addons still stuck in the 1.0.2/1.0.3 limbo, so I have to do it manually. I would love to just install the Firespitter Core, but wouldn't that nuke the mod-specific files?

It's a mess, really. In fact, I'm about to head to CKAN and request ability to install "incompatible" mods. Perhaps they'll be quicker about it than the dozens of mod authors scrambling to update all their mod to keep up with KSP version.

[RainDreamer]

Then just nuke the mod specific file. Usually modders keep themselves updated versions of their dependencies too, so it is rarely a problem, but to be sure, grab the latest version of the dependencies and override stuff. I do this for module manager and filesplitter and other things that a lot of modder uses and no problems so far despite running about 80-100 mods. They usually are backward compatible so no fear of updating. And in the case that it is not, you will get a warning.

[Mipe]

And when something goes wrong, prompting you to whine to the mod author, who then chews you out for not properly installing their mod...

My original point stands: mods should not put files in other mods' folders. If the design doesn't allow that, then the design needs to be reviewed.

[Red Iron Crown]

That's a tough thing to accomplish, because some mods modify other mods. Take a visual pack like Astronomer's or the Renaissance Collection, they are mostly configs and textures for other mods like EVE and Texture Replacer, and EVE and TR expect the files to be within their folders at certain paths. They couldn't work currently if they couldn't put files in other mods' directories.

The only way I could see not touching another mod's directory is if you could get all modders to agree on a central directory to store cfgs and other modifyable parts, but that is an unlikely scenario and they'd still be modifying the original mods' directory, the directory would just be another in a different place.

But maybe I'm missing something. Do you have an idea of how mods-that-modify-mods could still work without putting anything in their directories?

[Master Tao]

Ven's Stock Revamp uses a hybrid approach: it stores all of it's own textures and models in it's own folder, but then uses scripts to rename the originals so the game does waste RAM and time loading them.

[RoverDude]

Ah! I thought my ears were burning.

You do realize that for your specific example, using KSP-AVC as recommended would solve your entire issue. It's kinda why a lot of us use it. And it's a lot easier to have someone who sees an AVC warning just grab the latest FireSpitter vs. deal with the support issues of requiring a separate install and cries of 'why do you want me to install biplane parts??!'

Side note: The only difference in FireSpitter versions from the one you have in Karbonite and the one I just updated a day ago (as I also assist with FireSpitter) is the KSP version.

So in short, bundling will continue because some of these dependencies (CRP, FireSpitter, CTT, etc.) expect a certain folder. But the nice part is that all of these use KSP-AVC, so there's no reason to wonder whether you have the current version or not.

- - - Updated - - -

Side note - I do not 'force my own FireSpitter' - I use the one that we all share (and that I help maintain).

So when KSP-AVC warnd you, you just delete the folder, and dump in a new version. Problem solved.

[almagnus1]

Another possible solution to this issue is to essentially sandbox the mods from each other in a way similar to what the Minecraft modders did with the Forge Mod Loader, which is enforce a specific structure of where things are within the mod JARs are located, and refuse to load non-compliant mods. The way this came about in Minecraft, however, was that one of the modders basically decompiled the Minecraft code, and set it up so that development using the Forge Mod Loader greatly simplifies development and loading of mod assets.

Until some KSP analog for the Forge Mod Loader exists, we're gonna continue to have this problem (either perceived or actual) of things in Gamedata folders not being right/overwriting/whatever.

The advantage to this approach is the simplification of modding KSP, as the only mod you absolutely need to install is the loader mod, then you can throw ZIPs/7Zs/RARs/whatver of all of the other mods into a single directory, and then the game structure is created dynamically. It also simplifies support, as the loader mod would be responsible for loading everything else, and you can get extremely accurate information about what is/isn't loaded because the loader mod would know everything.

The downside is that the format for the archive must be agreed upon, code written for stuff that may not be possible with KSP, and enough other mods support something like this for it to take off and become a de facto standard.

Then there's the issue where the old .NET version that the older versions of Unity that KSP is using may not have key parts of the API to make this work easily (or quickly).

It's not an easy solution, but as far as the average player is concerned, it would greatly simplify the modding process as something like CKAN would just need to maintain the loader mod and throw mods in a directory, and the loader mod would take care of the rest.

[Diazo]

Mods "place files in another mod's folder" for two reasons.

1) The mod is a using another mod as a dependency. See Firespitter, every mod that adds a part with a propeller to the game uses it (as far as I am aware). But multiple copies of Firespitter installed lead to problems as well. Therefore the Firespitter Devs say "install here" and all mods that use Firespitter distribute it so that it installs there and everything works great. This means that the mod using Firespitter "places files in another mod's folder" to install Firespitter correctly.

2) To mod another mod. See Realism Overhaul. There are some tweaks that require changing the files in the original mod's directory to apply so that is how those tweaks are done.

Both of these are valid use cases and the scope of what mods using these methods can do makes it very much worth the slightly larger installation hassle.

And all that hassle makes you do is check date/time stamps when your computer gives you the overwrite file warning. Are the dates different? Then you are installing a different version and you will have to take a couple minutes to check the forums if you have issues running that mod.

@almagnus1: We essentially have that already in KSP, it is the Part Loader (technically just the Loader, but 99% of modding is done in the Parts section). Then ModuleManager allows a mod to interface with KSP and make the changes a mod requires. The BEFORE/FOR/AFTER/NEEDS/FINAL keywords in a ModuleManager script is how dependency across different mods is handled.

So is it a little more hassle to keep track of this issue? Yes. Is it worth it for the more complex and varied mods in allows us to have? YES!!

D.

[sarbian]

Calling the JARs of Forge a solution is nearly a joke. Sure they need to be in a specific folder but nothing stops a mod from storing or writing data elsewhere. They exist because java include a native mechanism to easily make jar look like a directory (gross simplification here). That system has the advantage to allow mods to be mostly one file (but most are not) but kills end user customization.

--- Edit---

To make it clear : Forge is a great API, not a great mod packaging.

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

As Diazo said we already have class that handle the loading and we could mod most of them but there is no real need so far.

I am not saying that we have a perfect system but I think it works fine. And we have a good mod manager that handle the hassles and has reactive devs.

If we want to look for improvement we may want to look into City Skyline. They run Unity like we do and their mod loader allow from hot reloading of dll. This is the kind of things we could use to make dep easier (add version numbers to dll and use magic to have only the last one load)

Edited June 30, 2015 by sarbian

[almagnus1]

Hey, I'm just throwing out a possible way to deal with the issue that the OP is describing, and also clean things up as far as mods go (like building a virtual directory and "extracting" stuff to it as it's needed). Is there a better approach?

And as far as .NET goes, if we ever get to .NET 4.5, then some of the APIs at this part ot the Framework may be useful towards that end: https://msdn.microsoft.com/en-us/library/System.IO.Compression(v=vs.110).aspx