HebaruSan

So you have no actual reason to think CKAN's doing anything wrong? I guess I can't say I'm surprised. It's just too bad that TweakScale users have to suffer the consequences of that attitude. Fixing messes requires credible reports of actual problems.

One further note: The current maintainer of TweakScale has not requested to have TweakScale removed from CKAN. CKAN has a strict policy that such requests are to be honored; mods are only in CKAN if the author agrees to it and doesn't request removal. You can draw your own conclusion about how seriously to take talk of "ditched" and "support" based on that.

Anyway, if such an issue truly exists and anyone stumbles upon it, please report it so it can be investigated and fixed (rather than posting a dubious "rant" in some obscure place, which virtually guarantees nothing would improve): https://github.com/KSP-CKAN/CKAN/issues So far there have been no such reports resembling the above. Frankly given how CKAN works, it just sounds like blaming someone else for the currently active fork of TweakScale working poorly if you install other mods and keep them up to date.

Thanks for the heads-up. Do you happen to know of an official announcement of this? I'm technically not the developer of CKAN (the others just aren't very active at the moment). We've looked into it, and it's not as simple as "just sign it." Code-signing certificates are costly, and you have to pay every year. That's a high hurdle for a free open source project to clear.

Is anything that's being complained about there actually different from when users upgrade mods manually?

Perhaps another heat-in-space user story could take inspiration from JWST, given how high-profile its heat engineering was: Parts that require low temperatures to operate (MIRI and friends) Parts optimized for blocking incoming sunlight and inhibiting conduction (sunshield) Parts that transfer heat from one spot to another (cryocooler) Granted, not everyone got a kick out of watching JWST cool down for 60+ days, but it still seems like a potential win if some similar challenges could be wrestled with in-game.

The CKAN client v1.33.2 "Laplace" is released! ... with a fix for that. ☝️

Thanks! If you'd like to test the real fix, too, you can download it here from the Artifacts dropdown: https://github.com/KSP-CKAN/CKAN/pull/3863/checks (Remember to uncheck the "Set as default" checkbox.)

Yeah, I wasn't clear, the default has to be set before you launch. So if you close after those errors and re-open, they shouldn't happen again (unless something also stops it from saving the default). Thanks for the report! We had one come in on Discord very early but it wasn't enough to guess what was going on.

The details about the exception from that popup would be really helpful. Usually there's a "Details" button. EDIT: Nevermind, I reproduced this by un-setting my default instance. For now checking the default checkbox would presumably be a workaround for this problem. Looks like we'll be doing a hotfix...

The CKAN client v1.33.0 "Lagrange" is released! Changes since v1.32.0 Features [GUI] Allow GUI users to delete registry lockfiles (#3829, #3841 by: HebaruSan; reviewed: techman83) [GUI] Show unmanaged files in game folder (#3833 by: HebaruSan; reviewed: techman83) [GUI] Installation history tab (#3834 by: HebaruSan; reviewed: techman83) [GUI] Hide fake instance creation in GUI (#3839 by: HebaruSan; reviewed: techman83) [GUI] Tooltip for auto-installed checkboxes (#3842 by: HebaruSan; reviewed: techman83) [Core] Default install_to to GameData/Mods for KSP2 (#3861 by: HebaruSan; reviewed: techman83) Bugfixes [GUI] Fix NRE on purging cache in GUI (#3810 by: HebaruSan; reviewed: techman83) [GUI] Only update Versions tab when the mod changes (#3822 by: HebaruSan; reviewed: techman83) [Multiple] Treat reinstalling a changed module as an update (#3828 by: HebaruSan; reviewed: techman83) [Core] Scan for DLLs with or without primary mod dir (#3837 by: HebaruSan; reviewed: techman83) [GUI] Show download errors for upgrades (#3840 by: HebaruSan; reviewed: techman83) [Core] Stop trying to check free space on Mono (#3850 by: HebaruSan; reviewed: techman83) [Core] Handle missing KSP2 exe (#3854 by: HebaruSan; reviewed: techman83) [Core] Linux network fixes (#3859 by: HebaruSan; reviewed: techman83) [Core] Include repo etags in transactions (#3860 by: HebaruSan; reviewed: techman83) Notes CKAN releases are built in clean-room conditions and do not contain viruses. If your virus scanner reports a problem, it's a false positive. Please report it to the company that produces your virus scanner, not us, since it's their software that's not working properly. This release of the CKAN has not been tested on Mono releases prior to 6.8. We highly recommend that Mac and Linux users upgrade to the latest stable release of Mono from mono-project.com. You will need the equivalent of the mono-complete package for your OS. Release image under CC-BY-3.0, courtesy of Xander89

That's a bug, to be fixed in the next release (which should be out soon™). It was originally reported a while ago, but the cause was obscure and the investigation proceeded slowly. I think I finally have a solid grasp of what was happening though. If you'd like to try the fix early, you can access the test build here: https://ksp-ckan.s3-us-west-2.amazonaws.com/ckan.exe

Yup, that popup is telling you that Steam is about to fix it.

Let it.

Like this?

Absolutely! So should we add the current version as-is, requiring TU instead of TURD, or should we wait for a new release? It sounds like the former to me, but better to check first.

Hi, since we received a pull request to add this to CKAN, I wanted to let you know that TURD can't be added to CKAN because it's hosted on Google Drive, which presents the files as a web page that the user has to click in a browser to download, so automated tools (like CKAN and its infrastructure) can't access them. Since TURD is a dependency of this mod, it unfortunately can't be added either. We can revisit this if this mod ever drops the TURD dependency or if TURD changes its hosting arrangements. Cheers!

The QA team probably failed to reproduce it by cheating a command pod into space to save time, whereas the bug requires a decoupler and tank to be staged off the back of the pod (with no save/load before re-entry).

The original (now locked) thread by @r4m0nseems to be: Several early replies mention version numbers beginning with "1" instead of "2", so that should at least get you back before the current "MechJeb2" branding. There do not seem to be any links to anything else from back then, but if you're just interested in the code history, it's all still there in git, starting from the "Initial import." commit here: https://github.com/MuMech/MechJeb2/commits/master?after=cb53e7c644a9b1864637f6c74f98a222d139df5a+2740&branch=master

My own speculation is on the previous thread on this topic:

Maybe the QA team is testing by cheating a pod into space on its own rather than launching a full mission, to save time. It kind of sounds like the drag cube occlusion is being stamped permanently onto the parts and not updated when the last bit is staged away (since a command pod would contribute no additional retrograde drag with a decoupler and tank covering its back). Presumably that caching isn't stored to the save file, so the proper drag cube would be calculated at load.

The above conversation is taking place in the context of what Curseforge is and how it operates. The shutdown and later limiting of the third-party api.cfwidget.com API was given as an example of the downsides of their business model for users. That happened in June 2019, and the API link shared above became operational in May 2022. From June 2019 until May 2022 (about 1055 days), there was no external API access to mods on Curseforge, because Curseforge decided to make it so. This may be of interest to some users deciding whether to use it.

The CurseForge Upload API (linked above) is, unsurprisingly given its name, for uploading mods. It does not provide a way to list mods or retrieve information about them or their releases. The third party API that Curse previously had shut down (api.cfwidget.com) did provide these things. It has since been brought back up, but with various fields removed that would have allowed users to browse and download mods without using Curse's own software.

Curse is a commercial enterprise. Its business plan is to monetize modding communities via the familiar model of attracting web traffic and selling ads. This can be beneficial in some cases, as when some modders receive small payments for hosting their mods there, and it can be detrimental in other cases, as when they compelled the shutdown of the only (third-party) API for listing and downloading mods they host to ensure Curseforge would be the exclusive beneficiary of those modders' work. CKAN is a community-driven open source project. Its earliest versions grew out of efforts by KSP modders and players to automate the process of installing the large suite of mods that then was or later became known as Real Solar System / Realism Overhaul / Realistic Progression (a role in which it continues to this day). Its only monetary costs are small fees for the lowest tier of AWS cloud services to run the metadata crawling bot, which is paid out of @pjf's personal patreon; everything else leverages free services (primarily GitHub). All bug fixes and enhancements to CKAN's application code and the associated mod metadata are done by unpaid volunteers (themselves often also mod authors) who donate their time to a project they find interesting and worthwhile. Sometimes there are functional problems when two mods are installed together. For non-CKAN users, the solution is simply to avoid installing those mods at the same time. However, when both mods are in CKAN, one author may request that CKAN add what's called a "conflict" relationship between the two mods, and CKAN can thereby find itself in the crossfire over which mod is at fault. Rather than taking it upon themselves to declare one side right and the other wrong, which is likely beyond their expertise anyway, the CKAN team tries instead to encourage the two parties to work together to find a suitable compromise, which may take the form of collaborating (gasp!) to make sure that everyone is satisfied with the outcome. Usually this works very well, as a good solution can almost always be found, and most mod authors are able to work well with others, with their different perspectives from working on different mods allowing them to anticipate problems that the other might have missed. Unfortunately a few mod authors believe their inherent rightness to be so indisputable that this is taken as an offense and a cause for resentment. Occasionally (twice in the past 6 years), a particular mod author may become aggrieved with the CKAN team because they feel that its members have not donated enough of their free time to a particular task, or have not donated it quickly enough to satisfy what these authors feel they are entitled to. Usually this is after CKAN team members have already donated many hours to helping these individuals with previous requests; sometimes toxic or abusive behavior like indignantly refusing to compromise, name-calling, or spamming leads to less enthusiastic, more reluctant, and thus fewer donations of time; and sometimes persistent negative, hostile complaining just drains the fun out of doing the work. Sadly, when this happens, the best option is to disengage, because someone who blames and attacks you for not volunteering enough probably can't be convinced that they aren't entitled to demand that from you.

I don't think there's a forum setting for it, but if you have an ad blocker extension installed in your browser, this filter seems to work: