keks

The meta-file will always contain all information available. It does not matter if we host the mod or if it is an external mod. There's only one exception: the download url. We do not need this parameter for self-hosted mods, because they can (and should) be identified by their unique name.

These build scripts would have to be standardized and may not fit every developers environment. I'd prefer to not have to have the mods compiled by the maintainer, rather than just redistributing the binary release created by the original author. Forcing the developers to make use of unified build scripts is not better than forcing them to use a special directory layout. Thats actually exactly what I proposed. There are mandatory dependencies (debian's "depends") and optional dependencies (debian's "recommended" / "suggests"). As "suggests" vs "recommend" would be based on subjective personal opinion of the maintainer, I'd like to not distinguish between them. Instead this field was meant to list optional mods that extend the functionality of this mod in any way. The popular "Toolbar" for example would be a candidate for "optional" as most mods do not depend on it, but make use of it when it is available. I don't think you will get may modders to keep up support for more than one target version. There's really no point of doing so (IMHO) as KSP is still in early beta. I do not aim to maintain the mods code, fix compatibility, offer support, etc. All I want to do is taking away the pain of updating mods by hand. If we decide to host via git, we'd simply tag a release with it's proper version string. The client-side application can then get a list of these versions (for example through GitHub's API) and download the versions meta-data. Again, I do not want to maintain the mods, I watn to maintain meta data. That's something we could do later. At the start I'd do this on service-side rather than client-side to be able to easily change standards once problems arise. My opinion. Additionally Nexus is just another commercial platform just like Curse is. I do not want o rely on a external company. What I want is a open and free community of modders, maintainers and end-users working together, not because they want money, but because they like to do what they are doing. When using a commercial platform, we would be bound to their decisions. Just like Squad decided to take down SpacePort and replaced it by stupid Curse. Actually there is no big difference in our ideas. As I said earlier we do not have to (and in some cases cannot) host the mod data itself. The meta-data can be distributed independently to the actual mod-data itself, as long as both versions match up. In my scenario this would be realized via download-url and checksum in the meta file. the meta-file itself would be distributed through GitHub and tagged with the mod version. That way you can say "hey, give me the meta data of mod X version Y" and you will get a file pointing you to the actual download location for the mod data. One problem with external hosting is that we cannot be sure the file will remain available over time. Many modders just replace their uploaded files with new versions, making the old version inaccessible. This would not be a problem when we host the mods ourselves.

As a Debian user I learned to love their package management system and policies. I'd like to create something similar to that, where there is a controlling instance assuring the quality of the packages (or mods in our case) in terms of respecting defined standards. Like supplying a proper license, documentation, meta-information, etc... End-Users could ultimately add different repositories to their managing application, but that would be something to think about later. In the first step I'd like to follow a centralized approach, to ensure everything works as expected and to define said standards in a proper way. Once we accomplished to get the system working properly, we of course could enable other people to easily create and maintain repositories as well. I'd also love to work hand-in-hand together with KerbalStuff. We could provide all the information, and KerbalStuff could build upon that data and provide a great web-frontend for managing, indexing and manual downloading of the mods. But of course, that's totally in the hands of the KerbalStuff guys to decide if they would like to cooperate in such a way. Ultimately it would be nice to host both, the meta-information as well as the actual mod itself. That includes the source as well as proper pre-built binary releases. But as you might know that will not be possible for many mods, as long as they do not provide a proper license allowing us to do so. That's why I intend to support these mods through so-called meta-packages which would simply point at the original location of the mod, so the client-application can easily download it from there. The meta-information would in this case still be hosted by us and maintained by some volunteer maintainer. As in the example repo I put up and linked earlier (https://github.com/ksprepo/) I'd like to keep it all together where possible, but split it into three branches: * upstream: the original modders branch, where we keep track of the unmodified original content. So it would basically be a mirror. That would also allow us to easily send patches / pull-requests upstream to the modders. * develop: the branch maintainers actively contribute to, like creating meta-information, merging updates from upstream, applying hotfixes, etc... * master: the actual 'release' branch keeping track of versions we release. Both develop and upstream will almost always be exact copies of upstream, except the additional meta-data as well as (eventually) additional documentation and changes in directory-structure (if necessary). That truly is something to specify early, but first we need to find out what data we actually need and how it should be organized. The examples I mentioned earlier are really just a first draft to give you an idea of what I am talking about. The meta-files will have to follow a exactly specified scheme later. Else the repo as well as the client-application can't work with them Some things we need are: * title * author (may be multiple) * version * original source (forums / curse / etc - may be multiple) * mandatory dependencies * optional dependencies * license and copyright (may be multiple) * checksum * download url (for meta-packages) * file-map (where things go) any most likely some more.

I'm currently earning my money by developing applications and maintaining infrastructure, so I know how important extensive planning is. That's why I started a discussion here instead of blindly jumping into a project This would of couse be opt-in for both, the end-user as well as the mod developer. You would need to actively enable it yourself. Sane defaults and so on... I think I don't exactly understand this one. Could you please further explain the use-case here? EDIT: Oh, I think I got your point. Did you mean validating the assembly information against the contents of the meta-file? If so, of course that would be quite easy to do. For the auto-recompilation I am not so sure about. That would heavily depend on how the developers workspace is set up. Something we cannot and certainly do not want to influence in any way. But as already mentionend, building a IDE-plugin would absolutely possible (once we got the core structure up and running), providing such functionality. /EDIT Well, I think we don't necessarily need fully automated upload for all sites. I think a tool preparing as much as possible for you (update a text template for your post and properly pack up the mod itself) would be good enough for most modders. At least that would be something to start with, that can easily be implemented. You as modder would then only need to copy&paste into your forum thread / website and upload the prepared archive file.

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.

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: modder creates a mod modder creates a meta-file modder uploads the mod including the meta file to [insert ksp repo name here] modder updates his mod modder updates the meta-file modder uploads new version to [insert ksp repo name here] or with an external maintainer it could be like this: modder creates a mod modder uploads mod to [insert distribution channel here] maintainer picks up released version maintainer creates meta-file maintainer uploads mod and/or meta-file to [insert ksp repo name here] modder uploads new version of mod to [insert distribution channel here] maintainer picks up updated version maintainer updates meta-file 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.

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.

Good to see some discussion going on in here 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. 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. 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. 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. 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.

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.

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.

As for the formula: I was playing around with WasteHeat (Interstellar mod) to balance the formula. Produce/consume waste heat to compensate loss/lack, but that did not work out well, because (just like sunlight) it should not be a storable resource IMHO.

THIS IS JUST A PROOF OF CONCEPT I QUICKLY HACKED TOGETHER! GitHub: https://github.com/michaelkrupp/ksp_greenhouse This POC is based on 'BioMass Science+' (http://forum.kerbalspaceprogram.com/threads/53009). Here's a summary of what I did in addition to the ressources/numbers: * removed all parts, except the large greenhouse * simplified production - basically Sunlight + CarbonDioxide + Water + Waste = Food + Oxygen * replaced 'Kethane' converters by 'TAC' converters - They are 'less broken' in time warp and simulate resource consumption when vessel is not active * modified the greenhouse texture (I did not like the blue) This mod depends on 'TAC LifeSupport' v0.8 and has support for 'Connected Living Space' via 'Module Manager'. Most of the generator code was ripped from TAC/LS 'GernericConverter'. As already stated above, this is just some kind of proof of concept I quickly hacked together. I'm not planning to make a real mod out of this, providing continuing support etc. I currently don't have time for this. I just want to share my idea how a greenhouse in KSP could work in combination with TAC/LS, and I hope someone will pick it up and continue work. I tried to make the numbers 'somewhat realistic'. The numbers are based on heavily simplified chemical formula: (I really don't know if any of this actually makes any sense. I'm not much of a chemistry/biology guy) BioMass (glucose) = C6-H12-O6 Water = H2-O CarbonDioxide = C-O2 Waste (formacetal) = C-H2-(O-H)2 Food (sugar) = C12-H22-O11 photosynthesis: Sunlight + 6(C-O2) + 6(H2-O) = C6-H12-O6 + 4(O2) reproduction: Sunlight + 4(C-O2) + 1(H2-O) + 1(C6-H12-O6) + 1(C-H2-(O-H)2) = 4(O2) + 1(C12-H22-O11) + Seeds respiration: 6(O2) + 1(C6-H12-O6) = 6(C-O2) + 3(H2-O) germination: Sunlight + Seeds + 4(C-O2) = 1(C6-H12-O6) + 6(H-2O) The conversions are not 100% realistic in terms of preservation of mass. This is due to some floationg-point imprecision problems I encountered and balancing decisions I made. In combination with TAC/LS the only ressource you will have to really care about is water. The greenhouse will basically convert the CO2 and waste into oxygen and food using sunlight/electricity. TAC/LS can convert WasteWater into water and waste, as well as excess CO2 into O2 and waste. The rates of production/consumption will increase with the amount of biomass (or seeds for germination, respectively) using the following formula: factor / ln(1 + max_capacity) * ln(1 + amount_available) Known issues: * 'Electric Charge' consumption seems to be broken. It jumps up and down for no reason. * 'Sunlight' should not be a storable resource, instead it should be some kind of environmental variable. * the numbers may need further tweaking Contributions / External ressources: original 'BioMass Science+': seanth model: Roboto TAC: TaranisElsu

For some reason this mod fails when using time warp. Above 100% time-warp bio-mass and oxygen constantly decrease, while carbon-dioxide and water increase. At 100% time-warp it's almost stable. no increase/decrease on any of the above ressources. Below 100% time-warp everything seems to work fine. Running this mod on KSP 0.23.5 together with TAC/LS and a bunch of other mods. My test-setup consists of 6 large greenhouses, 3 micro biomes and a bunch of TAC/LS life support containers providing the ressources. Any Idea?