pjf

The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]

Recommended Posts

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)

Edited by Murdabenne
moved 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.

Share this post


Link to post
Share on other sites
Strange error....

I was adding mods to my KSP 1.0.4 game, and I selected Community Tech Tree. (All I did was click the button TELLING CKAN that I wanted to add this mod.)

It immediately game me an error message.

It looks to my untrained eye like it has a hidden dependency on GoodSpeed mod. (But I thought CTT had no dependencies except for ModManager)




************** Exception Text **************
CKAN.ModuleNotFoundKraken: Cannot install Goodspeed, module not available
at CKAN.CkanModule.FromIDandVersion(Registry registry, String mod, KSPVersion ksp_version)
at CKAN.RelationshipResolver.<RelationshipResolver>c__AnonStorey0.<>m__0(String name)
at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at CKAN.RelationshipResolver..ctor(IEnumerable`1 module_names, RelationshipResolverOptions options, Registry registry, KSPVersion kspversion)
at CKAN.MainModList.ComputeConflictsFromModList(Registry registry, IEnumerable`1 change_set, KSPVersion ksp_version)
at CKAN.Main.<UpdateChangeSetAndConflicts>c__async1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at CKAN.Main.<ModList_CellValueChanged>c__async0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__4(Object state)




************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
ckan
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Games/ksp%201.0.4/ckan.exe
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34238 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34251 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Microsoft.GeneratedCode
Assembly Version: 1.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Microsoft.CSharp
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.CSharp/v4.0_4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll
----------------------------------------
System.Numerics
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll
----------------------------------------
System.Dynamic
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Dynamic/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Dynamic.dll
----------------------------------------
Anonymously Hosted DynamicMethods Assembly
Assembly Version: 0.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dll
----------------------------------------
System.Transactions
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll
----------------------------------------
System.Runtime.Serialization
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
----------------------------------------
System.Xml.Linq
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml.Linq/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll
----------------------------------------
System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.EnterpriseServices
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll
----------------------------------------
Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------


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


For example:


<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>


When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather 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.

Edited by Murdabenne

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 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

(I'll just point out that actually, you do. My offer is still valid, you know)

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:

CKAN v1.10.0 aka "Rainbow Nebula" released

User visible changes since v1.8.4:

  • [GUI/Bugfix] The GUI no longer says "about to remove" when there's nothing to remove (martinnj, #1203)
  • [GUI/Bugfix] The client is more stable after cancelling a download (Postremus, #1185)
  • [GUI/Bugfix] The auto-updater will try harder to set the execute bit when updating on Linux/Mac (Postremus, #1200)
  • [GUI/Bugfix] The GUI is less likely to crash with an InconsistentKraken when related modules exist, but do not satisfy required version checks (RichardLake, #1219)
  • [GUI/Feature] Double-clicking a row toggles mod selection (Postremus, #1217)
  • [GUI/UX] The previously misleading 'delete' KSP instance is now 'forget' a KSP instance (Postremus, #1196)
  • [GUI/UX] Even more dialog boxes have CKAN icons (Postremus, #1176)
  • [Cmdline/Bugfix] Min/Max relationships are more accurately shown in ckan.exe show (dbent, #1183)
  • [Cmdline/Feature] You can now ckan.exe remove --all to uninstall everything (martinnj, #1210)
  • [Core/Bugfix] Bad URL resources will no longer cause a module to be considered invalid (pjf, #1209)
  • [Core/Bugfix] Spurious messages are no longer produced for conditions that are actually okay (pjf, #1222)

Internal changes since v1.8.4:

  • Many classes now use interfaces rather than hard dependencies (RichardLake, #1167)
  • netkan.exe now strips x_netkan attributes during processing (dbent, #1193, #1201)
  • netkan.exe now supports version-specific overrides (pjf, #1197)
  • CKAN spec v1.10 now supports the find_regexp install directive (dbent, #1089)
  • The human spec now matches the machine spec and current usage when describing version numbers (pjf, #1178)

Public Service Announcement:

We're aware that fewer mods than expected are showing for KSP v1.0.4. We're working overtime to fix this, and you can read the full details (including possible workarounds) here.

Note:

  • Due to a change in the CKAN registry file format, you will not be able to move back to the 1.6.x releases after using this release.
  • Windows users must have .NET 4.5 installed.
  • Linux users, please apt-get install libcurl4-openssl-dev or yum install libcurl-devel if you have not already done so.
  • Mac/Linux/Mono users: please mozroots --import --ask-remove if you're a new user, to update mono's certificate store.

  • Like 1

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

hi,

after the last update (gb447380) i got an error by clicking fast on the Update tab. ^^

Edit: its on all sorting rows

System.ArgumentOutOfRangeException: Der Index lag außerhalb des Bereichs. Er darf nicht negativ und kleiner als die Auflistung sein.

Parametername: index

bei System.Collections.ArrayList.get_Item(Int32 index)

bei System.Windows.Forms.DataGridViewRowCollection.get_Item(Int32 index)

bei CKAN.Main.ModList_CellMouseDoubleClick(Object sender, DataGridViewCellMouseEventArgs e)

bei System.Windows.Forms.DataGridView.OnMouseDoubleClick(MouseEventArgs e)

bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

bei System.Windows.Forms.Control.WndProc(Message& m)

bei System.Windows.Forms.DataGridView.WndProc(Message& m)

bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Edited by whaaw

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?

  • Like 2

Share this post


Link to post
Share on other sites
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.
Unfortunately you not allowed to decide this. CKAN will decide for you. It will decide which version is best. You have no say in the matter. Move along.

Share this post


Link to post
Share on other sites
Unfortunately you not allowed to decide this. CKAN will decide for you. It will decide which version is best. You have no say in the matter. Move along.

That's a complete non-sequitur, in no way addressing the point that FAR does not have a complex set of dependencies. This:


Replaces: heimdal-servers (<< 0.6.3-12)
Provides: ftp, rsh-client, telnet-client
Depends: krb5-config, libasn1-8-heimdal (>= 1.4.0+git20110226), libc6 (>= 2.11), libdb5.1, libedit2 (>= 2.11-20080614-1), libgssapi3-heimdal (>= 1.4.0+git20110226), libhcrypto4-heimdal (>= 1.4.0+git20110226), libhdb9-heimdal (>= 1.4.0+git20110226), libheimbase1-heimdal (>= 1.4.0+git20110226), libheimntlm0-heimdal (>= 1.4.0+git20110226), libhx509-5-heimdal (>= 1.4.0+git20110226), libkadm5clnt7-heimdal (>= 1.6~git20120311), libkadm5srv8-heimdal (>= 1.4.0+git20110226), libkafs0heimdal (>= 1.4.0+git20110226), libkrb5-26-heimdal (>= 1.6~git20120311), libotp0-heimdal (>= 1.4.0+git20110226), libroken18-heimdal (>= 1.4.0+git20110226), libsl0-heimdal (>= 1.6~git20120311), libtinfo5, libwind0-heimdal (>= 1.4.0+git20110226)
Suggests: heimdal-docs, heimdal-kcm
Conflicts: ftp (<< 0.16-1), heimdal-servers (<< 0.4e-7), kerberos4kth-clients, kerberos4kth-user, netstd, openafs-client (<< 1.2.2-3), otp, rsh-client (<< 0.16.1-1), ssltelnet, telnet (<< 0.17-1), telnet-ssl (<< 0.14.9-2)

isn't even a very complex set of dependencies.

(It's also been observed elsewhere that this isn't, perhaps, the vast comedy of metadata errors one might have supposed existed.)

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.

  • Like 1

Share this post


Link to post
Share on other sites
That's a complete non-sequitur, in no way addressing the point
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.

Edited by nobodyhasthis

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.