DasSkelett

If it helps, for CKAN you don't have to create a new release, it would suffice if you update the compatibility data in the remote version file at https://taniwha.org/~bill/ExtraplanetaryLaunchpads.version CKAN would pick that up and update the compatibility data of the existing release.

The remote version file link is "https://ksp.spacetux.net/avc/VesselNotes.version", so HTTPS not HTTP, which means port 443. Maybe that is the problem? Until just now other remote version files were fine, however a few minutes ago they all started to return 404.

@linuxgurugamer FYI, the remote version file is timing out: ksp.spacetux.net/avc/VesselNotes.version

@linuxgurugamer is this intentional? Also it appears you haven't added the dependencies to the netkan:

TURD isn't on CKAN. @TT213, what you installed is probably "Textures Unlimited". This is not the same as TURD, and explains why it "didn't work" for you. You need to install it manually, see the download links in the first post. @Manwith Noname no worries, we won't index any of your mods without your consent, we would ask you before indexing it. But right now it wouldn't actually be possible, because CKAN doesn't support Google Drive download links (or better: Google blocks software that is not a browser controlled by a human from downloading).

And if with "purging" you mean that you applied the "Hidden" label to it, you can undo that by filtering by this label and then removing it from the mod via the context menu again.

Friendly reminder, someone just pointed the outdated version file out to me again, maybe you could take a look when you have some free time. Thanks!

Hey @Lisias, can you double-check the zip uploaded to SpaceDock for this release? I think you uploaded the one with the CurseForge layout (GameData contents directly at root of zip), instead of the other one (GameData contents inside GameData folder, also containing Extras and INSTALL.md) as for previous releases.

Thanks for the confirmation! If you dropped the date part from your mod versions that would definitely be very convenient for us and reduce the maintenance effort. However, CKAN aims to handle whatever mod authors throw at it, so please don't feel pressured to do it, especially if it serves a good purpose for you.

Hey, small question: the release has the number "2.13.202109.2" on SpaceDock. This format is different than previous versions like "2.12.20210823" or "2.11.1.20210817", with the day-of-month digit being split from the year+month part with a dot. Is this a mistyped "0", i.e. should the version have been "2.13.20210902" instead? Or is this intended and just a new format for future version strings? Asking because for CKAN we are stripping the date part from the version string to make it work with the version sorting logic, and the new release breaks the existing regex, so we may need to adjust it if it is not a typo.

As @HebaruSannoted in the other thread, it is likely caused by KSP still running in the background, from time to time it doesn't close fully when exiting. Check in the task manager if there's process for KSP still running. Otherwise, just reboot your PC. After that installing/upgrading/uninstalling should work fine again.

No, that's intended and fine. Definitely not the cause for your issues or those log lines. You might have a second, manually installed Scatterer somewhere hidden in your GameData.

This mod is already indexed, we received the automated PR from SpaceDock in April. .version files are not strictly required for SpaceDock mods, without it we just take the compatibility from SpaceDock. Edit: but of course, whenever you have any questions regarding CKAN, you are very welcome to contact us. Be it our forum thread, per PM, Discord server, GitHub... Or if you're planning to do bigger, restructuring changes to your mod, maybe add or remove some dependencies, we are always happy about a little heads-up beforehand.

Hey @JPLRepo, we've got a request to index your mod in CKAN. Would you be okay with this? We only do it if that's the case. I've seen the note about CKAN above. Of course, metadata would be purely maintained by us (except if you want to propose changes, you are always welcome to). I can't promise that we won't have to ask you a question every once in a while if we need clarification on something, though. Similarly, we also encourage users to report CKAN problems to the CKAN thread, if you pointed them to us we'd be very grateful.

So, did you figure something out, or maybe even successfully test this mod with TextureReplacer? @Beetlecat mentioned it might need some folder rearranging, and as far as I can tell, this is true – for TextureReplacer the files would need to be inside a "GameData/**/TextureReplacer" folder, however this mod doesn't come with a "TextureReplacer/" subdirectory. The config also has an explicit "TextureReplacerReplaced {}" node telling TRR the location of the "Heads" directory. So to me it looks like this mod explicitly needs TRR to work, but if someone has some more knowledge on this topic, please tell.

Hm, IIRC TextureReplacer and TextureReplacerReplaced aren't interoperable, something with a different folder structure required for the dependent mods? I'll have to take a look, adding an "any_of" is simple, but this might not actually correct for this mod. Edit: oh, should've read a few comments above, they're mentioning this as well. Will need to do some reading trying to figure out how it affects this mod.

With that little information it's impossible to say what happened and why it happened. Something happened to the registry.json, maybe it has been deleted, or it got corrupted. In the second case you should've gotten a message box with a help text saying what to do now. Most importantly: your mods should still be installed, they're still working, CKAN just doesn't know about them anymore. You can start with what @Caerfinon suggested, but be advised that this might not reinstall all of them, as CKAN can't detect every mod. Alternatively, you can also import the "installed-<name>.ckan" file in the "<KSP>/CKAN" folder, which contains all mods installed by CKAN after the last change. If this file is already overwritten, because you might've already started the reinstallation process, you can also use one of the "installed-<name>-<date>.ckan" files in the "<KSP>/CKAN/history" folder, look for a recent one from before the incident.

The mods themselves are compatible with KSP 1.12.1, however (some of) their dependencies are not. For EditorExtensionsRedux, it depends on ClickThroughBlocker, which in turn depends on ZeroMiniAVC and ToolbarController. ToolbarController still has KSP 1.11.2 as max KSP version. Since those mods very likely work perfectly fine, as they are dependencies of almost all of Linuxgurugamer's mods, and plenty of people installed them on KSP 1.12 already, you can install them regardless. Either by force-installing the outdated dependencies first, or by collectively telling CKAN to consider KSP 1.11 mods as compatible. Most people select KSP 1.8 and above there currently, as that was the last big update that broke a bunch of mods. However there are still mods that have broken since, so make sure to check the forum thread if in doubt.

That was not caused by updating KSP-Recall. These mods don't have anything to do with each other. As @dzin already said, you probably just unchecked Kopernicus and MFI by accident, and once you hit "Apply changes" to update KSP-Recall, it also removed those two mods as they were in the changeset. And as @Lisias said, CKAN problems go on the CKAN thread, not other mod threads. Don't bother mod authors with them, usually they can't help you anyway.

This usually means that KSP is still running. Make sure it's closed fully, also check the task manager. Try restarting your PC if you can't find a KSP process.

@linuxgurugamer it has been said already, but just to underline it again: The latest release on GitHub (0.43.0.10) is missing the release zip. It leads to a lot of confusion, and people downloading the source code zips wondering why it doesn't work. You should take a look at this soon.

Sorry for that. Should be fixed now.

Thanks for explaining the technical details behind this, always helps understanding why things are like they are. I'm going to move it to a recommendation then for now, since that's what you as the author have in mind. If you change your mind some day, because users don't stop asking about the empty space, just let us know

Hey, just spotted the adoption by pure chance. I noticed that KerbinSideRemastered is no longer listed as dependency, but only recommendation. It has initially been added with version 2.0 of KSCExtended (release notes). Is this correct, should we move it from dependencies to recommendations on CKAN as well? While I'm on it, the version file currently has a link to the repository as its "URL" property. However, the URL property is supposed to link to an online copy of the version file itself, if used. So in this case the value should be "https://github.com/JadeOfMaar/KSC_Extended/raw/main/GameData/KSCExtended/Version/KSC_Extended.version" or "https://raw.githubusercontent.com/JadeOfMaar/KSC_Extended/main/GameData/KSCExtended/Version/KSC_Extended.version".

Hey @SingABrightSong, congrats on your (first?) mod! While looking at the mod for indexing it in CKAN after receiving the automated SpaceDock PR, I noticed that your patches use ":FOR[Snacks]". If I understand the ModuleManager documentation correctly, only the mod itself should add a ":FOR" clause with its own name, because it signals ModuleManager that this mod is installed. Module Manager generate list of case-insensitive modname values that will work in NEEDS, BEFORE, AFTER by doing the following: * Scans all the loaded DLLs and adds modname.dll to the list of loaded mods (just the modname portion) * Scans all the configs for properly configured FOR[modname] and add modname to the list of loaded mods <======= * Scans the GameData directory and adds modname to the list of loaded mods, with white space characters removed from the name of the folder (space, tab, and several others defined by Unicode/.NET). https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering#valid-modname-values It is not recommended to use the :FOR directive to refer to other mods than the one you are writing. https://github.com/sarbian/ModuleManager/wiki/Patch-Ordering#the-beforemodname-formodname-and-aftermodname-directives For signalling a dependency on another mod, you are supposed to use ":NEEDS" (like you did for ReStockPlus), to my understanding. While this is not a problem for CKAN users, because they will always have Snacks installed due to the dependency, it can create issues for manual installers that are missing Snacks, because it would mean that not only your patches, but also all conditional patches of other mods that support Snacks are applied, even though Snacks is missing.