Recommended Posts

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)

Edited June 30, 2015 by Murdabennemoved discussion of CKAN reasoning to its own post

Share this post

Link to post

Share on other sites

I think forced == YOYO - as we know from past github issues, one reason the CKAN devs have (rightly, in my view) been reluctant to add a non-expert way to force installation is the inevitable tide of spurious bug reports.

I'd go so far as to suggest any forced/YOYO installation should leave a very prominent marker in output.log.

************** JIT Debugging **************To enable just-in-time (JIT) debugging, the .config file for thisapplication or computer (machine.config) must have thejitDebugging value set in the system.windows.forms section.The application must also be compiled with debuggingenabled.

When JIT debugging is enabled, any unhandled exceptionwill be sent to the JIT debugger registered on the computerrather than be handled by this dialog box.

See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.

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.

Share this post

Link to post

Share on other sites

You have just rejected, in very strong terms, an offer by someone to sort out the CKAN metadata for FAR - someone who is doing this for many mods and seems to have their head screwed on.

Perhaps that makes it harder to get things right?

...no I haven't. No one has asked about FAR metadata at all. I'm not sure how I could reject something that hasn't been asked. Go, check the FAR thread; there's nothing there about metadata.

You know, something I've noticed when dealing with CKAN: every person involved does their best to try and say, "no, we're not the ones screwing up, it must be your fault modder." Even to the point of making stuff up.

But let's suppose such a thing were to happen. FAR is not on CKAN by my choice. It was not added by me, nor have I ever had any input on the metadata. CKAN has always indexed my mods without ever asking for permission; I don't see why my permission is needed now, because it certainly wasn't needed before.

Share this post

Link to post

Share on other sites

...no I haven't. No one has asked about FAR metadata at all. I'm not sure how I could reject something that hasn't been asked. Go, check the FAR thread; there's nothing there about metadata..

My mistake; it was in the KJR thread. (So, not "making stuff up", but honest confusion).

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.

Reply:

I dunno why you're asking me, I have nothing to do with CKAN besides yelling at them about the problems they cause for me. Go take any of their problems to their place and please don't bring them here again.

Question stands; might this sort of response be in any way connected to the metadata not always being right for your mods?

Edited June 30, 2015 by damerell

Share this post

Link to post

Share on other sites

I have no idea how acknowledging that it's a CKAN problem, by whoever works with CKAN has anything to do with causing CKAN to screw up its metadata. It's not as if I'm the one that caused CKAN to index the wrong version of a dependency that only had one public version (how, I have no idea).

If he wants to update the metadata, well, CKAN policy and customs tell him he can do whatever he pleases. He never had to ask me, because CKAN established a long time ago that my permission doesn't matter. Why he wants it, I don't know; the only permission that I will give to CKAN is that they have the permission to de-index all my mods whenever they please; everything else is based on whatever other policies they have, and I won't pretend I have any say there.

Share this post

Link to post

Share on other sites

It's end of financial year here in Australia, which not only comes with an absolute boatload of legal reporting and paperwork for me, but has also had me interstate on work. I'm not likely to be back on the forums in any meaningful way for another couple of days until things quieten down. However, I am pleased to announce:

Share this post

Link to post

Share on other sites

If he wants to update the metadata, well, CKAN policy and customs tell him he can do whatever he pleases.

But Murdabenne's own desire to be polite led them to ask, politely; they're not part of some CKAN hive mind.

"Complains the metadata has been got wrong" and "bites the head off people endeavouring to get it right" don't seem entirely consistent positions to me. You could (for example) have replied "Go ahead, but it's not my problem and I'm not going to help you", which leaves you off the hook but would seem to increase the possibility it is got right, reducing the flood of CKAN-related enquiries (of which I could find one in the five pages of the FAR thread consumed by one confused-about-aerodynamics person).

Share this post

Link to post

Share on other sites

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion. There was a good group of issues from way back of CKAN not installing MFI, then installing a version of MFI that caused problems with Deadly Reentry, which probably also involved issues being reported to that thread. Also, let me remind you: CKAN is a machine. It does the exact same thing every time. This affected everyone that used CKAN and FAR, not just the ones that reported it.

Share this post

Link to post

Share on other sites

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

They asked permission; you didn't grant it. Now I know the hive-mind's position is that permission isn't needed, but that doesn't mean that an individual can't ask.

Seriously, as replies go, what exactly would be wrong with "Yes, but not my problem / don't expect any help / don't ask me how to do it" etc?

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion.

I'm just saying, I think kookery is a far vaster source of noise. The "angle of attack is a conspiracy" chap went on quite a while too, as I recall.

(I've skipped some stuff we've done on github).

Share this post

Link to post

Share on other sites

They asked permission; you didn't grant it. Now I know the hive-mind's position is that permission isn't needed, but that doesn't mean that an individual can't ask. Seriously, as replies go, what exactly would be wrong with "Yes, but not my problem / don't expect any help / don't ask me how to do it" etc?

.

In this case it is a dead end because there is two overlapping conversations here. The point is if you do fix the metadata for FAR. You can cause more harm that good. Here what is missing...

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)

In this case we get more choice of how metadata is used. However with some mods like FAR. The option must be YOYO - You're On Your Own. Given the complex nature of the mod. There is overwhelming evidence that CKAN does not update FAR correctly. You can use CKAN and FAR but must accept the responsibility that it might cause a glitch in FAR.

I think forced == YOYO - as we know from past github issues, one reason the CKAN devs have (rightly, in my view) been reluctant to add a non-expert way to force installation is the inevitable tide of spurious bug reports.

I'd go so far as to suggest any forced/YOYO installation should leave a very prominent marker in output.log.

Yes indeed a very prominent marker. The same rule cuts both ways here. If we force a mod to work. Including forcing CKAN to work. Then we do so at our own risk and should not go crying to the mod creators.

Share this post

Link to post

Share on other sites

I came across a compatibility issue today with real solar system and custom asteroids where CKAN said they were not compatible. While I was looking into this I seen there is a patch in RSS folders. Is there a way to let CKAN know there is a patch and have it apply the patch when/if this applys?

Share this post

Link to post

Share on other sites

If I may make a suggestion for CKAN, would it be possible to add either the author's publish date for the current version of a mod or the most recent date of the upload to the repository to the details in the mod list?

Share this post

Link to post

Share on other sites

In this case we get more choice of how metadata is used. However with some mods like FAR. The option must be YOYO - You're On Your Own. Given the complex nature of the mod. There is overwhelming evidence that CKAN does not update FAR correctly.

Oh, come on. It has been wrong in the past, which is regrettable, but while FAR does complex things, it does not have a complex set of dependencies.

Share this post

Link to post

Share on other sites

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.

Yes at the time (1.8.4? or 1.8.3?) it was repeatable. If I chose continue, the "Go to Changes" tab was greyed out, if I chose cancel CKAN crashed.

Now with 1.10, if I select CTT, the line turns red and I see a tool tip saying it conflicts with "OpenTree" mod and that CTT requested the not comparable status, (So I assume that was the actually cause before for the error message. as I have had OpenTree installed then too. {which is strange as I thought they WERE compatable, must be something recient)

Share this post

Link to post

Share on other sites

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

Well, as someone relatively new to KSP and this community, seeing this unfold leads me to what one would think would be the most obvious solution...

Mod author does not want to be involved with CKAN, but is regularly burdened by CKAN-related inquiries from people who are not aware of the compatibility issues.

Mod author does not actually care if CKAN lists his mod if it were capable of installing the thing correctly.

Mod author prefers that people have his mod correctly installed and fully functional.

Mod author is irritated by the policies/conflict surrounding the CKAN people.

The most obvious solution from my perspective would be for the mod author to work with the CKAN people so that it installs the mod correctly, thus eliminating all CKAN-related inquiries from people having problems because they installed the mod with CKAN. As far as what "work with" looks like, from what I can tell, all it entails is simply saying "go for it". Nevermind that things have been done without permission already anyway and the request for permission seems to be an inconsistent policy. Who cares? If this whole thing can be resolved by saying "go for it" then why not do exactly that?

Share this post

Link to post

Share on other sites

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion. There was a good group of issues from way back of CKAN not installing MFI, then installing a version of MFI that caused problems with Deadly Reentry, which probably also involved issues being reported to that thread. Also, let me remind you: CKAN is a machine. It does the exact same thing every time. This affected everyone that used CKAN and FAR, not just the ones that reported it.

To be fair the MFI problem was on our/my side. MFI code was updated without changing the version in the source and my server built a zip with the same name+version.

1

Share this post

Link to post

Share on other sites

Yes indeed. It is actually miss direction. No offense intended. I just used a bit of cognitive dissonance to break things up a bit. Stops people getting stuck with the original metadata excuse too much. The point was to justify that mods sometimes can't use CKAN with without a user input choice. This can be a temporary problem which needs a override choice. A choice which we can't yet make.

To be fair the MFI problem was on our/my side. MFI code was updated without changing the version in the source and my server built a zip with the same name+version.

Hey so it goes. We all learned something. Any mod creation comes through the hard work of very generous people. The fact we get any thing at all is amazing. You guys are all great at what you do.

The whole point of my original post was in response to people still arguing that metadata is everything. It might be 99% of the time. However manual user driven CKAN installs are still required. For various reasons because mistakes can happen. Squad can also easily bring the whole house of cards down with KSP hot fixes. The mod CKAN comparability decision should be a suggestion not an absolute unbreakable law. It should let you install incompatible mods at your own risk. As suggested there is also some really good reasons why this is a bad decision. Logs need to record when it happens to stop people calling foul when the game breaks.

Share this post

Link to post

Share on other sites

The point was to justify that mods sometimes can't use CKAN with without a user input choice. This can be a temporary problem which needs a override choice. A choice which we can't yet make.

You can install a specific version of a mod via the CLI.

The whole point of my original post was in response to people still arguing that metadata is everything.

Has anyone? As far as I can tell, everyone would like it to be correct, much as there's been an argument about some other problems. "Metadata should be correct" seems to be an utterly uncontroversial statement.

The mod CKAN comparability decision should be a suggestion not an absolute unbreakable law. It should let you install incompatible mods at your own risk.

I think it would be doing modders an enormous disservice for CKAN to provide an easy way to install mods believed to be incompatible, completely at odds with the way that it can be an asset for modders as well as users if it consistently provides correct mod installs. Squad put out 1.0.5? You're no worse off than you were before CKAN existed; but now you have the option of testing mods and getting their metadata fixed. That's exactly what I'm going to do when I finish my current expedition in 1.0.2 - if Murdabenne hasn't done the lot.