TeddyDD

We can guarantee the availability of modes with permissive licenses. These closed will disappear anyway. Open mods can be uploaded to dropbox/google drive or Curse and retrieved from there (or from oficial github releases). Using git submodules + github releases will be terribly time-consuming and complicated. Who will be responsible for the dozens of forked repositories? Agree. The more things can be done ​​on the client side, the better. Also I think mod tools are awsome, but do not have too much in common with mods management. I do not believe that any moder join us and start using this system. Not until it becomes popular among players.

You are much more experienced than me so I guess you're right. We'll do it your way. I will try to help if I could.

Precisely what I was doing. I started to write the specification as I prefer to work on concrete things. It's a point of reference. If there is something you do not like, let's change it. I started writing a manager to make it easier to determine the needs (and learn some golang) but this secondary project. I just want to have something to show. Even if the prototype will later be abandoned in favor of a better solution. I use this: http://bower.io/docs/creating-packages/ https://www.debian.org/doc/debian-policy/ch-relationships.html https://www.npmjs.org/doc/files/package.json.html But do not think that any of these systems could be used directly. I am willing to do anything, as long as the idea will be developed. If you know how to do better is simply Just do it. If you have an idea how we can consult the specification of the package I'm going to join and help.

It would be enough to clone the repository and use git pull. But try to tell a player that he has to install git :> No way. I think now the main goal is to facilitate the installation and updates. We focus on searching later. If someone wants to write a client that pulls the whole repository can use description field. Once I changed it already. I have to think about it. The idea is not to delete old packages only add new ones. You may want an older version of mod. Version in the file name will be needed. Program will read package version from file name. Version stored in the file is not necessary but I think I'll leave it as an optional field. Besides, I think we do not need field replaces. Implementation of this would be complicated and can be replaced with order of installation. And relationships between the KSP mods are fairly simple.

Field of categories will be a problem. I do not know how the client application can search the packages in the repository. We would need an index. Keeping it manually would be difficult, especially if the repository managed by more than one person. At the moment, the only information available to client is list of names and versions of mods for given ksp version. In this case, client would have to download all the packages from the repository to search by categories or keywords. I think users will have to look for mods on the forum. At least for now. I'm looking for suggestions on how to solve this problem. I like the ideas for fields. I'll add them soon. So far we have: depends, optional, conflicts, replaces, provides. All of this fields are optional.

Yep, I mean "authors". I change it today. Good suggestion. Category field is also nice, but I think it would be better to call them "keywords" or "tags" (but tags can be confused with git tags) Besides, I wonder if I should add a field "conflicts". I do not know if I will ever be needed. What do you think?

I think part of features you are talking about (voting, flagging, download statistics) can be implemented later. Somehow Progress: The initial version of the tool used to generate the packets based on the zip file: - reads the name and version of mod (usually) - generates the checksum - looking for mod's forum thread I'm going to add automatic detection of file structure in the zip archive. Sample output (ignore checksum, It was generated based on dummy file): http://pastebin.com/AZhmbkvW Maintainer must check the generated file, add some information, and the package is ready.

At the beggining I thought about adopting NPM or bower. I'm afraid that these solutions are not very suited for KSP. Aur is a great system, but it would be hard to adapt it to our needs. And in any case, I do not know how to do it. And these solutions requires the server. The idea that I'm working requires only a repository on Github. If anyone has any ideas on how to improve what I have created so far go here: https://trello.com/b/28wWVbaS/kerbal-packages-system Or here: https://github.com/TeddyDD/ExampleKSPrepo/issues?q=is%3Aopen+is%3Aissue Or write here, no matter Maybe we can create something together.

Working on this

I know what you mean In any case, I will continue to write such a tool even just for me. I hope I will not do some terrible mistakes with design and coding (I am a visual artist, not a programmer xD) At least I will learn something. We'll see what comes up. BTW, thank you. This topic motivated me to work. It is nice to know that someone thinks similar to me EDIT: https://github.com/TeddyDD/ExampleKSPrepo So far so good.

I got a drawing

I see that the discussion has died? Recently I've been busy trying to force Golang and node-webkit to cooperate xD Today I read documentation of github api. Very easy to get a list of files in the repository. And easy to download files in raw versions. Github is a really great place for a package repository I wonder... Github api returns json files. Personally, I prefer YAML, but perhaps packs should be in JSON too? Tools programmers do not have to worry about the two formats. Its not big deal I know, but it is better to simplify everything as much as possible. Edit: It's slightly expanded version of your sample package. In my opinion, contains all the necessary information to install this mod. It can be hosted together with the mod but its not required. http://pastebin.com/gnK7Yf48

From stable orbits you can schedule more precise maneuver. Besides, nothing.

We should talk to these people: http://forum.kerbalspaceprogram.com/threads/78861-Java-8-Win-Linux-Mac-Ultra-complete-Mod-Manager-v0-1-8-7alpha http://forum.kerbalspaceprogram.com/threads/26031-Win-KSP-Mod-Admin-v1-3-11-%281-4-0-PR-12%29-Mod-install-with-a-few-clicks http://forum.kerbalspaceprogram.com/threads/57284-All-OS-Java-MultiPlayer-Part-Manager-v3-4-2-March-2014-No-Support http://forum.kerbalspaceprogram.com/threads/85865-Tinker-Time-Self-Updating-Curse-com-Mod-Manager-for-KSP

@ferram4 That's why we ask you for an opinion instead of blindly create something. I understand that you do not need the extra work when creating mods. I appreciate your hard work. Without mods KSP would be nothing (still I don't understand stock players). When we do not find an appropriate solution we leave off. If you do not trust any third party package maintainers It can be difficult. I have to think about all this extensively.

That's something useful. In general, metadata should be as simple as possible: -basic mod info -version -download link -Dependencies and information how to unpack the archive. I think it will be hard to screw up something here. As for users... Nothing can help to human stupidity.

Nothing new here. Anyway I'll burn in hell We considered the needs of developers (about a format of file etc.) Fortunately they do not have any We just do our bit.

I just think that if we can do some things better then why not try it? I really like the idea of the metadata packages. I was curious about response of mod developers. Well... I understand your point of view. But I do not think that because updating mods in other games is difficult, in the KSP, we must be satisfied with what we have now. I'm not saying that is bad, but could be much better.

Do not count me as a developer but despite the fact that not all of your ideas I like I'm with you http://forum.kerbalspaceprogram.com/threads/89490-A-Modding-Community-Divided <- It's getting hot :>

The problem exists. You know how much time takes to manually update 30 mods?

I understand, but metadata files in your sample repository would not be independent. It would be best to package file always contain a link to the files and every information even if it is stored together with the mod. That's a point. We can mirror only mods, which the license allows it. Unfortunately, there's nothing you can do about it. I have always believed that mods with restrictive licenses is a bad idea. It is a pity that Sqad allows it.In any case, I am very glad that you created this thread. It's time to simplify process of installation and updating mods. I just spent about 40 minutes making sure that I have all mods up to date :> We need to find a convenient way to brainstorm with moders and the authors of mod managers and design metadata file that will suit everyone. This is the basis of the entire system.

Ok, thanks, that's something I do not really like the keeping mods together with metadata (there are many websites to keep mods) but I also see the advantages. In my view, the ideal solution would be if the metadata could be completely independent and to contain all the information needed to install mod by any program following this standard. This is my design of such a meta file. I worked on it in April and since then I have a lot of other ideas. There's a mess, unfortunately. Also its python file but you can guess how it works. http://pastebin.com/NWc5WjRV Of course, many fields from this file would probably be completely unnecessary like extends The main difference in our ideas is each metadata file would have name like MODNAMEvVERSION.some_funny_extension Then you would need a way to get a list of packages from the repository. Then the program will fetch the file with metadata. In this file would be link to download mod itself.

keks I have some questions for you because I'm not sure I understand what you mean. 1. Want to create a single central repository, or rather something modeled on Linux PPA? 2. Are you want to keep mods (zip files) in the same repo as metadata files? Or mayby want to keep the yaml files inside the archive with the mod? Or rather a repository of metadata not contain zip files, which would be taken from outside? Anyway in my opinion, the first thing to determine is the same look and feel of files that store metadata.

At the moment this site is 100 times better than the old SpacePort I hope that in time will become the main repository of mods. Congratulations, and best regards.

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