politas

Setting it to strict versioning is awaiting the next CKAN version. I'm hoping that's not far off. EDIT: Ah, the older versions need to be fixed to prevent them showing as compatible. Changes submitted. EDIT2: ModuleRCSFX is no longer appearing for KSP 1.0.5.

NathanKell has announced that ModuleRCSFX has been rolled into stock as of 1.0.5, and should not be installed, and that is set as a dependency for this mod. I think that may mean that the RCS features might not work if you don't install ModuleRCSFX (I gather there are slight differences in the naming), and other things might have problems if you do install it. Looks like this mod may therefore need an update to work properly with 1.0.5. EDIT: Looks like the K-21-RCS Jet Thruster (rcsJet) part is the only one affected by this, but I think the ModuleRCSFX reference is actually completely commented out, so maybe ModuleRCSFX should not be a dependency at all.

Give it time. MechJeb for 1.0.5 was only released two days ago, and CKAN now lists it. KER still hasn't been updated, and is at least partially broken in 1.0.5 (No dV stats for jet engines, for instance).

[quote name='CrazedGunman502']Yep, sure. "Unhanded exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Transaction timeout." This happens every time the mods are finished being downloaded. CKAN freezes and I am a sad person. Everything is ready to be extracted from the downloads folder but CKAN is super stubborn and doesn't want to do it. It's either manually install all of those .zip folders (which is going to take a really long time) or try again until it works (unlikely).[/QUOTE] A few questions to try to pin down the problem: Is this your first time using CKAN? If not, when were you last able to successfully install mods using it? What version of .net/Mono do you have installed? What operating system are you using?

[quote name='Yarbrough08']I do not have a fork on Github, and I am not that familiar with using it. I do know how to send pull requests, but that's the limit of my knowledge - I've never had a reason to learn more lol.[/quote]If you want to keep maintaining your mod's metadata (and CKAN is very, very happy for mod authors to do so!), it's probably worth learning the fairly minimal amount needed to use the github web site to modify files and generate pull requests from there. [quote name='Yarbrough08']I can do this (PasteAll): [URL="http://www.pasteall.org/62395"]Core Mod[/URL] [URL="http://www.pasteall.org/62396"]4096[/URL] [URL="http://www.pasteall.org/62397"]2048[/URL] [URL="http://www.pasteall.org/62398"]1024[/URL] [URL="http://www.pasteall.org/62399"]Low[/URL][/QUOTE]You'll need to bump the spec_version to "v1.4" in order to use "find", but otherwise, that looks like it ought to work to me. Obviously, if you're doing install from .ckan, you'll need to completely uninstall (parts+texture) between trying each texture file.

[quote name='Yarbrough08']I am trying to get my recently updated 2 kerbal command pod onto CKAN, and am curious about something before I send a pull request with the *.netkan 's. I've generated the ckan data and tried installing it through CKAN; however, I am getting a "too many mods provide..." error. I am using a system similar to RSS and RFs to install textures (multiple choice textures). I have noticed that others have had an issue with this in the past, and am wondering a couple things: -if the issue was resolved and I am doing something wrong on my end -will installing it in this fashion (multiple "provides") even work by merely 'opening' the ckan file -is it just a bug and that when I send in the data everything will work properly through the GUI? I noticed that RSS and RFs is still using this method to select multiple dependent choices, so I am unsure what to do about it. Any advice/answers would be greatly appreciated..[/QUOTE]Can you post a link to your Github fork with the .netkan files you've created? Then we can have a look at them.

[quote name='steve_v']I get his, I really do. But as I understand it, CKAN exists to make life easier - in this scenario it's just getting in my way, and it happens with [I]every[/I] new KSP version.[/quote] This is really only an issue for a small group of users, those that install a fresh copy of KSP with every version who also use CKAN. Users running Steam get their KSP updated in-place, and CKAN doesn't uninstall their potentially-broken mods. Of the two situations, I think that is a bigger potential problem for CKAN developers to work on than yours. [quote name='steve_v']If I want to do a Bad Thing, I'll install the mod manually anyway - is it not better to have it handled by ckan, or are we operating under the assumption that Users Are Stupid and making life difficult on purpose? (something that I find [I]extremely[/I] aggravating). IMO it'd be far better to just provide a --force option with a Big Fat Warning, the number of times this has come up speaks for itself.[/quote]Well, I would counter that the best thing for clever users like you is for this sequence to happen: * Install desired mods manually * check that they work * Report functionality of mods to the mod author's contact option (forum thread, home page, whatever) * Report functionality of mod to this thread (or by raising an issue on the CKAN Github) Then, a CKAN contributor (which there is very little preventing you from becoming) does: * Edit the .netkan file to change the KSP Max Version field. Then you can manually remove the mod and re-add it through CKAN, with the benefit for all other CKAN users that they can now easily use CKAN to do it. You doing a --force option to avoid the metadata update is the selfish alternative. Now, I don't know whether a decision has been made to not include a --force option in order to encourage this cooperative workflow, or whether it is just something that they haven't gotten around to. Either way, you have two options. You can continue to complain about things not working the way you want them to, or you can be helpful and make CKAN work better for all the users, either by testing, metadata editing, or even contributing code to add a --force option if you really, really want that option. If you had simply started by providing a list of the mods that you know work and need to be updated, I could have submitted changes by now. Instead, I'm spending my limited time responding to your complaints.

[quote name='steve_v']So, what's the ETA on sorting out (or just getting rid of) the mime handler installation? it's broken at [URL="https://github.com/KSP-CKAN/CKAN/issues/1510"]least[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1509"]three[/URL] [URL="https://github.com/KSP-CKAN/CKAN/issues/1498"]ways[/URL], and much as I'd love to use CKAN for 1.0.5, up with an application that corrupts my desktop configuration every launch I will not put. Can't we just kill this already? It's not hard to add a file association through the provided desktop tools, for those few who will actually use this. Aside, I'm not overly excited about ckan tampering with files it does not own (and without prompting) in general. Please leave my desktop alone so that I can use this again.[/quote]The reality of the situation is that there is a limited amount of time the small group of CKAN developers have to put in to CKAN. When a new KSP version comes out, a lot of work is needed on metadata, so work on the client slows. With KSP 1.1 expected in December, I'd be surprised if a new version of CKAN is released this year. I would suggest writing a wrapper script for CKAN that copies CKAN Handler.desktop and mimeapps.list before running CKAN, then restores the files from the copies after CKAN closes as a workaround that is much better than the ones I suggested previously. [quote name='steve_v']As a workaround I'd like to use the command-line client, how do I change the filter from 'compatible' to 'all' on the CLI? CKAN will not show mods that haven't been updated for 1.0.5, or allow one to install them without guessing the exact version, despite said mods being known to work... and this issue is getting rather old.[/QUOTE]I'm not sure that you can. From CKAN's perspective, installing incompatible mods is a Bad Thing. If there are mods that are known to be compatible but CKAN is not reporting them as such, why not post a list of such mods with links to evidence for each (just someone saying "I've tested it" would generally be enough) and do something helpful?

[quote name='Zeggpold']I'd like to copy my mod list over from my old 1.0.4 installation to the new 1.05 version. I can export the list from 1.0.4 as a ckan and try to import it using the gui in the 1.0.5 directory, but as soon as ckan sees an incompatible mod, it just stops, reporting just that mod. Is there a way to either (1) get it to ignore the incompatible ones, or (2) provide a complete list of incompatible mods (not just the first)? I tried removing the incompatible ones one by one but gave up after about five. I also tried the readme hack to claim the version was 1.0.4, but that just gives me different mods listed as incompatible, so it doesn't help. Also, in at least one case (Astronomer's Pack), I get a message that it's incompatible, but it's available to check in the installation list, which seems odd.[/QUOTE] Open your exported .ckan file in a text editor and change "depends" to "recommends", and you should be able to get just the compatible mods when you install from it.

[FONT=arial][SIZE=2][quote name='Workable Goblin'] I believe I am running the latest version of mono: [code]Mono JIT compiler version 3.12.1 (tarball Fri Nov 13 12:40:55 CST 2015) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: normal SIGSEGV: normal Notification: kqueue Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen[/code] I do use MacPorts, not Homebrew, if that's important.[/QUOTE] No, you really aren't: [code]Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Nov 12 09:52:44 UTC 2015)Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen [/code] Mono V3 does not support elements used by CKAN; it is not a .net 4.5 framework. You'll need to go to mono-project.com and get the actual latest version.[/SIZE][/FONT]

[quote name='Auriga_Nexus']Sigh.. it's a bloody 404 error how much more exact do I have to be?! Though I guess more details can't hurt. Basically the metadata package points to version 2.7b as the most current, but that download is no longer available on KerbalStuff. On top of that I have been using KSP v1.0.4 still - I'm waiting for the official 1.0.5 release of MechJeb before I make the switch. I actually looked at the metadata entries and they show all the way up to version 2.10, but 2.8 and up are listed for version 1.0.5. I think this has to do with the version-compatibility rules for CKAN - but it's weird because the mod still shows up as compatible on my mod list. It just refuses to recognize any version of the mod that doesn't match the current KSP version, so it won't update to the latest version available - and the current version is no longer listed on KerbalStuff. Hence, HTML error 404, location not found.[/QUOTE] Well, you said in your original post that the link in the 404 error message was "correct". So clearly, you had more information that could have helped. Generally, when reporting a problem with a volunteer-supported program to web forum where everyone trying to help is doing it on an entirely voluntary basis, it helps to give more information than is necessary, rather than less. It looks like the mod author has pulled the 2.07b version of the mod and changed 2.0.8 to be KSP 1.0.5 only. CKAN has some old data. Not sure how to clean that up. It's difficult when mod authors change things that way. I've raised an [URL="https://github.com/KSP-CKAN/CKAN-meta/issues/836"]issue[/URL], so it should get sorted out as best we can. Everything should be fine on KSP 1.0.5 when you do upgrade. [COLOR="silver"][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='BlackHat']Hmm, Checked CKAN today and saw before Refresh I had 399 Compatible mods. After Refresh I had 436 Compatable mods. (27 mods updated and 9 new ones in repository) So once again I am scrolling up and down the list of compatible mods trying to "figure out"/"identify" which mods have been updated to be compatible with 1.0.5. I would like to strongly suggest one of the following: 1. Include a new column showing the date a mod had its metadata updated in CKAN. 2. Add a new filter showing Updated mods since last refresh. (Similar to the New in Repository filter) Trying to find the 27 new mods added to the compatable list in a list of 436 mods is getting tedious and annoying.[/QUOTE] It has been [URL="https://github.com/KSP-CKAN/CKAN/issues/1519"]raised as an enhancement request here[/URL], since you last asked. Might not get implemented in time to be useful for 1.0.5 at all, but hopefully for 1.1 (Where it's going to be very important.)

[quote name='TheMustacheGuy']Hey there. I have CKAN and I can't find ckan.exe. Where do I find it?:wink:[/QUOTE] Wherever you extracted it. Try running this command from a terminal window. [code]find ~ -iname "ckan.exe" [/code] [COLOR=silver][SIZE=1]- - - Updated - - -[/SIZE][/COLOR] [quote name='Auriga_Nexus']When attempting to install Kerbal Planetary Base systems via CKAN I get a 404 error. The KerbalStuff page has it up however, and the link in the 404 error appears to be correct. Also the mod version listed is not the most current, but there is no option to upgrade.[/QUOTE] Please include the exact error text you get.

[quote name='neo2001']You're right! The "Compatible" filter was selected... which I didn't realize... Is this the default setting? If so, IMHO this should default to "All". Or there needs to be a better visual feedback, that a filter is currently applied. Like the filter button in some kind of "active" or "pressed" state or a bar at the top showing the current scope.[/QUOTE] "Compatible" is generally the most useful filter. It shows you the mods that have been kept updated and are known to work for the version of the KSP install you are modifying. These periods of version changeover are the exception, not the rule.

[quote name='neo2001']I had PlanetShine installed, but since the latests KSP versions it gives me a warning that it's not compatible with >1.0.2 anymore - so I decided to remove it. I started CKAN, but couldn't find it. [/QUOTE] What Filter do you have selected?

It could do with having KSP_VERSION_MAX in PlanetShine.version bumped up so that KSPAVC stops complaining every time you load the game, though. CKAN can't help with that.

[quote name='Raptor831']I need to change the file structure in the next RFStockalike release. Is there a way to "sync" both a release on my end and an update of the CKAN registry?[/QUOTE] Depending on just what you're changing, I believe the netkan should be able to be modified to handle both file structures, but raise an [URL="https://github.com/KSP-CKAN/NetKAN/issues"]issue on GitHub[/URL] with the details of the change and the people who know more about it can help.

[quote name='the grue']NavballDockingIndicator not currently installed.[/QUOTE] Are you sure? Check your GameData folder. But there is something weird going on with NavballDockingIndicator. It's not showing up as either compatible or incompatible for KSP 1.0.4 or 1.0.5

Nice list! [B]EVAFuel[/B] and [B]Unmanned Contracts[/B] each have the description of the mod above them, though.

[quote name='TaintedLion']I cannot get this to work, no matter what I do. I am on Ubuntu 14.04, and have followed all the instructions given, but I cannot open it.[/QUOTE] Please report the results of the following commands. We cannot help you with no idea what problem you are having: [code] mono ckan.exe version mono -V [/code](Make sure you are in the directory where you installed CKAN)

You are welcome to create a metamod pack similar to Realism Overhaul and submit it to the NetKan repository. Try to make it a themed set of mods that make sense, rather than just all the mods you happen to like, and leave out the kind of helper apps that are largely a matter of personal preference, like Landing Height Display, Chatterer, Control Lock, Critical Temperature Gauge, Editor Extensions, RCS Build Aid and such.

Ah, ok, that's what you meant by running them in HEAD. Wouldn't it be easier to have a development KSP install and a gameplay KSP install, and only use CKAN for the gameplay install? I would think you're courting problems in your savegames with advancing and reverting versions. CKAN really isn't aimed at developer use, or for bleeding-edge users. That would seem to be the kind of edge case that should be worked on after the basics of dealing with ordinary users with little computing knowledge is really rock-solid, which it really isn't, yet. You can manually deselect and reselect mods, which will then put them into "selected by user" mode rather than "installed as a dependency" when you update. It'll still remove RO if you remove RealFuels, but all the other mods RO depends on won't get removed.

You could create a dummy user and group that the CKAN executable is setuid/setgid for, and then chown the CKAN directory to that group? I think that'd work.EDIT: Sorry, I meant chown the KSP directory to the group.

Sorry, I'd have answered, but I really don't know why the decision was made, or where the discussion is. I'm also not entirely sure what you meant about what you were doing with your mods. It may be that the philosophy behind CKAN just isn't suited to what you want to do.- - - Updated - - - That's odd. The timestamps on my files match with the last new CKAN version I installed. I've made a new ckan.desktop file, so it won't be overwritten. You could chown ckan-handler.desktop to another userid to prevent ckan over-writing it, I suppose. I think the upshot of that issue is that it will be fixed. It might be more correct to say that both our desktop environments are ignoring that part of the freedesktop spec, but there's a point where you have to stop denying reality, and accept that specs aren't always perfect.

I'm pretty sure it only rewrites those on every CKAN update, not every startup.

Ok, so it's nothing to do with anything in your KSP directory. What do you get from mono --version CliftonM, can you post the results of this, too, and the exact error message you get when trying to run CKAN?