MisterFister

You beat me to it, sir! I have video of the issue being discussed, though I emphasize that this issue only appears when the mod is nowhere else installed on your system. if you have this mod active on your KSP install, it'll show up, but it's de-listed for new installs. Note, video plays best if downloaded and played from desktop specifically with VLC, as opposed to other players, as opposed to playing it directly through the web portal viewer embedded into the Dropbox link. Color Coded Canisters installs just fine for me -- it pulls MM and that's it.

I'm aware of core-dll and shared-asset mods. I'm at a loss as to what could ever me wrong with my copy to any extent that I could diagnose, as it's a single standalone .exe that was most recently released six weeks ago. Nevertheless, I redownloaded it just now to recreate the issue and took recorded video of the process, available here. Note, I establish in the video that I have a v1.1.1 and a separate v1.1.2 copy of KSP active, and CKAN is entirely unable to confirm the existence of your mod's prerequisite within the index in either event. Switching focus to the v1.1.1 copy allows me to attempt to install your mod so as to generate the actual error message in question. If you're telling me that the symptom is different for me than for you, then fine, but if you'd care to view my video capture before commenting further, that would at least allow me to verify if I'm going crazy or not. Note, the file views best when you download it and play from VLC, instead of WMP and instead of viewing it through the Dropbox browser portal.

What about specifying a range of compatible versions within the metadata file, or amending the metadata? I see plenty of mods listed as "compatible" but not for v1.1.2 specifically.

Absolutely, yes, no question at all, most definitely. Though, I'd suggest marking it as compatible with both 1.1.1 and 1.1.2, if you feel that's appropriate. CKAN works on metadata files. CKAN is a front-end interface, it's not a "repository" like Curse or Spacedock or Github or even Dropbox; it's an index. Well, it's actually two indexes. The first index is of metadata files with information on where the mod is stored for download, how to download and automatically unpack it, and a series of manually-entered info on what KSP version (or range of versions) that a mod author is willing to personally, manually, and intentionally certify that a mod version is compatible with. With a new version of the mod is published, the metadata is appended and not replaced -- CKAN will remain capable of managing the old version of the mod if a user ever wanted it, or if the user were managing mods for an older version of KSP. Those metadata files are manually filled out by someone who intends to submit a mod, or a mod version, or a metadata update for a mod, to the CKAN index. (Typos in the metadata files can be persnickety.) The second index is on your computer hard drive, wherein it tracks what folders it's made and "owns" and steers well clear of any folder that it doesn't recognize (such as "Squad," or such as any mod you manually install -- this is why mixing a lot of manual mods with a lot of CKAN mods is a recipe for pain.) If KSP autoupdates, such as through Steam, on an otherwise existing GameData folder, then CKAN will be able to track mods installed on its internal index, but will only be looking at the outward-index for mods pegged as compatible with the "current" KSP version. Mods pegged as being compatible with previous versions will still be suppressed for purposes of first-time installs. Note that "my streamers and friends use a mod that lists here as being a version mismatch" is one thing. Yes, I agree with you -- your friends do it all the time, that's true. "...and that must mean that the version mismatch is unimportant" is an entirely different statement. "I wish CKAN would just understand that 'the mod is working despite the version mismatch' means that the mod is still compatible." CKAN will never understand that, even if it were true, and by the way, it's not true. The difference between "fails with no symptoms" and "is actually compatible" is something that only the mod author specifically can ascertain, and ONLY with log files. Period. Everything else is guesswork. Work from a backed up copy of v1.1.0 until the mod metadata is manually and intentionally updated by the author. This has been asked for a long time. Either it won't happen, or there's an issue with making it happen. I can say that, in my opinion, introducing this would be a bad thing. Mod support is a very thankless role. I promise you, these restrictions are there to make the mod authors' jobs just slightly less worse.

Hi there. I edited my post on the FTP thread after you'd already Liked it when I saw your signature and realized that I was already talking to the purveyor of IFS. (Also, KSPIE is an awesome mod too.) Anyway, I see this update here to v1.1.1... aaaaaand literally eight minutes before I began typing this, v1.1.2 pushed through steam. I see no CKAN listing of any kind for IFS, irrespective of KSP version. I do see KSPIE however, still tagged for v1.1.0. Is this a CKAN issue that IFS is not listed in any way? Am I doing something wrong in looking for it?

Any development on this? Perhaps repurposing a license-forgiving model from another engine set? In the alternative, would you suggest that I attempt to muck with the textures on my own for my own purposes? Or perhaps I'm going about this rather clumsily. I'm in your camp that I would tend never to use this particular engine as Squad designed it, only because my gameplay focus is on runway-launch spaceplanes as opposed to stack-launch. Form factor is more important to me in the mid-game and end-game than raw thrust-density. Despite the fact that you're "a rocket guy" and I might be a spaceplane guy, my own philosophy is that stack launching spaceplanes is a waste of spaceplane potential, thereby causing me to agree with you but for the ironically-opposite reason from yours. If a clone-option exists at the ready, I'll take it, but even if not, I think I'll switch to Viktor and call it a space program.

Does @magico13 agree with this? And speaking of, I see references within the last few pages of prereleases and community fixes. I run CKAN, and I try to run exclusively CKAN where possible. I backed up my old KSP and am building a new modset from a virgin copy of v1.1.1. CKAN's default behavior is to rather strictly enforce version mismatches, and my experience leads me to rather prefer it that way, though I know I can manually override and tell it to install whatever version of the mod that I want. Sir, your mods here are all currently CKAN-keyed to v1.0.5. Is this intentional? I'm not asking when an update might be out, but I guess I kinda sort of am asking if one is in the pipeline for them at all. I run them all except Field Experience and Tree Toppler, and they're all superb mods that I consider must-haves and I really think they bring this game closer to what the stock game should be. Also, I'm reading up on KRASH -- how does that mod differ from KCT, or interact with it?

Note to @FreeThinker: I typed ALL of this below before glancing at your signature line and discovering you are the developer of IFS. I intend to visit your thread now, then, because I'd presumed (recklessly) that @NecroBones developed both, which is somewhat implied by the notations on CKAN but not explicitly stated. I'll ask here if you plan to host IFS-Core on CKAN, and if that becomes a drawn out discussion I'll happily visit that mod's thread. Well, the question of mod dependencies and other info that comes from the metadata file (or errors within that metadata itself) are questions that the CKAN thread advises us to ask the mod developer / submitter. Beyond that, the CKAN-related troubleshooting considerations very highly lend toward choosing to run all-manual, or all-CKAN. Running a handful of oddball mods either way (heavily manual-modded but a handful of CKAN-managed mods, or heavily CKAN-modded with a small, number of manual mods) is often something a user can get away with, but large numbers of mods from both categories is troublesome because of how CKAN tracks folders that it "owns" for purposes of backtracking, uninstalling, update versioning, etc. I'm willing to go download the mod manually if I have to, but the fact that this mod is listed on CKAN (I'm led to understand that mods are not often "listed accidentally" and that someone actually submitted it for repository listing, and filled out a metadata file to do it) implies to me that this mod author would need to know about this metadata mismatch. It's not unheard of for a mod to be third-party submitted, and that's not a violation of most distribution licenses I don't think, and if this were the case here then of course I'd run off and worry about the mod manually without bothering the mod author. That said, the metadata for this mod and a few others are specifically calling for a dependency here. It's not calling for dependency to a mod that's listed but hasn't itself been updated to KSP v1.1.1 (what I think might be known as a "secondary version mismatch" or something) but it's listing to a prerequisite mod that's not listed at all, at any KSP version. That's a very uncommon circumstance in my experience with CKAN, and this mod author is exactly the person I need to report that to unless the mod author him- or herself replies otherwise. It means either that these mods were uploaded without the mod author's knowledge; the mods were submitted with flawed metadata, and a simple re-upload of each mod with corrected metadata for each mod will fix the issue; the mods were correctly uploaded with valid metadata but the prerequisite mod had some sort of issue, including the possibility that it was corrupted during upload or that someone neglected to upload it at all; the mod author, for whatever reason, intended to remove the prerequisite mod and hasn't followed up, or hasn't finished by also removing the other mods that call for it as a dependency; or else the prerequisite mod was properly uploaded at some point but has since been removed unintentionally, also an unusual circumstance. That last item would be unusual because CKAN is designed to be a rolling archive -- deprecated and obsolete versions of mods, still compatible with obsolete versions of KSP, are still available through CKAN. For example, if someone wanted to install v0.90 and design a modlist around that, any CKAN-listed mods from back then that were compatible with that KSP version would still be available for download and CKAN-management. Unanticipated removal of any mod, prerequisite or otherwise, is not a normal occurrence. Also, CKAN and Spacedock are rather notably integrated. My own estimate is that more than half of all CKAN-listed mods are hosted and downloaded from Spacedock anyway, and CKAN is simply a repository index manager.

Hi there! I backed up my KSP v1.1 (I have a tidy little collection of versions growing!) and then performed a complete uninstall / KSP folder delete / reinstall through Steam to v1.1.1. I'm using CKAN to build a new modset, and things are going surprisingly well, through predictably slow since I intentionally allow CKAN's default behavior of rather strictly enforcing version mismatches with mods. As mods get updated in the repository for being compatible with v1.1.1, the modlist that I can choose from grows. I'm trying to install the Alternis Kerbol Rekerjiggered Flags mod. When listing all mods, the download size of this (113535) is actually larger than the system-changing mod itself [listed as not-yet compatible, of course] at 109893, both sizes listed by CKAN in KB. Notably, the flags-mod leads me to this thread, but the CKAN-metadata forum page for the actual mod itself simply points to the Github page (is this intentional?) Anyway, I'm trying to install just the flag set and not the mod itself for the time being. This was before I saw literally the last discussion before my own in this forum thread, discussing the forcible suppression of Kopernicus. Before coming here, I did manually verify my GameData folder and only AlternisKerbolFlags is placed there from this mod entry. I navigated to the CKAN download cache, and the zipfile there "B2FDC149-AlternisKerbolRekerjiggered-flags-1.5" nevertheless contains three folders: AlternisKerbolFlags, AlternisKerbol, and Kopernicus. I emphasize, the second and third folders have not been copied into my GameData folder, and I am not asking for them to be copied, since what I'm looking for is the flag set and not the mod itself. Is this intentional? Is this a result of the Kopernicus suppression discussed before I got here? Will an update to Kopernicus cause this mod to spontaneously activate? Is there really more than 100MB of data in a simple flagset? I fully intend to run this mod at some point, but for now I'm designing a modset with a different Kopernicus-build in mind. Thanks!

Howdy! I've already posted the above at the end of the Colorful Fuel Lines release thread. I'm experiencing this same issue with this mod, now. I'm slogging through troubleshooting a new install of v1.1.1 with mods-from-scratch through CKAN, and I suppose if I hit this again, I can consolidate my reports somewhere if you tell me the preferred location. Anyway, I report the following screensnips: Any advice?

Greetings! I have a question about this mod's listing on CKAN, and I was directed here. This mod is listed, recently, as being manually-confirmed as compatible with v1.1.1 (which is a change from 24 hours ago). However, when I attempt to select this mod for install on an install of KSP v1.1.1 with a handful of only confirmed-compatible CKAN-managed mods, I get the following error: Attempts to locate InterstellarFuelSwitch-Core or any keyword permutation thereof yields no joy, including turning off all mod filters and instead searching "all" repository-listed mods regardless of KSP version. Is there something I'm doing wrong?

Well, something is off within the metadata somewhere. I speculate it might be a single-digit typo in whatever file it looks to. I know that I am running an otherwise-sterile v1.1.1, and I note in my screensnip above, and verified anew just now before I type this reply, that the "Max" KSP version is 1.1.99. I wonder where the "Min" might be listed, perhaps that's an issue. As for installing it manually, I'm perfectly willing to do that, but there are vast and very numerous advantages to not mixing CKAN-installed and manual-installed mods on the same KSP folder, as discussed with dozens of individual issues throughout the CKAN release thread. Those advantages go beyond simple convenience for management of this one mod in isolation; CKAN tracks folders that it does and doesn't "own," and putting in a lot of folders that it doesn't recall placing there can create issues down the line, especially for heavily-modded installs, which is where CKAN benefits really come into play anyway. I just checked, and I am already using the current version of CKAN, v1.16.1-g2e91715, and this version of CKAN has been out for a while with no recent updates to it. While I highly recommend you consider tinkering with it as an enduser, because it really does streamline and resolve a LOT of error checking and update management (it scales with mod usage, though -- for a small handful of mods, it's a rather even trade, I think -- in terms of dozens or, in my own case, hundreds of mods installed, it's a godsend)... since you indicate that you don't have familiarity with it as a user, I can note for your benefit here that there are separate "secondary version mismatch" errors that have cropped up on other mods. "Secondary version mismatch" is a term I'm coining here and doesn't come from CKAN itself, but it's an error that occurs when a current-updated mod has a dependency-mod which has not yet updated, and it reports THAT secondary version-mismatch separately from what I'm seeing here. The error for RealPlume here is specifically telling me that, regardless of what's listed on my repository selection list that I show in my screensnip above, something that the mod looks to for versioning info is telling CKAN that my installed KSP v1.1.1 is not "listed" as compatible (it never knows what "is" or "isn't" compatible, it just refers to listings, listings that I'm led to understand are the exclusive purview of the person submitting the mod for repository listing.) Note on the new snip below (error message omitted for redundancy) that CKAN is properly detecting that I'm running KSP v1.1.1 (top left).

Alrighty then. Be advised, I am specifically not asking for an update or for any estimates on when an update could become available. Instead, I'm noting in this thread that development is continuing, but the CKAN flagging for it seems like it's more out of date than activity on this forum would suggest. I was simply asking whose attention I'd bring that to if not yourself. (Full disclosure, I backed up my v1.1 install and am intentionally operating from a sterile copy of v1.1.1, and CKAN defaults to a rather persnickety enforcement of version number mismatches, no matter how slight.)

As for custom URL installs, I have nothing to do with CKAN but I've troubleshot CKAN and a lot of management utilities like it. Based on what I see the utility "doing" with respect to GameData folders and tracking what it's done for "ownership" purposes as well as for update / uninstall purposes, against what I gather from these forums as to how the backend registration process works for mod authors submitting their work to the repository; I'd suggest that pulling unvetted source data, even if it's at the user's own risk and discretion, can interfere with some of the error-proofing already in place. I'm not even talking about malware or licensing issues, I'm talking about sheer technical tracking. That said, as a fellow user, I can at least agree with you that some form of this idea could potentially become useful to me. I know that I intentionally allow CKAN to restrict me to only "compatible" mod listings as keyed against my KSP version number. Since backing up my v1.1 and running a new and sterile v1.1.1, that means that a lot of v1.1 or v1.1.0 mods are not listed for me for the time being, at least until someone on the backend manually submits a repository update that explicitly affirms that v1.1.1 is within the known-compatible range of KSP versions. I suspect that some users are not as aware of CKAN's habit of doing this, since allowing CKAN to modify updated installs is a more common practice than what I'm doing, which is to intentionally begin with a new and sterile copy of the game before proceeding further. And to be sure, CKAN will allow you to work with updated versions, simply pegging installed mods for updates as they become flagged as available, despite the fact that uninstalling the mod in question would result in being entirely unable to CKAN-reinstall it due to the apparent version mismatch.

CKAN still lists this mod as being keyed for KSP v1.0.4. Is there a CKAN update in the pipeline for v1.1.x? The announcement a few tiles back indicates v1.1, but not v1.1.1. (oi these version numbers are at an annoying-to-type state, huh? :-p )

Sir, I offer the following CKAN-error report. It seems there is a config selection available on CKAN but no base mod. Please note that I am currently running KSP v1.1.1 via Steam on Windows 7 64-bit.

To that end... is there any way that we can get a CKAN function to show us "only mods that have become listed since we last checked"? Or a way to manually "favorite" or "follow" mods without installing them? Or a way to list the mods we've installed chronologically, such as for troubleshooting if we know that our game worked fine before that last batch of five mods was added?

Howdy folks, just a brief question about how the backend CKAN submission process works for mods. With the migration from v1.1 to v1.1.1, of course, mod compatibility (and notations of mod compatibility) is again an issue. My question: if a mod author submitted an updated metadata file to CKAN "now," how long would it take to register as updated at the client side of the equation? Is this a thing that simply reflects at midnight according to some specific timezone, or with manually-triggered batch updates, or some other formula? Thanks! CKAN is a lifesaver!

Um. Hmm. Well, after posting my bug report, I know that I noticed that I was not filtering CKAN properly against my KSP version. I noticed that before noticing that the specific mod I reported to you was also mismatched. So, by scraping all of that out and starting over, I know that I've simply prevented this issue from cropping up again. Sorry. Second, however, is that I am of the impression that it's a filenaming error within a zipfile. This was saying that a file downloaded and installed by one CKAN-mod was attempting to overwrite an identical filename provided by a second. I can re-download the zipfiles through CKAN and manually inspect them to verify my speculation, if you think that'd help. And to be clear, I'm reasonably convinced that manually deleting "whole" GameData subfolders isn't the best troubleshooting method for CKAN-managed mods, though if I'm misunderstanding either your suggestion here, or if as the mod developer asking me to intentionally do it anyway to report symptoms, then of course I can happily proceed.

Sir, I am sent to this forum thread from the CKAN metadata Homepage tag for TankLock. Is this in error? Where can I find more information about how to learn more about what that other mod does so that I might consider installing it? PS -- I'm a fellow Linux user, coming back to Windows now that KSP has proper 64-bit support!

@SmarterThanMe Just wanted to advise you of a minor-seeming CKAN conflict. In attempting to select and install multiple ribbon packs, I received the following CKAN error: Oh no! We tried to overwrite a file owned by another mod! Please try a `ckan update` and try again. If this problem re-occurs, then it maybe a packaging bug. Please report it at: https://github.com/KSP-CKAN/CKAN-meta/issues/new Please including the following information in your report: File : GameData/STMRibbons/EngRoles/FinalFrontierCustomRibbons.cfg Installing Mod : STMsFFRibbonPackExpeditionRibbons 0.5.1 Owning Mod : STMsFFRibbonPackEngineeringRoles CKAN Version : v1.16.1-0-g2e91715 (beta) Your GameData has been returned to its original state. Ha, note that CKAN does not format this text in such an easy-to-read fashion -- the "invisible carriage returns" on my Windows7 64-bit system force the above code to be smooshed into just a few lines of text, which I simply copy-pasted here. Good to know that the interface here on the forums will help me make sense of it. Anywhoozle, I'm slowly progressing through CKAN one screen-length at a time (since my Linux64 experiences lead me to worry about CKAN crashes when installing lots of mods, and I'm in the process of stress-testing v1.1 in Windows) but this seemed pertinent to what you're doing here. Thanks for an awesome set of ribbon packs!

I like this, a favorites flag, and a time-date-stamp of install, date of last version check, and date of last update. For large sprawling installs with hundreds of mods, it'd be useful to be able to backtrack my steps. Also, very key -- something to "disallow" or "ignore" a mod, perhaps with a user-editable description of why. When I make an affirmative decision to uninstall a mod and not go back to it, I want CKAN to ignore it. A handful of times I've tried a mod because the description seemed enticing, and either I plain didn't think it was my cup of tea, OR I removed it due to a conflict with something else I was trying to accomplish. Then, a few days later, I see the enticing description again...

"Made CRP possible" was poor word choice on my part. "Happened around the same time," is what I was trying to say, and from what I remember as to forum chatter, yes, TAC's definition of the variables was a significant part of the discussion at the time. I can't quote from that discussion verbatim of course, but it all happened around the same time in kerbaleering history. And I'll formulate my USI-LS questions and ask them separately on your mod's thread.

CKAN was heavily keyed to KerbalStuff, but wasn't exclusively dependent on it. What source CKAN pulls any given mod from is customizable by the mod author who registers their mod with CKAN, and many mods pulled from GitHub, MediaFire, and even a few were from DropBox oddly enough. Obviously, though, the lionshare was with KerbalStuff, and when that site went down, so too did any CKAN-attempt to pull from that source, which I estimate to have been about 65% of all CKAN mods. KerbalStuff went down at a rather persnickety point in the mod-ecosystem lifecycle, because most modders kinda walked away from releasing major updates in anticipation of needing to rework them entirely for v1.1 anyway. If we'll all recall (setting aside the potentially-valid claim that, with its bugs, v1.1 isn't exactly "here" yet anyway, since there'll likely be several v1.1.x hotfixes in the coming weeks anyway) v1.1 was originally hoped for by us, the players, several months ago. When you add the calamity of KerbalStuff and the CKAN-attachments to it all going down earlier this year, again, many modders just put everything on hold until after getting their v1.1 updates ready to ship (a process which I estimate is about 15-20% done anyway -- my prediction is late May or early June for full ecosystem revival.) So, @Mattasmack, if you just happened to pick up CKAN for the first time recently without realizing there was still a little bit of a mushroom cloud hanging over it, well, now you know how close your shave actually was.

@ShotgunNinja First off, I reiterate from my previous post that I recall that when TACLS moved over to metric units, savegames were simply broken, period. Different era, different version of KSP, and with @RoverDude's reminder, it was the changeover that made CRP even possible. It may or may not be avoidable here. My only suggestion (my background is not in programming but IS in logistics deployment and "making lots of people happy with change when their default is to be unhappy with inconvenient changes") is to carefully announce the change ahead of time, and to accomplish as much with one save-breaking version rollout as possible to minimize the need for multiple save-breaking version changeovers. In the alternative, design a little offboard ditty-utility designed to specifically modify saves. As for the third bulletpoint, I've already said before that I am diehard TACLS. Since TACLS might be going away... *shrug* I politely suggest that you either take that over and absorb it, or even replicate it within your own code. No offense to @RoverDude, but the USI LS wasn't as satisfying an in-game challenge for me. Which brings me to my point to you regarding mass. To assign them as massless, in my mind, you're simply defaulting for waste products to be vented overboard. When playing TACLS, I NEVER vented wastes overboard unless it was an absolute emergency. My in-game justification was that I wanted the waste products to be returned home to KSC for biological and medical analysis of kerbonaut long term health exposure, as is the real case with ISS crew being rotated. Maybe you should consider implementing something like that, wherein CO2 / SolidWaste / WasteWater could be returned to KSC for some sort of science value scaled to reflect the longevity of the exposure to space travel? This is of course in addition to being able to recycle it into new Water / O2 / "mulch" or some equivalent, of course, but I'd care to prevent "waste science" from being collectible in a science lab -- this would ensure that a player couldn't just install the station crapper inside the science lab and somehow unlock the career tech tree by shipping up "productive" foods like burritos and asparagus. Ultimately, I really do realize that I'm asking you to make your mod "just like TACLS" because I hate change and I love that mod so much. In the alternative, could you consider making your internal functions toggleable? From what I read, your mod overwrites some RemoteTech functionality that I also hold near and dear, as well. Perhaps splitting your mod into an interrelated suite, like USI, would be a possibility?