Dazpoet

We're always happy to see PRs and I recommend you send it in for review so devs can see it and discuss it on github

Aww Yiss!

Please bring CKAN issues to the CKAN forum thread and don't bother mod authors with them. On a sidenote 1.7.9 is now indexed in CKAN, for better or worse.

We're looking into it https://github.com/KSP-CKAN/NetKAN/issues/1114 Thank you! I know about the mouse having to be active issue but I'm acctually not sure there's a github issue about it, please open one to let the devs know! RecvError in CKAN is often a website saying "I don't like you right now, please try again later". Seeing as it worked later I'd assume this was the case here aswell.

Thanks for the information

I'll look into fixing that one tonight, thanks! I can do nothing to fix your issue without information about the mods in question. At times thread titles do not accuratly reflect the currently supported version of a mod. We do our very best to ensure compatibility through contacts with authors and checking through threads for confirmation that the mods work for the versions added into the metadata. I've done some testing of the system and these are my findings. Mods marked for version 1.0 will work for _ALL_ KSP versions 1.0.x Mods marked for 1.0.z will _ONLY_ work for KSP version 1.0.z Mods marked for ksp_version_min 1.0 will work for _ALL_ KSP versions >=1.0, including 1.0.x and 1.y.x aswell as z.y.x Mods marked for ksp_version_max 1.0 will work for _ALL_ KSP versions =<1.0.x (not confirmed, but logic dictates this will be the case) Mods marked for ksp_version_min 1.0.0 and ksp_version_max 1.0.99 (I've seen this one hence the example) will work for KSP versions 1.0.x where 0=< x =<99 but will _NOT_ work for 1.y.z The best way to handle your mods working for multiple versions is a well updated and thought through .version file in a directory specified for installation in the mods .netkan file. Adding a ' "$vref" : "#/ckan/ksp-avc" ' field to your .netkan file and following the rules outlined at https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md#vref will allow your mod to work on all versions you want it to. With some luck I or somebody else will have the time to make a wikipage on this subject in the future, I'm sorry for the confusion.

If the mod generates a .config file after it's installation that file will stay. E.g. ModuleManager creates files upon usage and those are kept even if ModuleManager is created. CKAN will only change files which have been installed through CKAN. You need to run 'mozroots --import --ask-remove' NOTE: That command is user-specific so if you run CKAN as root you need to also run mozroots as root. All mods visible to you when using a 1.0.x install are available for you. If you're still at 1.0 there is no way to see which mods are available for 1.0.x through GUI I think. You need to list mods which incorrectly appear/don't appear for us to be able to fix it.

I'm not sure whether to ask here or in the Universal Storage thread but is there any chance of a USI-LS US wedge for N.O.M.S? Can't open a github issue until I know where to post it

I need examples of mods to be able to answer why you see them. You'll need to talk to someone more privy to the inner workings of CKAN-core to get a perfect answer to your question about config.xml but my assumption would be that yes, it blows stuff away. I base my answer on https://github.com/KSP-CKAN/CKAN/issues/15

Open a github issue

When you update a mod CKAN basically uninstalls your current version and then installs the new one. So yes it will download the .zip of the new version. If you are however uninstalling a mod and then later re-install the same version it will use the cached .zip you've downloaded earlier.

Yeah 1.0.1 is something of a problem acctually. Assessing now EDIT: For mod authors who maintain their own .netkan or .ckan files. ksp_version 1.0 is good, 1.0.0 makes things not show up. Everything in NetKAN should be fixed, we've started looking at CKAN-meta.

USI has not been removed as compatible, it is still marked for 1.0 in our metadata. FirespitterCore (the .dll that many mods depend on, among them USI mods) have however been marked down to 0.90 based on above discussion and testing. USI mods will return once we have a working solution to supplying the Firespitter.dll file through CKAN.

CKAN currently lacks a good way of solving this without a lot of trickery so I would like to humbly suggest https://github.com/KSP-CKAN/CKAN-support/issues/125#issuecomment-98156962

Open a github issue.

Did you bring the tourist with you?

FirespitterCore is now removed from CKAN 1.0 compatibility listing. We're actively searching for an alternate solution. ATM should now be fixed and properly show up as version 5.0. I'd like to point out that even though x64 was discontinued for Windows there very much exists a 64bit client for linux users.

In GUI you can choose to display incompatible mods. However mods that are compatible but lack dependencies are not in either list right now. Sounds like a curse problem indeed.

Yes I know the latest version is there but CKAN cannot handle a direct download a .dll but requires a .zip hence my asking for such a file. Our currently indexed version isn't working on 1.0. Is the latest compile of the .dll available in the 6.3.5 version of the firespitter package? If so I can index it from there. EDIT: More and more people are telling me it does indeed work (for most (all?) intents and purposes) but it gives an error on startup which part of the userbase understands and ignores while other parts report it as broken beyond belief. Either way I can't wait for a new release

CKAN checks your install to see which version you're running. Then it checks our metadata in the mod repository which mods to offer you based on your version. Everything you see after a refresh is marked in our metadata as compatible with your version of KSP.

Yes it is near impossible to keep up right now. There's a few of us doing what we can to index and work through the data but there's only so much we can do. I recommend you send in 1 as a request on github, I'm pretty sure there's at least one like it somewhere already. As for 2 uninstalling the mod will indeed delete it from GameData but the download will still be cached so there's no additional downloading as long as you're re-installing the same version.

Yes... some mods are removed when proven to be totally screwed over. KW was such a case seeing as their thread is currently users hacking together MM patches to be able to use the parts. Based on this discussion FirespitterCore might be such a case aswell and I'm monitoring toolbar and some more partpacks aswell. But every time we remove something, esspecially something like FirespitterCore, users tend to rage a lot more than they do when the mod just doesn't work. In a perfect world we get access to a redistributable .zip of a recompiled FirespitterCore asap and this will all be resolved.

Are there no more 32 and 64bit versions and different operating systems? It's just basic and aggressive now?

FirespitterCore had an older version in our metadata repository that had ksp_version "any" in it. This was found out to late to pull it, looking around on forums it seemed that firespitter.dll was working and as such the newer version we had indexed was pushed to 1.0 aswell. I've asked in the Firespitter thread for a package we can use in CKAN for 1.0 so I'm hoping we'll get a new version soon. Until then I can't really do anything since removing an already installed mod in CKAN has negative effects on the users. Having an incorrect version available ofcourse also have negative effects so we're kind of stuck between a rock and hard place until we have a new firespitter.dll to index I'm afraid.

http://forum.kerbalspaceprogram.com/threads/65754-HotRockets%21-Particle-FX-Replacement-Tutorial?p=1881054&viewfull=1#post1881054