4o66

A day late and a [insert local currency unit here] short, but thanks, for many things: A wonderful tool for managing mods, especially when there was no other viable working solution Open-sourcing said tool, giving me a reason to step out of my comfort zone and take a crack at C# Accepting code changes from me and taking the time to email me back and forth when I had questions Allowing me to step in a provide unofficial releases where I could Your efforts, while unacknowledged, were greatly appreciated by many. Thank you.

Can one or both of you provide a link to your KSPModAdmin_aOS.cfg file? I would like to try and replicate this.

Can you give me an example URL for a mod that is packed this way? I will see if there is some way to detect better which file to use. You're very welcome, thanks for helping us to make KMA better.

When adding KIS (using http://kerbal.curseforge.com/projects/kerbal-inventory-system-kis) as the mod URL, it pulls the correct mod version. Can you provide and example mod that doesn't pull the version number? (Are you changing the modinfo, updating, or adding a totally new mod?) So after some testing, it turns out KMA gets the version from KIS via the .version file in the mod zip. Curse doesn't have a "version" field for the mod on the page itself, except if the author includes the version in the filename. Let me see if I can come up with a way to reliably parse out the version of the mod. On the plus side, I have figured out how to include the notes in the mod info imported into KMA.

It looks like this is fixed in the current development version (2.3.0.5) Until MacTee drops an official release, I have compiled a preview, you can get it here: https://github.com/4o66/KSP-Mod-Admin-aOS/releases/tag/2.3.0.5_Preview_1 Disclaimer: this may break your game, computer, set your cat on fire, etc. Backup your game files before testing this preview copy. There was, at one point, a CKAN plugin in the works. Not sure where on the roadmap it is now, but my coding skills are not quite up to that task yet.

The biggest issue with this is that mods themselves do not contain the dependency information in any of the version and info files. The dependency tree in CKAN would be a possible candidate, but it is at best unreliable since there is no mechanism for a mod author to explicitly control their own mod. (Based on my limited understanding of the CKAN database.) A possible fix to this would need adoption from the mod authors themselves using an agreed upon format to document Send me a copy of your KSPModAdmin_aOS.cfg (In the KSP base folder)? I assume you are right-clicking the mod and choosing edit ModInfos? Can you reply with the link of the mod you are trying to add?

I have pull requests up the the main dev repo: Fix for issue #140 (Require a downloads folder to be set before you can download mods) Added support for spacedock.info (Kerbalstuff successor)

It's been so long since I have seen that dialog I forgot about it. I'll are if I can make it less confusing. On Mac you need Mono, do you already have it installed? (The Mono project is mentioned a few pages up.)

Actually this should (and normally DOES) work. You can even shorten the URL down to just the mod number if you want, ex: https://kerbalstuff.com/mod/352 The code that handles URLs from kerbalstuff and curse strips them down to the mod ID since that is the minimum needed to identify the mod reliably. Are you clicking the browse button? You should be clicking either the "Add" or "Add & Close" button after pasting the URL. (As shown below.)

KSPModAdmin has an export feature: When exporting, you have two main options: Export with or without mod archives. (Both will allow you to either export all mods, or just a subset.) The export with Archives is useful for situations where not all of your mods are source controlled (they have an update URL.) The exported .modpack file is actually a zip file so you can open it with your favorite archive manager if you want to peak under the hood. (I suggest 7-zip.) Exporting as .txt is useful if you just want a list to print or post on forums, etc. This is possible in theory,but it is not a current feature. Please submit it here: https://github.com/MacTee/KSP-Mod-Admin-aOS/issues (Yes, development has stalled. I plan to help pick this back up once my school and work load lightens up a bit.) To the best of my knowledge, the crafts tab is only for craft files added by mods (and stock), not what you have in saves. Can you tell me what mods (with source urls) so I can try to duplicate the issue? I have never actually tried running under Linux with Mono. Based on the Mono project documentation you should be able to just run mono KSPModAdmin.exe (assuming you run it in the folder that contains KSPModAdmin.exe) Please let me know if that doesn't work, and I'll give it a go.

Expanded launch options is in the enhancement list. I am working on some underlying changes that should happen first.

PM MacTee for a direct link to the official release. (My fork on github has a binary release, but it is not the official package.)

My recommendation: 1. Fork the Dev Branch to your github 2. Clone that repo to your computer. 3. In your repo, 1 issue = 1 branch. 4. When issue fixed, merge that branch 5. Push to origin/master 6. Pull request to upstream/dev. 7. Profit! (Wait, can't: licensed under CC BY-NC-SA) Or if you are lazy like me and have a fork going that you don't want to scrap... Skip step 1 and 2, add upsteam as a remote, and fetch & pull the dev branch in local.

Found an issue with the GitHub integration, but not sure there is anything that can be done. The Active Texture Management Mod has multiple binaries with each release, 2 for x64, and 2 for x86. Since all 4 are under the same tag/release, the current implementation will grab the first binary of the release. Any way we can change this to ask user when multiple binary links are present (and store for future update checks?) Thanks!

Actually, with Git you want to pull now since you are in a branch. You will get any updated code that does not effect what portion you are working on. This way when you are done with your branch, merging back will be less painful. (Always pull just before a branch merge, makes the pull request back to upstream less confusing.)