Combining efforts on proper mod management framework / tools / platform

[keks]

Post below is mostly outdated. Hit the following link to see an up-to-date version:

http://forum.kerbalspaceprogram.com/threads/85989-Combining-efforts-on-proper-mod-management-framework-tools-platform?p=1378713&viewfull=1#post1378713

---

Hey,

as for the immense number of mods out there, there definitely is a need for proper mod management tools and platforms. There has been are quite a few attempts to create such tools / platforms (http://ksp-avc.cybutek.net/, http://forum.kerbalspaceprogram.com/threads/26031, http://forum.kerbalspaceprogram.com/threads/13155, to name a few). To me, neither of them satisfy my needs for such a tool. In my opinion mod management should include:

• easy installation
  
  • via built-in search
    
  • via copy & paste of mod URL
    

  [*]reasy removal

  • via simple [remove] button
    

  [*]easy version control

  • install specific version of selected mod
    

  [*]dependency management

  • no more re-distributed third-party mods included in mod
    
    • module manager for example is being shipped in different versions by many mods
      

    [*]automatic installation / update of dependencies

    [*]automatic removal of auto-installed dependencies

  [*]unified mod directory structure

  • currently, each mod seems to have its own directory structure, instead of one standard (GameData/[Author]/[Mod]/{Plugins,PluginData,Parts,Flags,...})
    

I'd like to start such a project, working hand-in-hand with the mod/content developers, provided that I can find some talented, professional-working developers here.

I'm planning to use git as foundation and build upon that (similar to https://github.com/kerpak/Kerpak, but with unified, standardized structures). The actual content (the mod) is then to be stored on a git hosting provider of your choice, as long as they support anonymous, direct access to files.

By using git for both, development and content distribution users can see what changed, when and why. I'm currently using about 100+ mods, and it is a pain in the ass to update those whenever a new version of KSP gets released. Mostly because I do not really know which files came from which mod and what changed.

I want the original developers to have the option to easily opt-in to this management solution, or, if they themselves do not want to change the way they work, let someone else maintain a ported version of their mod and continually merge new versions into the ported version.

One problem will be unlicensed content. We'd have to find a way to support unlicensed content, without violating the copyright of the original author. I thought about some kind of meta-packages containing all the information needed by the mod manager application, as well as a link to the original source. This way (I think) we would not violate the copyright and could still integrate non-licensed work.

Another point would be to further integrate mods like CLS into other mods by providing ModManager configuration files. By Using GitHub, that could be done by a simple pull-request.

As for the framework: It's also a pain to debug most mods, because they do not add log-prefixes to their log entries. This way I get a ton of log messages which I cannot easily find out which mod caused them. My favorite message is "[EXC] NullReferenceException: Object reference not set to an instance of an object" on which I spent a whole weeks to find out which mod caused this message, because It only occurs when some special conditions are met... I'd like to fix that by patching the original sources and replacing all the mod's logging calls by proper ones, including mod name and line of code. Either in cooperation with the original developers, or as redistribution under the terms of the respective licenses.

As for the size of this project and my limited available time, I'd need at least 3 or 4 supporters, helping with development and maintenance.

Is there any interest here in such a solution? I'd really like to combine efforts with some other ModManagement solutions and build upon that, if there is any interest. No need to re-invent the wheel over and over again.

Edited August 27, 2014 by keks

[dudleypippin]

Having recently taken an hour or two whipping up a bash-based mod manager for OSX/Linux, I've determined that it's useless until the mod packagers standardize on file structure. Just downloading and looking through the zipfiles of ten different mods on curse was enough to make me give up in disgust. (My sample mod seemed ok, but then I grabbed one that included toolbar (which conflicted with the next that included a different version), and the next included a GameData folder instead of being a folder to include _in_ GameData, and then conflicting files named "ReadMe.htm", etc., etc.)

I assume the mod coders have discussed this; was there a consensus that they're working towards?

[dudleypippin]

Ah, here's another attempt at what you're suggesting: http://forum.kerbalspaceprogram.com/threads/64058-PROPOSAL-Package-Manager-style-for-KSP-Mods

To be honest, the pushback from the mod authors in that thread is clear:

And besides that, the main reason there are multiple standards is that everyone thinks that their standard is the best one. It's not laziness, it's modders choosing what they perceive to be the best method of organizing things.

and:

...but the system we have now is already ideal in most ways

There's also disbelief that trolling through zipfiles and figuring out the important bits and what goes where is something to be improved upon.

Good luck!

I think I'm going to go give up and spend an hour getting all the mods set up so I can finally go play .24 a bit. Looking forward to doing it all again when .25 comes out! ($DIETY forbid I actually try to determine what's been updated since I've installed them...)

[keks]

[...] I've determined that it's useless until the mod packagers standardize on file structure [...]

That's why I'm aiming to create a mod repository. Mods hosted there will have to follow certain rules on directory structure, providing a readme-file, a proper license, etc.

With my proposed concept the Mod-developers would not need to change anything on their side, as long as they follow some kind of standard in their releases.

Then we could create simple mod-specific makefiles compiling the mods and creating the standardized package file which then gets uploaded to the repo.

Even when they change standard from time to time, all we'd need to do is update the makefile accordingy.

In combination with git we'd always see what changed on developer-side, and what changed on repo-side between versions.

Also, we could re-distribute modified/patched versions of mods and send pull-requests/patches upstream to the original developers.

Edit:

This is how such a repo could look like: https://github.com/ksprepo.

So far it's just a proof of concept. It's not complete, everything (including commit history) is subject to change.

See DRE for an example: https://github.com/ksprepo/ksp_deadly-reentry.

Edited July 23, 2014 by keks
Added sample repo

[TheAlmightyOS]

I agree with the concept. I do not believe it will catch on. At least, not without a significant show of force by Squad.

At my work I deal with developers. Great people till you start telling them what to do. They get it in their head that they know EXACTLY what the end user wants or the best way label their code. Out of 13 Devs, they each have the RIGHT way to do things and everyone else is wrong. Then when something goes wrong it's the users fault, every time. And Modders are WORSE. Once again. GREAT people. Some of them downright awesome. Start telling them they must do something that is not required by the program and they resist

There IS a solution to this: FORCE STANDARDIZATION AT THE PROGRAM LEVEL. They will moan and cry and throw their temper-tantrums. But in the end, almost all mods will conform to minimum set of standards and most of the headaches will go away.

IMHO, I do not feel like a Repo is a way to go about it. Don't get me wrong, I am a 'nix guy myself and think repo's are an awesome way to keep your system (or program) up to date. And if you could GET the modders to use it and someone could code some sort of mod organizer/updater then it would be perfect for KSP. BUT: You got to get the moders to use it

Right now we got ~500 mods in the forums (just a quick and dirty query to get that number. don't know how many of them are active), another ~200 on Curse, 37 @ github KSP Mod Repository, and 4 have found their way to the Nexus (wtf?). There is another site out there too I just can't find it. Now, a lot of these numbers are replications such as a mod author posting to the forum, github and curse, still you can see for yourself the massive disconnect. We got modders posting everywhere

It's not WHERE that we need to change. It's the HOW. You make your repo, put in the requirements for a successful submission and then....what? the devs that don't like your way of doing things will just use another way to submit their mod. What is needed is end point changes in how mods are installed and maintained in KSP and that has to happen at Squad's level. It does not have to be much, a file required in each folder under GAMEDATA that has the mod information in the correct format would suffice.

But, unfortunately, all this is talk and not even productive talk. Nearly everyone looks at the current situation and knows it's no where near ideal but until we can get someone from Squad to sit in on this convo and actually hammer out something that would work for 84.7% of the community I foresee this situation getting worse.

However, something DOES need to be done

[TeddyDD]

I'm workin (rlly slowly) on something similar. But my idea is little different. I do not think we can force modders to use any standards. My idea is to use json files with all mod informations and directory structure (example: where in zip is GameData dir) and direct link to download mod (dropbox etc.) This is quick dirty example of package json file http://pastebin.com/1FWeC82Y

[TheAlmightyOS]

I'm workin (rlly slowly) on something similar. But my idea is little different. I do not think we can force modders to use any standards. My idea is to use json files with all mod informations and directory structure (example: where in zip is GameData dir) and direct link to download mod (dropbox etc.) This is quick dirty example of package json file http://pastebin.com/1FWeC82Y

Ok. That is a thought. But who is going to maintain the json files? You said yourself we can't force the modders to use any standards (and I agree) so who is left holding the bag?

[Justin Kerbice]

@keks: what you propose is very close to Debian system in which some people (debian "developpers", one or more people in a team) create packages from software made by some other people (typical example: the Linux kernel). Their duty is to care about source software, make a proper package (with all files needed for the system to work), check dependencies, compile the source if relevant, ...

Even is this system, there is big flaws as some wants to rush their package(s) into a release and mess up with potentially a lot's of packages, worth example: wrong dependency on libc6 version.

Anyway, it could be achieve for KSP modding except one huge item: licence.

Squad team made them mandatory for add-ons, but most people seems to don't know exactly what's exactly it is and just pick a random one then they sometimes add their own terms outside the chosen license (like no redistribution allowed for a CC licensed contents) all of this just to say that you'll face a big wall of repulsing/opposing forces, some won't let you touch their mods in any way, some won't allow redistribution, some this some that, ...

I'm not stubborn and I'm open to any system which could really make things easier for everyone, but I'm not confident on getting any standard tool/system any time soon.

Perhaps you can make people change their mind not by forcing them (the stick), but by showing them how much benefits they can get with it (the carrot).

[TheAlmightyOS]

Perhaps you can make people change their mind not by forcing them (the stick), but by showing them how much benefits they can get with it (the carrot).

What do you propose as the carrot? Not being argumentative, just curious about your POV. I personally see no benefit that could sway the current modding community into standardization.

[Justin Kerbice]

What do you propose as the carrot? Not being argumentative, just curious about your POV. I personally see no benefit that could sway the current modding community into standardization.

I didn't wrote anything on this because for now I have no idea on it, but keks mention "forcing people" thing, which lead to more or less a failure. The carrot could be anything from more support from players, more "reputation", better compatibilities over KSP version and dependencies, easier to find mods (=more use from community) if at some point, such system would be integrated to the official KSP launcher.

Standardization can also lead to less work, looks at tools like dh-make-perl (a debian helper which almost "convert" a perl module package into a debian package source), it's help a lot by doing a big part of the chore, following the idea, if we have a "modgen" tool which:

when invoked like (example of a CLI tool)

modgen --name="myawesomemod" --version=+0.24.2 --type=parts --archive=zip --dep=modulemanager

-create base directory structure

-add a version control file (for use with KSP-AVC for example)

-add a dummy readme

-create a script to create an archive automatically

-compile the plug-in automatically + create an update script for KSP update (this script recompile against the specified KSP version, create the archive, add a dummy changelog entry, ...)

myawesomemod-files/
    GameData/
          myawesomemod/
                 Parts/
                      ...
     readme.txt
     myawesomemod.version
     modzip.sh (or bat or anything)
     ...

There is plenty of room to make modders life easier, just need to know what was the most boring tasks done I guess, and strike there.

[TeddyDD]

Ok. That is a thought. But who is going to maintain the json files? You said yourself we can't force the modders to use any standards (and I agree) so who is left holding the bag?

I assume that there will be people willing to help. If the package creation will be a simple of course. I think part of data in the json file can be generated automatically by the tool for creating packages. Maintainer will have to enter only some information.

Another thing is my idea helps to avoid problems with licensing. As long as mod is on hosting with direct links

Distributing a package with information about mod is not redistribution a mod itself

Edited July 29, 2014 by TeddyDD

[keks]

Good to see some discussion going on in here

[...] You got to get the moders to use it [...]

[...] You make your repo, put in the requirements for a successful submission and then....what? the devs that don't like your way of doing things will just use another way to submit their mod [...]

Of course it would be great if we could get all the modders to use such a standardized system, but with my approach this is not necessary. As longs as we get someone to maintain the mod, the original modder does not have to do anything at all. They can still use the forums for distribution, then some maintainer picks up the new version and updates the repo.

As already stated earlier, we could create some helper scripts to create and maintain mods. A simple makefile-style approach could eliminate the need for the modders to change their directory structures. We could redistribute their mods as-is and provide a build-script which puts everything in place.

We could even make these scripts easily customizable (GUI frontend, maybe) for the end-user. Let them select what they want and where they want it.

[...]Even is this system, there is big flaws as some wants to rush their package(s) into a release and mess up with potentially a lot's of packages [...]

That should not be a problem at all. It would work like it does right now. We add dependencies, but we do not make them 'fixed'. You will still have the option to install packages ignoring its dependencies. Just like dpkg/apt works under debian. I'd also not maintain 'stable' branches. I'd just host the releases, and let the end-user decide which version to install. We could of course provide a 'latest' branch, always pointing to the latest release.

[...] Anyway, it could be achieve for KSP modding except one huge item: licence. [...]

We do not necessarily need to redistribute the mod itself, if the license does not allow that. As already stated in my earlier post, we could provide meta-packages pointing to the original release (for example the download link on the forums) and just distribute additional meta-data, like dependencies, proper readme files, build-scripts, etc. This way we do not violate any copyright at all.

[...] Perhaps you can make people change their mind not by forcing them (the stick), but by showing them how much benefits they can get with it (the carrot). [...]

That's the plan. That's why I aim to create a system in which the original authors do not have to change anything about how they develop / redistribute their mods, unless they want to. I aim to only add features, not forcing to change anything related to mod development.

][...] but keks mention "forcing people" thing, which lead to more or less a failure [...]

I don't remember writing anything about forcing anyone to do anything. In fact, that's the opposite of what I aim to do (see me initial post). In my opinion that's the reason why the other projects failed, because they tried to force modders into using their system. I do not want to do that, I want a opt-in solution, which also enables the community to maintain packages themselves, if the original author does not want to.

The integration-part really only consists of maintaining a build-script which puts things in place, and pushing changes to the repo. That's it.

[sarbian]

[*]currently, each mod seems to have its own directory structure, instead of one standard (GameData/[Author]/[Mod]/{Plugins,PluginData,Parts,Flags,...})

You'll have a hard time making me adopt that one.

Putting the issue of making modders agree on something aside, you're scheme look complex. You are far from the first to come up with a variation of the "let's use something that works for linux distrib" theme. But most of those schemes require modders to use (CLI) tools that may not be available or easy to use on their platform. It's one more hoop to jump thru for people who learn modding...

As fo the end users... do you expect player who need a tutorial to launch the game in 6bit to use a CLI tool and install their dependency ?

[AlphaAsh]

At my work I deal with developers. Great people till you start telling them what to do. They get it in their head that they know EXACTLY what the end user wants or the best way label their code. Out of 13 Devs, they each have the RIGHT way to do things and everyone else is wrong. Then when something goes wrong it's the users fault, every time. And Modders are WORSE. Once again. GREAT people. Some of them downright awesome. Start telling them they must do something that is not required by the program and they resist.

This. If you're going to do anything like what is being proposed in this thread, you're going to have to have a front-end that modders will want to use and then a back-end that does what it is that you want it to do. And even then you'll not be able to automate everything in that back-end. Not possible. You absolutely will not get modders conforming to anything.

[TheAlmightyOS]

This. If you're going to do anything like what is being proposed in this thread, you're going to have to have a front-end that modders will want to use and then a back-end that does what it is that you want it to do. And even then you'll not be able to automate everything in that back-end. Not possible. You absolutely will not get modders conforming to anything.

You are absolutely right. Modders will only change if A) They have to (program requirements change) or They [darn] well please

I did not have a chance to read though all the suggestions, but has anyone thought of an auto-publishing tool?

The modder would open the tool, type in the changes made this version (auto-appends the readme), drag the files into their appropriate sections, update other tidbits of information, press "SEND" and BOOM: Forum updated. Curse updated. Kerbal Stuff updated. Add your location here - Updated. The program zips up the data in a specific, standard format and sends it out. All we would need are the API's which should be easy enough. There are programs that automate tasks on forums other websites all the time. I know I am making it sound easier than it is but I know this can be done.

[keks]

You'll have a hard time making me adopt that one.

Putting the issue of making modders agree on something aside, you're scheme look complex. You are far from the first to come up with a variation of the "let's use something that works for linux distrib" theme. But most of those schemes require modders to use (CLI) tools that may not be available or easy to use on their platform. It's one more hoop to jump thru for people who learn modding...

As fo the end users... do you expect player who need a tutorial to launch the game in 6bit to use a CLI tool and install their dependency ?

Not to be rude, but I think most of the people here did not even read (or maybe not understand) what I am proposing here. As already stated several times, I do not want to force modders into anything at all! I do not want to force you to adopt a specific way of development. I do not want you to use CLI tools. I do not want you to care at all unless you decide to do so.

The actual work would be done in one or multiple files providing some information, like what goes where, which license is used, which dependencies exist, link to original content ...

All someone (does not have to be the original developer at all) would have to do is maintain these meta-files.

Modders would still use their own workflow, their own tools, their own directory structure, ... and we would just provide kind of a management tool which puts things in place. When using such a tool the underlying structure does not matter anymore, and we'd be fine with every mod using its own structure as long as there are no conflicts. Of course, I'd like to standardize directory layouts, but that would cause several mods to break because of hard-coded paths. But we really do not need to do change the layout for my proposal to work. Thats the whole idea behind it - I do not want to change anything, instead I want to add features to existing content.

So lets say we have a mod named "ModuleManager", and a mod "SomeCrazyComplexMod":

By default MM only consists of a single file called "modulemanager_[version].dll". Where as our imaginary 'SomeCrazyComplexMod' consists of several deeply nested directories and also ships a lot of unnecessary content for whatever reason. Additionally 'SomeCrazyComplexMod' changes directory structure every time a new release comes our, because the developer suffers from schizophrenia.

When installing mods by hand, this kinda sucks, because you cannot simply drop in the new version. This would cause multiple versions MM being installed at the same time, and result in a corrupted 'SomeCrazyComplexMod' installation.

So you will have to go through each mod and figure out what changed and what goes where manually, every time you update your mods. In my case, I have to update over 100 mods... Last time I updated them I spend a whole week updating them, as well as hunting down incompatibilities. That's why I didn't update to .24 yet, because it's just a pain in the ass...

So with my proposed solution we would provide a file 'meta.yaml' with the following contents:

https://github.com/ksprepo/ksp_module-manager/blob/673288e1f651d5ecef20320da15f9f78e10c6318/meta.yaml

In addition to that, we would provide information where the files go:

filemap:
  - source: '/^modulemanager(\.\d+)+.dll$/i'
    target: 'GameData/ModuleManager/Plugins/ModuleManager.dll'
    sha512: fb48a92f6641191a0f580f3d73aa627b415ba1530f684ed1bd4dd3b14f9cfda4128ee0f7711ded6a93b27ad619fdbf91f5f9337a37787255c4ceaed541b6f8d4

or for 'SomeCrazyComplexMod' respectiely:

filemap:
  - source: some/file
    target: GameData/SCCM/real_name
    sha512: aeae379a6e857728e44164267fdb7a0e27b205d757cc19899586c89dbb221930f1813d02ff93a661859bc17065eac4d6edf3c38a034e6283a84754d52917e5b0


  - source: very/deep/directory/structure/archive.zip
    unpack: GameData/SCCM/Parts/
    sha512: 2d58ba046462be04415ee0d39243c6893c36f3ae438b5b20fa32e5596227ead4c94599081acd1c603aad80088eb58b795683dde7e14c579e4bdae820e3628c33

We could also (as already stated earlyer) provide meta-packages for unlicensed content via the meta-files:

filemap:
  - download: https://ksp.sarbian.com/jenkins/job/ModuleManager/lastSuccessfulBuild/artifact/ModuleManager.2.2.0.dll
    source: '/^modulemanager(\.\d+)+.dll$/i'
    target: 'GameData/ModuleManager/Plugins/ModuleManager.dll'
    sha512: aeae379a6e857728e44164267fdb7a0e27b205d757cc19899586c89dbb221930f1813d02ff93a661859bc17065eac4d6edf3c38a034e6283a84754d52917e5b0

We could also provide standardized version strings. Some people here use dates, others use numeric versions, others use alphanumeric versions, some use release candidates, etc... We could add a repo-specific version string (most likely M.m.p.b-v format) which exactly identifies a dependency version and add a map mapping these custom version to the official ones like so:

versionmap:
  '2.2.0.0': 2.2.0
  '2.2.1.0': 2.2.1
  '2.2.1.2': 2.2.1b
  '2.2.1.2+ksprepo-1': 2.2.1b

This of couse may cause collisions, but then all we'd have to do is bump the version by one. We also have the option to provide hotfixed versions (for example for future releases of KSP) for mods not updated yet (last example). See B9 for an example. When .23 came out it was quite a bit of work to find all the hints and workarounds spread all over the forums to get it working correctly.

We could provide a easy-to-use GUI for end-users in which they simply have to put the original mod-url (on the forums, on curse, on the repo, ...) and the tool then maps the entered URL to a mod repository. Downloads the meta-file and the actual mod, puts everything in place, checks dependencies, notifies the user of known compatibility issues, etc...

This could really become a very powerful tool for both, users and the modders. We could integrate automatic build, test and publish functions which automatically upload new version to the repo.

My goal is to create a tool that just works out of the box with no configuration effort at all. For both, modders as well as end-users.

Edited July 31, 2014 by keks

[TheAlmightyOS]

Keks, I am reading though what you want to do and, I am sorry, I am just not understanding what you are attempting to do. If I am reading your posts correctly, then in order for what you want to work each mod will need to be packaged with a meta.yaml file that may or may not be created by the modder. if it is not created by the modder it would be created by the user.

Are you saying, that a group of individuals are going to create and maintain these meta.yaml files? A program? The IDEA of the file is fine but WHERE in the process is it being created?

[keks]

Are you saying, that a group of individuals are going to create and maintain these meta.yaml files? A program? The IDEA of the file is fine but WHERE in the process is it being created?

It would work the same way it works for package maintainers over at [insert linux distribution of your choice here]. When some individual (may be the modder himself or some random individual) decides to become the package maintainer, all he really has to do is create said meta file(s) and update them accordingly when the mod was updated. So the workflow could be as follows:

1. modder creates a mod
   
2. modder creates a meta-file
   
3. modder uploads the mod including the meta file to [insert ksp repo name here]
   
4. modder updates his mod
   
5. modder updates the meta-file
   
6. modder uploads new version to [insert ksp repo name here]
   

or with an external maintainer it could be like this:

1. modder creates a mod
   
2. modder uploads mod to [insert distribution channel here]
   
3. maintainer picks up released version
   
4. maintainer creates meta-file
   
5. maintainer uploads mod and/or meta-file to [insert ksp repo name here]
   
6. modder uploads new version of mod to [insert distribution channel here]
   
7. maintainer picks up updated version
   
8. maintainer updates meta-file
   
9. maintainer uploads new version to [insert ksp repo name here]
   

So because we (ideally) only add meta-data, it really does not matter who maintains the mod, as long as the maintainer is somewhat reliable.

[TeddyDD]

That's what I was thinking from the beginning. The ONLY standard of what we need to introduce it a standard packet metadata format.

Then people will be able to use it in their projects (eg mod managers, packet generators, or even mods).

-Package format should be discussed and approved by all interested persons.

-It should be carefully thought out, so we did not have to modify it soon because it could cause a incompatibility of different tools.

-In addition, these packages should be based on any known format, so it was easy to parse it in different programming languages ​​(I think about json or yaml but maybe you have better suggestions?)

I'm curious what you think

BTW. Sorry for my English if I made any mistake

Edited August 1, 2014 by TeddyDD

[TheAlmightyOS]

So the workflow could be as follows:

1. modder creates a mod
   
2. modder creates a meta-file
   
3. modder uploads the mod including the meta file to [insert ksp repo name here]
   
4. modder updates his mod
   
5. modder updates the meta-file
   
6. modder uploads new version to [insert ksp repo name here]
   

or with an external maintainer it could be like this:

1. modder creates a mod
   
2. modder uploads mod to [insert distribution channel here]
   
3. maintainer picks up released version
   
4. maintainer creates meta-file
   
5. maintainer uploads mod and/or meta-file to [insert ksp repo name here]
   
6. modder uploads new version of mod to [insert distribution channel here]
   
7. maintainer picks up updated version
   
8. maintainer updates meta-file
   
9. maintainer uploads new version to [insert ksp repo name here]
   

Ok. now that I understand what you want to do I have to say that I do not agree that this will work. Once again, not trying to be argumentative. There are three major flaws I can see with this

1. Mod Authors will not do this
   
2. Mod Authors post their mods to (at last count) 6+ different and district locations
   
3. When you do have a team of dedicated maintainers checking everywhere +Mun for mods and uploading them into the repo, WHO is going to use said repo?! Like I said in #2, there are already 6+ locations to find mods. This repo would make 7
   

I don't want to fight you cause I know deep down we want the same thing. But in my opinion this would create more chaos, not reduce it.

In my eyes, our only option (and yes, that is opinion again) is to fully back one of the currently used Mod hosts (my choice is Kerbal Stuff) and work on creating tools for devs/authors to produce standardized packages.

[TeddyDD]

1. Mod Authors will not do this
   
2. Mod Authors post their mods to (at last count) 6+ different and district locations
   
3. When you do have a team of dedicated maintainers checking everywhere +Mun for mods and uploading them into the repo, WHO is going to use said repo?! Like I said in #2, there are already 6+ locations to find mods. This repo would make 7
   

1.At the beginning probably not, but over time may see the benefits of this solution.

2 and 3. Most important mods first appears on the forum. In practice, maintainers must check only forum.

We will not upload mods to the repository. We will upload only small files containing information about the mods. Mods will be downloaded from its orginal location.

The repository will be used by mod install/update tool.

[TheAlmightyOS]

1.At the beginning probably not, but over time may see the benefits of this solution.

2 and 3. Most important mods first appears on the forum. In practice, maintainers must check only forum.

We will not upload mods to the repository. We will upload only small files containing information about the mods. Mods will be downloaded from its orginal location.

The repository will be used by mod install/update tool.

Ok. I am with ya so far. I still have a few issues with your plan but for the sake of frying bigger fish let's fast forward a bit

In your plan, you have a client side tool that connects to multiple points (repo, all various download points) to keep the user updated and to install (search for?) mods.

Why not take it just one step further...

Make it a Mod Submitter/Installer/Updater tool! Someone mentioned offering the authors a carrot earlier and I can think of no bigger then a tool that uploads and updates their mods over multiple locations with a click of a button. The program would standardize the submission format, generate the info file and, basically, do all the leg work. All the Author would have to do is set up his or her account settings to the various web services when they first set up the app then add the updated information when they create a new mod. And then updates are a push button away.

[keks]

[...]Make it a Mod Submitter/Installer/Updater tool [...] standardize the submission format, generate the info file and, basically, do all the leg work [...]

That would ultimately be the result of having such a standardized, central repository. But as you already said, we cannot make modders use it. Maybe some will, but certainly not all of them. I wanted the repo to e opt-in, so people and modders can use it if they want, but do not have to. We'd still be compatible with manual installation, not break anything, but (as already stated earlier) offer additional features like dependency management, easy update, etc...

I also already mentioned the possibility of integrating build/test/publish-tools as soon as we have managed to create some kind of stable environment (including a detailed specification).

There would really not much work for modders/maintainers to do to enable support. For most of the mods their basic structure does not change, so they would only need to create such a meta-file once and in future only need to update the release version string as well as dependencies. Thats (ideally) two lines of a plaintext file to be changed and can easily be automated with most IDE's and a little scripting with will ultimately (if done right) result in no work for the modders at all.

We could also (at some point later) implement some kind of opt-in statistics and crash-report plugin. There already exists some statistics plugin here upon which we could build (given the author agrees to work together with us). It may be a great help for modders to actually get standardized crash report data (including OS, architecture, version, installed mods, external dependencies, logfile entries, ...) instead of some vaguely phrased reports on the forums like the good old "it does not work.".

Over time I'd really like to make this a complete and overall consistent solution to all the modding problems we currently have. Publishing and installing mods could be as easy as pushing a single button and you are done.

I'd really like to work together with some of the modders here. Especially the some of the bigger names. At the end-user side it's pretty clear what we want to see, but I'd also like to hear what features modders would like to see on their end. What features they would like to have and how things should be organized for them. For example would you like to see an external standalone application or a tool integrated with your IDE? Could we get at least some of you to agree on a standard directory format (it's really not that complicated to follow squad's proposed format and wrap it up inside a directory representing your namespace ...)? Would you like to have a "publish" feature, automatically uploading your new release to all the distribution channels (any possible conflicts with terms of use here, we have to care about?)? I want your input and I want to create tools for you, too! Not just the end-user.

To the modders:

I think we can all agree on the fact that modding is a big mess right now. It works (kind of) but is definitely not even remotely comfortable for users, as well as modders, unless they have absolutely no external dependencies. You have a chance here to work together here, work with a team that listens to your advice and wishes. You certanly don't like the way it is right now, but you also seem not to want to change anything about it... Do you think the problem will go away on it's own? Cause It certainly will not unless someone does something about it. Squad does not seem to do anything, and I'm sure they have enough work on their own. So I don't think we will see anything from them any time soon. I know you don't want to change the way you develop (because 'your way of doing it is the best and the only way to do it right' ... blah blah everyone else is stupid blah - I'm a developer myself ) but the community would really benefit from working together, making life easier for everyone :-) - just my opinion on this topic.

Edited August 2, 2014 by keks

[TeddyDD]

Make it a Mod Submitter/Installer/Updater tool!

As keks said earlier such a tool will probably be created over time. If all goes well will be several (for different IDE and standalone)

The only problem I see here is that when writing such a tool would be needed support from web developers of mod websites (API that allows to upload mods)

I'm not sure if Curses has something like this

[Justin Kerbice]

@keks: good plan, lot's of ambition, but be careful, too much ambition at the beginning may lead to messy development (want to go everywhere at once like a rover with 4 wheels, each one on a side of a square ). Maybe a simple tool to start: create base directory tree + dummy files according to some parameter like debian packaging tool, then step up the game with dependencies management (not an easy part) and so on.

Beware of evil statistics gatherer and crash reporter, some noisy people don't like this (see the great controversy thread).

For plug-in author, a checker may be useful: check if a version is provided inside the dll info + eventually check against some fields, like mod version and warn if there is mismatch. I guess "auto" recompilation with a chosen KSP version may be a great tool too.

As a part creator only, I don't need so much, I even don't upload like crazy. But I have doubt about auto uploading, as it will need one module per website, and worth, check those websites (especially the commercial one like most of spaces providers) regularly for updates they don't talk about (quite like JDownloader tool which have tons of plug-in for almost each single one online storage website).