MisterFister Posted May 2, 2016 Share Posted May 2, 2016 (edited) 1 hour ago, Hobbes Novakoff said: Is there a way to set CKAN to ignore hotfixes when figuring out if a mod is compatable? I was trying to set up a KSP directory using CKAN, but it didn't let me install a bunch of mods (for example, scatterer) because the mods were set to be compatible with 1.1 and I had 1.1.2. This has been asked at least twenty or thirty times in the last four calendar days. Please scroll back and read the entries. "No" for the end-user. The mod author metadata controls that, for the most part. And the person in the most control of the metadata (at least initially) is the mod author, from what I understand, though there are other hands on it to be sure. Edited May 2, 2016 by MisterFister Link to comment Share on other sites More sharing options...
blowfish Posted May 2, 2016 Share Posted May 2, 2016 (edited) 3 minutes ago, MisterFister said: The mod author controls that, for the most part. Well, it depends on how KSP versioning is implemented. For mods using a AVC .version, you can specify a min and max version if you choose. For mods on Spacedock, you can only specify one KSP version. For mods that have neither of those, the version has to be specified directly in the metadata. For mods that use a .version file, it's usually not as simple as just updating it - it's impossible to tell what future versions of KSP will be compatible, so most mod authors don't like to specify that future versions are compatible. But if it's already been released then you need to have a new release to update the .version file, or re-release and somehow poke the NetKAN bot into updating it (not trivial apparently, and not accessible to individual mod authors). Edited May 2, 2016 by blowfish Actual content Link to comment Share on other sites More sharing options...
Hobbes Novakoff Posted May 2, 2016 Share Posted May 2, 2016 39 minutes ago, blowfish said: Well, it depends on how KSP versioning is implemented. For mods using a AVC .version, you can specify a min and max version if you choose. For mods on Spacedock, you can only specify one KSP version. For mods that have neither of those, the version has to be specified directly in the metadata. For mods that use a .version file, it's usually not as simple as just updating it - it's impossible to tell what future versions of KSP will be compatible, so most mod authors don't like to specify that future versions are compatible. But if it's already been released then you need to have a new release to update the .version file, or re-release and somehow poke the NetKAN bot into updating it (not trivial apparently, and not accessible to individual mod authors). I meant some kind of checkbox in the settings, or something. Like, "allow mods for versions later than X." (Another thing is maybe we could have the ability to check a box and have a mod download as soon as it updates. That would also be nice.) Link to comment Share on other sites More sharing options...
rasta013 Posted May 2, 2016 Share Posted May 2, 2016 So I've been reading this thread on and off all evening and haven't found this answer anywhere so please forgive me if I've missed this answer... Has there been any reason given for why mods are now disappearing from the CKAN list entirely? I removed my entire USI suite trying to track down a serious conflict but the vast majority of the USI suite is no longer even listed. It was there, it showed me as installed, updated and current 1.1.2. Now...nothing... Link to comment Share on other sites More sharing options...
RoverDude Posted May 2, 2016 Share Posted May 2, 2016 I'm curious as well hopefully a ckan person can let me know what's up. For now you can install manually and use ksp-avc for the version checking. Link to comment Share on other sites More sharing options...
dboi88 Posted May 2, 2016 Share Posted May 2, 2016 Hi, i've just installed but i'm getting this error message 'Failed to connect to repository. Exception: Object reference not set to an instance of an object.' any ideas how i can fix this? Link to comment Share on other sites More sharing options...
NecroBones Posted May 2, 2016 Share Posted May 2, 2016 6 hours ago, rasta013 said: So I've been reading this thread on and off all evening and haven't found this answer anywhere so please forgive me if I've missed this answer... Has there been any reason given for why mods are now disappearing from the CKAN list entirely? I removed my entire USI suite trying to track down a serious conflict but the vast majority of the USI suite is no longer even listed. It was there, it showed me as installed, updated and current 1.1.2. Now...nothing... 2 hours ago, RoverDude said: I'm curious as well hopefully a ckan person can let me know what's up. For now you can install manually and use ksp-avc for the version checking. We just solved this with regards to InterstellarFuelSwitch, via some Netkan pull requests. If it's like that, then it's a dependency issue. For IFS we discovered it was listing an unnecessary dependency in the netkan metadata, one which was not showing as compatible with 1.1.2, and so the indexing was simply failing for IFS. It dropped out of the list entirely. Once the dependency was straightened out, it returned into the index just fine. Link to comment Share on other sites More sharing options...
RoverDude Posted May 2, 2016 Share Posted May 2, 2016 Sure, the rub being I own all of the dependencies and in this case, CRP which itself has no dependencies is not being listed. I'm going to just version everything up in case CKAN is having hiccups Link to comment Share on other sites More sharing options...
NecroBones Posted May 2, 2016 Share Posted May 2, 2016 4 minutes ago, RoverDude said: Sure, the rub being I own all of the dependencies and in this case, CRP which itself has no dependencies is not being listed. I'm going to just version everything up in case CKAN is having hiccups Ah, yeah that is very strange then. I wonder what else the indexer bot is doing then. Link to comment Share on other sites More sharing options...
Anbalsilfer Posted May 2, 2016 Share Posted May 2, 2016 7 minutes ago, NecroBones said: Ah, yeah that is very strange then. I wonder what else the indexer bot is doing then. One weird thing I noticed is that CKAN lists a number of mods as compatible with a 1.1.x install that shouldn't be, namely a number of mods with a "Max KSP version" of 1.0.x. Not sure if its related to the problem with vanishing mods, but it seems odd. Link to comment Share on other sites More sharing options...
RoverDude Posted May 2, 2016 Share Posted May 2, 2016 Looks like it may be SpaceDock, so I did a push to use GitHub's versioning. Link to comment Share on other sites More sharing options...
nobodyhasthis2 Posted May 2, 2016 Share Posted May 2, 2016 (edited) 16 hours ago, WildBillKerbin said: I sure hope my comments were not taken as a complaint so much as an attempt at constructive criticism and commentary. I (and hopefully most CKAN users) really appreciate all the hard work that the CKAN authors put into such a cool product. Your contribution to the KSP community just can't be overstated and I do indeed thank you! Your comments where fair and needed to be said. I can speak for anyone else but I though you made you point quite well CKAN authors are amazing and the project statistics are jaw dropping to prove it. Although just for complete clarity here. To avoid any personal miss understandings. As far as my own contribution goes. I do not deserve any praise at all. I don't do anything apart from chuck money into various pockets ( If anybody is curious, Vitas for the spacedock server. Roverdude for herding cats, Pjf for CKAN sprints ). So if I am a pain in the butt to these people. The lease I can do is buy them a coffee now and again. 15 hours ago, Hobbes Novakoff said: Is there a way to set CKAN to ignore hotfixes when figuring out if a mod is compatable? I was trying to set up a KSP directory using CKAN, but it didn't let me install a bunch of mods (for example, scatterer) because the mods were set to be compatible with 1.1 and I had 1.1.2. It depends on the definition of a hotfix across the whole community. Breaking MM could have been bad for a lot of mod owners. Plus I have seen comments off forum about having to recompile code. If it is a bigger change we have to wait to hear back from individual mod owners. This has happened before. An example being 1.0.3 to 1.0,4 was a hotfix. 1.0.4 to 1.0.5 probably was not. 13 hours ago, MisterFister said: This has been asked at least twenty or thirty times in the last four calendar days. Please scroll back and read the entries. "No" for the end-user. The mod author metadata controls that, for the most part. And the person in the most control of the metadata (at least initially) is the mod author, from what I understand, though there are other hands on it to be sure. Yes that is pretty much that is how is goes. Although we could open the flood gates directly in CKAN and let them all through with a few lines of code. The question is should we if mod authors are saying it is not a hotfix. When the answer is has been no in the past and the ball gets tossed back into the modding community, However for what is it worth. There is a link to the PR a few pages back if people want to voice an opinion on where or not it gets merged. 12 hours ago, Hobbes Novakoff said: I meant some kind of checkbox in the settings, or something. Like, "allow mods for versions later than X." (Another thing is maybe we could have the ability to check a box and have a mod download as soon as it updates. That would also be nice.) This is a massive change in the way things are done. It has been suggested over and over since we started getting stable KSP builds. So it is already done. Almost there. Honest...... Links posted a few pages back for those that want to read the code. Edited May 2, 2016 by nobodyhasthis2 Link to comment Share on other sites More sharing options...
Torih Posted May 2, 2016 Share Posted May 2, 2016 Hi, Precise Node and Blizzy Toolbar have been updated for 1.1.2, I believe they need to be manually updated for ckan to grab them. https://www.blizzy.de/precise-node/download.html https://www.blizzy.de/toolbar/download.html Thanks Link to comment Share on other sites More sharing options...
MissMolly Posted May 2, 2016 Share Posted May 2, 2016 what does this mean 748 [1] WARN CKAN.KSPManager (null) - KSP_Ckan at /Users/xxx/Desktop/KSP_Ckan is not a valid install. I'm running Ksp 1.1.2 Intel Core i5 2.7 GHz 26 GB ram this comes up in the terminal as Ckan loads. Link to comment Share on other sites More sharing options...
LeCosmopilot Posted May 3, 2016 Share Posted May 3, 2016 (edited) That's version issues so annoing... I cant install mods because 1.1 and 1.1.2 version difference.... Can author add possibilities to enable "mod force install"? Edited May 3, 2016 by LeCosmopilot Link to comment Share on other sites More sharing options...
steve_v Posted May 3, 2016 Share Posted May 3, 2016 43 minutes ago, LeCosmopilot said: Can author add possibilities to enable "mod force install"? ROFL, people have been asking for that for as long as CKAN has existed. The answer is, apparently, a resounding no. From the CLI: ckan.exe upgrade <mod identifier>=<version> will force the issue. Get version and mod identifier from the gui (look at bottom of "metadata" panel for id) or by grepping through CKAN/registry.json. I don't know where this attitude regarding user-overrides comes from, but it's a royal pain in the proverbial. So much so that I'm still doing manual installs. Link to comment Share on other sites More sharing options...
ExavierMacbeth Posted May 3, 2016 Share Posted May 3, 2016 (edited) I would have to agree to making an option to have CKAN ignore existing installed mods or allow installation of older mods be considered. I have an issue right now where CKAN is forcing me to uninstall mods that while technically work (Planetshine for example) under 1.1.2 haven't had their metadata updated. If I don't, I get an exception error that crashes CKAN when I try to install any mod that has a multiple config option, for example Custom Asteroids. I keep getting a variation of this error: (Though obviously this one is for RCSBuildAid rather than Planetshine now that I uninstalled Planetshine to see if I can actually get Custom Asteroids to install. Spoiler See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** CKAN.ModuleNotFoundKraken: Cannot install RCSBuildAid, module not available at CKAN.CkanModule.FromIDandVersion(IRegistryQuerier 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, IRegistryQuerier registry, KSPVersion kspversion) at CKAN.MainModList.ComputeConflictsFromModList(IRegistryQuerier 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.<>c__DisplayClass2.<ThrowAsync>b__3(Object state) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.6.127.1 built by: NETFXREL3STAGE 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:///F:/Win7Apps/SteamLibrary/SteamApps/common/Kerbal%20Space%20Program/ckan.exe ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.6.79.0 built by: NETFXREL2 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.6.79.0 built by: NETFXREL2 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.6.79.0 built by: NETFXREL2 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.6.1064.2 built by: NETFXREL3STAGE CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.6.79.0 built by: NETFXREL2 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.6.1068.2 built by: NETFXREL3STAGE CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- Microsoft.GeneratedCode Assembly Version: 1.0.0.0 Win32 Version: 4.6.1064.2 built by: NETFXREL3STAGE 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.6.79.0 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.6.79.0 built by: NETFXREL2 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.6.79.0 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.6.127.1 built by: NETFXREL3STAGE 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.6.79.0 built by: NETFXREL2 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.6.79.0 built by: NETFXREL2 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.6.79.0 built by: NETFXREL2 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.6.127.1 built by: NETFXREL3STAGE 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.6.79.0 built by: NETFXREL2 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.6.79.0 built by: NETFXREL2 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. EDIT: And for those who are stating to just install them manually. The problem is that I still have so many of them installed, especially now that we have stable 64bit, that I sorta need CKAN just to keep track of them all. I don't particularly fancy refreshing 72 forum threads daily just to see if one got an update just because CKAN is forcing me to uninstall my list every KSP version, which then causes the mod to become untrackable. Since there is no "favorites" list I can set up to have CKAN let me know when a valid update is available so I remember to reinstall it. Edited May 3, 2016 by ExavierMacbeth Link to comment Share on other sites More sharing options...
politas Posted May 3, 2016 Share Posted May 3, 2016 (edited) On 01/05/2016 at 9:43 AM, MisterFister said: As requested by the mod author, I am reporting here that the Kerbal Stock Part Expansion mod lists a flawed forum URL in the metadata. Is there any way I can assist in correcting this? You can try reporting the correct URL, rather than forcing us to re-do investigations you've clearly done yourself, at the very least. Edited May 3, 2016 by politas Link to comment Share on other sites More sharing options...
JWag Posted May 3, 2016 Share Posted May 3, 2016 4 minutes ago, politas said: You can try reporting the correct URL, rather than forcing us to re-do investigations you've clearly done yourself, at the very least. Here is the KSPX (Kerbal Stock Part eXpansion) thread: http://forum.kerbalspaceprogram.com/index.php?/topic/96464-11x-kspx-kerbal-stock-part-expansion-mod-reposted-v02101-20416/ Link to comment Share on other sites More sharing options...
politas Posted May 3, 2016 Share Posted May 3, 2016 2 minutes ago, JWag said: Here is the KSPX (Kerbal Stock Part eXpansion) thread: http://forum.kerbalspaceprogram.com/index.php?/topic/96464-11x-kspx-kerbal-stock-part-expansion-mod-reposted-v02101-20416/ The KSPX homepage in CKAN is actually taken from the Spacedock page, so stupid_chris can fix it any time he chooses. Link to comment Share on other sites More sharing options...
DanHeidel Posted May 3, 2016 Share Posted May 3, 2016 I just want to start by saying that I greatly appreciate the work done by the CKAN team and that there's no ill will here. That said... I am uninstalling CKAN and have no plans to use it again. CKAN's blind enforcement of versioning makes it completely unusable. There needs to be a way to allow the end user to override incorrect or outdated version numbers. This would be a trivial change to implement and despite constant and overwhelming user demand for this feature, has been consistently ignored by the dev team. I honestly cannot understand such a strong aversion to a needed and highly requested feature. It is perfectly reasonable to have the versioning controlled by the mod creator. However, ultimately this is my KSP install and I should be able to install a mod with the understanding that a version incompatibility might break my game. That should be my decision to make. I've seen arguments that the end user can just do a manual install of the mods. What is the point of using CKAN then? Right now about half my mods are versioned at 1.1.0 or 1.1.1. I would have to remove them all from CKAN and do manual installs. Then I've got to regularly check spacedock for all of these mods to see if they've updated, manually delete them and re-enable them in CKAN. That's worse than nothing. I'm keeping track of CKAN mods on post-it notes and hammering Spacedock. You're better off just doing it all by hand at that point. Using the mod creators as the definitive version control is a good place to start but hardly flawless. You see plenty of mods that have version requirements like 1.1.99 or 0.25.0+. Are we to believe that a mod creator that was working back in version 0.25 knew for a fact that their mod would be compatible with 1.1.2? There are other cases where the mod creator has confirmed that the mod works with the latest version but simply hasn't had time to update the version listing. CKAN is correct in that the mod creator should be the go-to information source but assuming that the input data is flawless is provably wrong. I wish the CKAN the team the best but request that they reconsider their hard stance on this issue. This single issue is taking an otherwise awesome utility and basically making it useless for the purpose it was created for - managing KSP mods. Link to comment Share on other sites More sharing options...
Rafael acevedo Posted May 3, 2016 Share Posted May 3, 2016 (edited) Can you please upload the newest version of kerbal planetary base system into ckan. Thanks https://github.com/Nils277/KerbalPlanetaryBaseSystems/releases/tag/1.0.10 Edited May 4, 2016 by Rafael acevedo adding link Link to comment Share on other sites More sharing options...
Wuwuk Posted May 3, 2016 Share Posted May 3, 2016 Kerballoon dont install - bad link. Fix please. Link to comment Share on other sites More sharing options...
MisterFister Posted May 3, 2016 Share Posted May 3, 2016 (edited) 12 hours ago, politas said: The KSPX homepage in CKAN is actually taken from the Spacedock page, so stupid_chris can fix it any time he chooses. Sorry, that's bullcrap. @stupid_chris has enough on his plate, please and thank you. You were correct in suggesting to me that I had a great opportunity to provide a URL to you when I didn't, and that's something that I would've called out someone else for had I been an onlooker, so no worries on that item. But then you get the info from someone who happened to log in before I had a chance to see this and respond, and your first response is "well I looked at it, no-ma-yob." No. I, right here, brought this to the attention of the CKAN thread. (Yes, I erred in not providing more thorough information with URL links.) "Well our info points to a SD listing, so that mod author can fix it any time he chooses." No. If I were reporting an issue with the SpaceDock listing being in error, then fine. But this isn't a SpaceDock thread on the KSP forums, it's a CKAN thread. I didn't report an issue with the SD listing, I reported an issue with the CKAN metadata. The end-user product being delivered and discussed in this particular searchable and indexable conversation is CKAN. The end-user experience being prioritized here is CKAN. CKAN's metadata, at the end of the day, in my view as a user, is CKAN's responsibility and no one else's. If others want to help or contribute (you know, like I did when I asked if there was something I could do to help after pointing it out) then that's fine. If the mod author specifically wanted to help, then that's hunky dory as well. But to offload it onto the mod author, summarily, nonchalantly like that? No. 9 hours ago, DanHeidel said: I just want to start by saying that I greatly appreciate the work done by the CKAN team and that there's no ill will here. That said... I am uninstalling CKAN and have no plans to use it again. CKAN's blind enforcement of versioning makes it completely unusable. There needs to be a way to allow the end user to override incorrect or outdated version numbers. This would be a trivial change to implement and despite constant and overwhelming user demand for this feature, has been consistently ignored by the dev team. I honestly cannot understand such a strong aversion to a needed and highly requested feature. It is perfectly reasonable to have the versioning controlled by the mod creator. However, ultimately this is my KSP install and I should be able to install a mod with the understanding that a version incompatibility might break my game. That should be my decision to make. I've seen arguments that the end user can just do a manual install of the mods. What is the point of using CKAN then? Right now about half my mods are versioned at 1.1.0 or 1.1.1. I would have to remove them all from CKAN and do manual installs. Then I've got to regularly check spacedock for all of these mods to see if they've updated, manually delete them and re-enable them in CKAN. That's worse than nothing. I'm keeping track of CKAN mods on post-it notes and hammering Spacedock. You're better off just doing it all by hand at that point. Using the mod creators as the definitive version control is a good place to start but hardly flawless. You see plenty of mods that have version requirements like 1.1.99 or 0.25.0+. Are we to believe that a mod creator that was working back in version 0.25 knew for a fact that their mod would be compatible with 1.1.2? There are other cases where the mod creator has confirmed that the mod works with the latest version but simply hasn't had time to update the version listing. CKAN is correct in that the mod creator should be the go-to information source but assuming that the input data is flawless is provably wrong. I wish the CKAN the team the best but request that they reconsider their hard stance on this issue. This single issue is taking an otherwise awesome utility and basically making it useless for the purpose it was created for - managing KSP mods. Oh dear lord, this speaks to me. I can't find fault with any of this. I'm beginning to consider doing the same thing. I may retain CKAN as a method of discovering mods, on an otherwise manual install. Ladies and gentlemen, go do a text search within this discussion for "ferram" and you'll see a clot of posts stemming from late October 2015. I've spent a good... I dunno, two hours maybe(?) over the last two days reading those discussions. FAR was perhaps the first high-profile mod that had this happen, but my understanding from having read both before and after that time period is that the human-issue was bound to come up eventually for someone. Spoiler The short-version technical explanation of what was going on back then: CKAN installs mods with an overall success rate of "better than a mid-level-skilled human" but slightly below "perfect." CKAN uninstalls mods with a much more random track record, however, since CKAN is programmed not to delete files that it doesn't remember creating and installing. This means that any time a mod creates its own files during the course of gameplay, CKAN will clean out that GameData/[ModName] folder of all of the original files that it recognizes, but leave behind the "crumbs" of data files that were created, along with the folder itself. Well, around that time, a version update from v14.x to v15 of the FAR mod involved the need to delete the FAR folder with some files that, with a CKAN-managed scenario, would have been left behind by the old version. Since users didn't know about this issue, what ended up happening was the new version got installed alongside old files, which sent things completely haywire because that particular version change made the mod behavior peculiarly vulnerable to such an error... something happened with a version update for FAR that Ferram can explain and clarify better than I can. I understand that there was a version of FAR that introduced a new need for a dependency called ModularFlightIntegrator (sp?) that was bundled properly with the mod-author's intended zipfile. Previous versions of the mod never had such a dependency. However, since FAR was indexed to CKAN kinda sorta without the mod-author's knowledge through some sort of automated metadata-generation process, the data within the zipfile was not properly copied into the player's GameData folder along with the new dependency. The mod then attempted to run, never found the dependency, and all kinds of error-message hell broke loose for reasons that made no logical sense when the issue was first brought to the mod author's attention. Maybe the zipfile was "treated" as if it were simply a similar zipfile from previous versions of FAR that never carried such a bundled dependency? I'm not sure. (A parts-only mod has almost none of these problems because the parts are only "objects" as opposed to a plugin-mod which is a "thing that does something." Hell, even plugin-mods don't tend to have this issue often, but when it does happen, it's a doozy.) This caused a lot of problems on the FAR support thread, because users of FAR were reporting it as a problem with FAR, and it took a while to realize what the issue was. @ferram4 reported that here on this thread, and there were three distinct phases in the types of responses he was getting, and they happened in a rather easy to identify sequence as the conversation progressed. The first phase of response was, "Wow, that's odd, I guess that's a limitation of CKAN. Why don't you just tell your users to be sure to uninstall the mod with CKAN, and then alt-tab out to their GameData folder to delete the old leftover crumb-folders before installing the new version." That translates to, "this problem happens to affect you, so why don't you be the one to tell your users about the solution since they're going to you anyway." I paraphrase the second "phase" of response as, "These things can either not be avoided at all, or cannot be avoided without drawing volunteer-resources (already in short supply) away from other issues that 'affect' more CKAN-users." And the third phase was, "I feel you, and I'ma let you finish, but CKAN solves more problems than it creates, and because of the fact that we prioritize those benefits above your inconveniences, we're at an impasse." Note, I can't really use any phrasing more neutral than that while also retaining its plain-English meaning. That actually is what the sentiment became, and I specifically invite anyone reading my words here to reject my word for it -- go look yourself, it's all still there. It has variously simmered down and / or escalated from there at different time periods and across more forum threads than just this one, and I won't continue rehashing it here, except to say that at least once I saw a statement by someone else wishing that Ferram would just go away and take FAR with him. That's.... not "verbatim," but it's also a rather conservative paraphrase, since the exact phrasing was pretty close to that. tl;dr -- I really like the idea of mod-authors' efforts and time investments being respected not only by users like me, but by fellow mod-authors and content creators. Here's why I'm bringing this up here, and it's not for the mere sake of a history lesson or to watch myself type. It was an example, perhaps the first very-high-profile example in CKAN's history (happy recent anniversary to CKAN, by the way) but by no means the most recent example, of users like me being put in the middle. What do I mean by that. I'm glad you asked. Lookit. I run mod-heavy. Spoiler I have a backed up copy of KSP v0.24.2 that I played in 64-bit Windows (back when Squad actually tried to release 64-bit KSP for Windows before they pulled it back) where I was running a solid 85-ish mods. My RAM footprint at KSC idle screen was ~6GB. This was before CKAN existed, so it was by definition a manual-mod-install build. I was having troubles getting past some in-game glitches that were ultimately symptoms of the whole reason that Squad pulled the plug on Windows 64-bit to begin with, but as a standalone matter of mod conflicts, it was fine. FAR, I don't think it immodest of me to say that most people would agree with me here, is a rather must-have mod Part of the whole reason that CKAN exists is because people wanted a way to install common mod-sets, such as Realism Overhaul, of which FAR is a prerequisite. When ferram hard-disabled his plugin from even working in 64-bit Windows, that's when I took the plunge and learned how to install Linux with a dual boot on my computer. In 64-bit Linux, still running manual mod installs, I progressed through the KSP versions and I've saved the final iterations of each one. Pertinent to this story: v1.0.3 ended up running with ~200 mods by my latest estimate looking at my archived backup (merely counting GameData folders can be misleading because of how some authors place multiple mods that they design in the same consolidated GameData subfolder, such as "ThunderAerospace," whereas some single mods are spread out across several folders, such as EVE.) All manually installed, the hard drive footprint of the GameData folder was over two gigs. RAM footprint at KSC idle screen was ~5.1GB if I recall correctly. On KSP v1.0.3, I played 2-4 sessions per week, averaging 2-3 hours per session, and once a week I'd spend approximately an hour or two at a session trudging through forum posts, KerbalStuff [rest in peace] and CurseForge [*shudder*] entries looking for mod updates, alongside AVC or whatever its equivalent was at the time. Notably, I'd have to troubleshoot those updates, which involves starting KSP and running some in-game diagnostic tests (if a forum post indicated a mod update was designed to address a CTD bug after making a certain type of connection in the VAB, I'd go into a sandbox and deliberately try to trigger the CTD to assure myself I'd updated properly, for example). With that many mods loading, my load times would often run more than half an hour per attempt. Longer if I was trying to see if it was freezing on load, or if a newly installed / updated mod had to do some first-time-load things that would take longer. I emphasize here that 1-2 hours dealing with updates was a week-over-week average. Some sessions were less than 40 minutes including the load test, some were 3-5 hours and I never got to play. The KSP migration from v1.0.2 to v1.0.3 was rather sedate, but the migration from v1.0.3 to v1.0.4 was quite persnickety with mod compatibilities. That was also around the same time period that my offline life got a lot more hectic with law school and other whatnots. Having some individual outlier weeks where my mod troubleshooting time consume more than half of my weekly playtime, with it averaging most weeks at about 30%, that was borderline unsustainable by itself. The transition from KSP v1.0.3 to v1.0.4, across two hundred mods, was nightmarish. Between crashes themselves borking my savefile to high hell, let alone non-crash issues that borked the savefile simply due to how many craft I had floating around the Kerbol system with modded parts on them, I spent at least a dozen hours over three weeks doing nothing but surgically editing my savefile itself. That's on top of actual mod-update efforts, load-testing my mod updates, and load-testing my savefile edits. That's when I picked up CKAN. My modlist changed, I dropped 35 and picked up 70 or so, I think. Decided to reboot my in-game career. It was glorious! Single-click versioning? At-a-glance metadata?? Auto-suggested prereq mods, with a SEPARATE pass for auto-suggested "recommended" companion mods?!? Dear Lord Jebediah Kerman, I'd entered the Promised Land!!! Now I could budget 3-10 minutes for mod updates at the beginning of each play session, which fit my reduced playtime availability perfectly. I still ended up losing hours surfing forum posts once in a while, but that was elective research, not required-on-penalty-of-something-not-working-correctly. I ended with exactly three mods that I still needed to maintain manually. The first of those three was EVE, because of how finicky I was, personally, with how I wanted the texture resolutions to appear. CKAN was very capable of handling it at the time, just not capable of doing so to my own personal standards. My second manual-mod was BoxSat because it simply wasn't indexed on CKAN (at the time, I was frustrated by this) and the third was InGameNotes, because it had a problem with one of its Blizzy Toolbar icon textures that caused an issue with TextureReplacer, so I decided to manage that mod manually as well. That's it. And despite that being the period of my law school career that I had the least amount of time available for deep-into-the-night marathon play sessions, it's what I consider to have been my personal Golden Age of KSP, simply because "CKAN made it work." Yes, I learned a lot about gravity turns, and managing orbital refueling networks, and DangIt design redundancies that made sense in career mode, and RemoteTech planning issues, and setting up contingencies for life-support emergencies before I launched kerballed missions because KerbalConstructionTime made emergencies into Very Serious Things with high stakes and razor-thin margins of error. But those were not the reasons I consider that time period to have been my person Golden Age of KSP. I was because I could satisfy my mod-addiction as thoroughly as I wanted without it turning me into the KSP equivalent of a junkie who spent more of my time getting my next mod-fix than I spent enjoying the high I'd gotten from the last one. There are four "Great Debates" in KSP that I'm aware of. First is the MechJeb Debate. Second is the debate over which is the best life support mod. Third, I would argue, is this CKAN-or-manual debate. tl;dr -- I really like the idea of CKAN. I know how to manage mods manually. The fourth Great Debate is mods-vs-stock. "Mods are cheating!" "No they're not!" "When it's stock, I'll consider it non-cheating!" "Take that back!" "Your kerbal wears combat boots!" It gets nasty. But it boils down to a fundamental question -- "How Is KSP Meant To Be Played?" And the stock-with-no-mods conclusion I disagree with (obviously) but its logic is undeniable: mod management takes away from play time. Mods, at their most absurd, have all of the hassles of DLC except financial cost to the user, with very few of the benefits. And CKAN, very simply, brings very-mod-heavy play a lot closer to The Way KSP Is Meant To Be Played -- by playing it, instead of load-testing it. So when arguably the two single most significant enablers of my ability to enjoy KSP amid my busy offline life (CKAN for time management, FAR for in-game aerodynamics) are competing with each other... frankly, it liquides ticks me off. [Edit; the adult-language autocorrect for "pi.ss.es me off" transmogrifies it into "liquides me off." I find that to be just plain odd.] I'm in law school (until I graduate in thirteen days -- yay!). Law, communication, arbitration, and dispute resolution are what I do. They are, quite literally, my stock in trade. When I am put into a position where no matter what I do, I end up having to somehow side "against" another person who has done right by me in the past, that's unfair. I am unavoidably either: 1.) contributing to CKAN's userbase, which is then used, even if unwittingly and unintentionally, as justification for "moral hazard" (an intriguing keyword hit within this particular forum thread, if you're curious for context); 2.) "just wanting my mods to work" and having to navigate forum thread responses from mod-authors who are obviously answering through gritted teeth when I bring a CKAN-metadata or KSP version compatibility question; 3.) being caught in the middle where I am literally telling someone like @NecroBones that there are mods pertinent to his work that simply disappeared from CKAN, whereas I come back here and see someone else get told by @politas that @Ippo can fix a metadata-listed forum link "any time he chooses." Frankly, I'm privileged to be in the position that I'm in -- I benefit GREATLY from CKAN without being utterly helpless without it. Just like I benefit greatly from MechJeb's Hohmann Transfer Planner, because I can't synch up an orbital rendezvous for excrements, [edit: a more understandable language-filter autocorrect] but I can dock decently even without NavyFish's DPAI mod, though obviously that makes docking a cinch. The only downside for myself from dropping CKAN that I can see, beyond the time and convenience issue which I can work around, is the fact that there have been a fair few mods I discovered initially through CKAN, so I may keep the .exe for that standalone purpose. I don't have to decide right now, and I also choose not to decide right now, but I'm seriously considering dropping CKAN. Edited May 4, 2016 by MisterFister Link to comment Share on other sites More sharing options...
Ippo Posted May 3, 2016 Share Posted May 3, 2016 (I have just been pulled in the conversation by the mention and have no clue of the context of the post) Is there an issue with any of my mods' metadata? If that's the case, let me know and I'll fix it ASAP. Anyway, from what I gather of the post, the issue is twofold: the metadata and the source of the metadata. Yes, we can manually fix anything we want in the generated metadata, but if the source of the automatically generated metadata has a mistake, we'll keep generating wrong metadata that will need someone to fix it at every update. So it's basically like curing the symptoms without curing the illness. Link to comment Share on other sites More sharing options...
Recommended Posts