Murdabenne

I wonder if someone might want to do a meta-package for all these, incorporating the configs and fixes posted here (including the compatibility fix above)? What permissions would be required? This is a more to my liking than TACLS or one of the other more intricate multi-resource systems. Just something simple, easy to manage, but still imposes consequences on long missions, or abandoning Kerbals in weird orbits or getting them stuck in difficult places (I'm looking at you Eve). If I knew more c# and graphics, Id attempt it myself. Maybe I should?

Is this affected at all by the thermal changes in 1.0.3/1.0.4?

Cool. Basically if it was good under 1.0.3, 1.0.4 should not have affected it, unlike most Squad changes. If that's the case, no need to rebuild, just let me know to update the metadata on CKAN and this is ready to go.

Im asking you because its your addon, and some authors would rather not have anyone do anything that might affect their app, even peripherally, such as an indexer like CKAN. Along those lines, did you know that CKAN can and will stop indexing your stuff if that is what you wish? Its not a "CKAN problem" Im bringing in here - is your apparent anger management issue with CKAN I am trying to help solve, because I like both of those things. I was merely offering, politely I might note, to help to try to keep those CKAN questions away by helping update the metadata. I am providing the courtesy of asking you first, rather than just going ahead and doing things - Ive seen what users that just jump in can do, and just how bad they can screw things up (Sarbian and Mechjeb and a user who reposted his stuff without asking). But given your response, your "yelling" (since when does that accomplish anything online other than appearing as a tantrum or trolling?) I'll take that as a "no" to all of the above. Good luck, have fun yelling. One final suggestion - when someone comes in and politely offers help, dont be a jerk, it reflects pretty badly on you.

just an FYI: 64bit win 8.1 is OK, but win64bit client will get your head bitten off in here, so be clear to the authors that you're using the regular 32bit KSP client. the win64 KSP client is notorious for strange behavior, and is (perhaps deservedly) not supported by squad nor by most addon developers. Just trying to save you time and aggravation.

LOL give them the answer Blizzard uses -- Soonâ„¢

I just tried installing CTT on my 1.0.4 install, and it didn't error, but I do have a ton of addons installed, do you still get this error after exiting, refreshing and retrying? I also tried GPOSpeedPump (which is GoodSpeed continues, installs as GoodSpeed directory) since its an addon I always have loaded as soon as its available, and its working too. Strange they should show an error - usually I am an error magnet for addons, if they break I break em. - - - Updated - - - For YOYO, I'd think not just a marker, but change the menu so that's the only mode you can use from then on, with appropriate warnings, popups, ominous sounds, and pictures of Walter White to indicate that you are now breaking (bad) the app.

My analysis: Its taking all addons and addon managers and version trackers a while to deal with all the fallout from having apps that are still good despite a version change to KSP. Its not just CKAN, but CKAN, KSP-AVC and KerbalStuff are all having to come up with ways to allow for an app that's made for 1.0 (or 1.0.2) and not updated since then still being considered compatible with 1.0.2, 1.0.3 and 1.0.4. but also still filtering out ones that are not. The old assumptions of new releases breaking addons is no longer valid now that we players are seeing patch/hotifx releases like 1.0.4. So those authors are having to come up with ways to allow for an addon that's made for 1.0 (or 1.0.2) and not updated since then still being compatible with 1.0.2, 1.0.3 and 1.0.4. For example, something like Hyperedit isnt really touched at all by any of those updates, so why should the author of that addon be forced to recompile/rebuild just to mark it as compatible? Answer: s/he should not! The whole thing of these tools is to help users manage their addons, and do so in a way that prevents errors like an outdated or conflicting app, however they also add benefit to addon authors in that they can relieve some of the work that the rapid version changes throw at the authors. Typically, authors would rather be improving their addon instead of dealing with versioning issues and bugs caused by users installing when/where they shouldn't. CKAN has taken the approach to this problem of adding KSP min and max versions to their metadata, which is what they are doing at the moment, updating the metadata of hundreds of indexed addons. This allows an addon to be marked as installable and compatible for multiple versions in a range, which is very convenient in the event of a hotfix. For authors (or even someone they designate), after a hotfix or minor patch that doesnt affect ther addon, instead of rebuilding the whole thing and re-releasing it, all they (or a friend) needs to do is simply change the ksp_version_max in the netkan or ckan metadata, and you're done. CKAN can update the rest for its users. Hopefully addon developers will see and understand this isnt an attempt to take their apps away, but to help distribute them to an even wider userbase, and reduce the workload of doing updates whenever Squad drops a hotfix. Is this fixed yet? Does this still work with 1.0.x? Where is the update? Is this the stable version? Does this depend on adodn X, and is it and this updated? CKAN and a quick metadata update can prevent a lot of those. This is what my posts to most addon's forum threads have been about - Im offering to help update CKAN's metadata, so the addon authors dont have to fiddle with it. - - - Updated - - - Some End-users want more choices, so I have proposed (for discussion) having different modes of operation to allow the users the choice of how tight they want the checking: strict -- must be released for the exact version, must be marked as such by the author. Its how things work now, pretty much the safest way, and this would be the default mode of function. gras "generally recognized as safe" meaning although its compiled for 1.0, its OK to use on 1.0.2, 1.0.3, per the author (usually via a forum question or email) -- it looks like most falls into this category, (gras is also french for "fat" - as in a fat selection, lots of stuff). This saves addon authors time and effort when their users use CKAN to get updates. forced which means the user overrides the version safety for this app (and its dependencies). Do this when your favorite addon isnt current but you want to install it anyway. This is akin to a manual install. The only thing you gain from CKAN is that it will check dependencies, and let you know when an update is available. YOYO - You're On Your Own - doing this basically means you are unsupported and should not bother the authors of the addon or the authors of CKAN with errors you have created. Its like using Win64 mode - go for it, but dont go looking for support. The only thing CKAN does here is simply tell you what addons you have installed and give you pretty checkboxes to check and do an install,. or uncheck to uninstall. This would make more people satisfied, allowing power users more leeway, but keeping most users in the safe zone. (moved to its own post as a separate topic - a proposal for CKAN)

I like that mod too - the Corvus stuff is really well thought out and looks great. You'll find that Corvus and HGR Props are both updated for 1.0.4, per my last check of the CKAN client (I just installed them as a matter of fact). Installing Corvus will grab HGR Props along the way as a dependency.

Congrats!

updating CKAN to mark this as working with 1.0.4, please correct that if this is incorrect.

CKAN updated to mark this as compatible with 1.0.4 as well as .3

v014 is in CKAN - may take an hour or 2 to show up

All I did was change some metadata on CKAN, not a bug. All credit goes to the SCANsat mod author, DMagic

Im fixing that now. Edit: c hange submitted and accepted in CKAN.

So the answer is "mu"?

OK, got it. I'll go into wait and see mode. I just wish the versioning issues weren't so tangled. I think the CKAN guys are becoming more aware of the work they can potentially create for authors, and are trying to change that.

CKAN is pending my pull request, should be done shortly. edit: complete.

I've tested with 1.0.4 and it seems stable, and other users report it stable, so Im adding in an override on CKAN which marks this specific version (1.1.5) as compatible with KSP 1.0.2 thru 1.0.4. It will not affect past nor future versions and it only affects CKAN.

I've tested with 1.0.4 and it seems stable, and other users report it stable, so Im adding in an override on CKAN which marks this specific version (0.5.2) as compatible with KSP 1.0.2 thru 1.0.4. It will not affect past nor future versions and it only affects CKAN

You updating this anytime soon for 1.0.4? If so, then the update (and compatibility) will be done automatically. If its not affected (and I think it is not), then instead of you having to do a rebuild, I can just update CKAN for the app to use a range of ksp_version and set this iun CKAN as compatible with 1.0.2-1.0.4. It won't stop the warning message when KSP starts form the version checker, but it will make this available for CKAN users to install, once again.

I dont modify the version - the guys at CKAN came up with a specific metadata item (x_netkan_override) that says, basically "if this is version X.Y.Z then ignore the ksp_version from the version file, and mark it as compatible with KSP versions from A.B.C thru A.B.G, inclusive" It basically is a workaround for the bugfix releases so that authors dont have to do a rebuild or change their ksp_version info - it can be done in metadata instead, which in theory should save you from having extra work to keep CKAN updated. Thats the purpose behind the new metadata ksp_version_min and ksp_version_max.

Because they are marked as being compile for a specific version, 1.0.2 in most cases. And there is nothing wrong with running them on .3 and .4, but to get them compatible for this would require the author to rebuild the thing - and likely mark them as incompatible for earlier versions that some people are still using. This is bad for the mod authors and plain nuts for people that are tracking addons like CKAN and KerbalStuff Blame Squad for their abuse of the versioning system - right now KerbalStuff only has a single version as viable. CKAN was the same way but now has the ability to specify a minimum and maximum KSP version, which is what I am doing in the metadata - removing the old KSP version metadata and adding in the new min/max data. Nice thing is if the author wants we can set the max to a future version like 1.0.99, which means it will stay valid in CKAN for quite a while. CKAN is trying to take this bit of busy-work off the authors to-do lists, so they can concentrate on making great mods, instead of chasing KSP versions and figuring out how to distribute their app sensibly (and dealing with the questions about that). edit: and yes I am trying to get those specific things (Bahamuto dynamics, KIS, KAS, Extrap[lanetary Launchpads, etc) flipped over to using min-max, so they show up. But unlike some fans, I tend to ask first (like I did here). Well meaning fans that do not check first and just slam the things in there can cause a lot of mess for the author - for instance Sarbian is having to deal with someone that put MJ developer up on KerbalSpace without asking him - and worse they put it up there as the stable version which causes the old version to be replaced! So now there are some screwed up installs because of that. And that's causing Sarbian to put time into correcting that mess instead of getting MechJeb updated. This is what I am trying to avoid.

ferram, may I, with your permission, update the metadata in CKAN to use the new ranged formatting? This would set a ksp_version_min and _max, which would allow your mod's users who use CKAN to see it as "compatible" there, and install it easily rather than bothering you here in the forums. I can set the min to 1.0.2, and the max to 1.0.4 - making it available to people running any of those versions. I can also set the max to 1.0.99 meaning in all likelihood this mod is OK to use until 1.1 (the Unity 5 update). I will not do anything unless you say its OK, but after that it should cut down on questions here.

BTW, CKAN can pull your zip file directly from github if you want them to track your latest release automatically. This means CKAN (and people bugging you for it to show up there) can automagically grab the latest release, cutting back on your workload a bit. Especially when Squad throws in a hotfix patch like 1.0.4, letting you tag and release to make it compatible. Anyway, I put this in as compatible for the range from 1.0.2 thru 1.0.4 inclusive based on your comments here - let me know if you want this automated to grab the zip off github instead of your website. It would still direct people here for the forum thread, and to github for bugs.