Gordon Dry

@ensou04 how about releasing the fixed version?

Okay, I got it. For some reason also several checkboxes for "auto install" where checked where they should not be checked. As soon as they are, stuff gets removed. I don't understand the underlying logic for that behaviour, but at least I found the culprit.

Using KCT with CKAN RP-1 Express Install and after unlocking an R&D node it says "Update point added" but it's not visible immediately as in earlier version, a scene change is needed to get it shown. On the other hand it's nice that the font turns to green to show that upgrade points are available.

I wonder that there are still no community patches with sane default values for different part types - and a pull request on Github then. That every part gets a "1.0" is wrong. And I shed a tear because in a pre-hiatus state of archived mods I got an MM config with a whole bunch of those patches ... but it's gone.

It's not a rant, it's a first impression. I did not use CKAN all those years before my hiatus and there was a reason why, I just do not remember exactly and in detail what it was. For clarification: How do I update a mod that is flagged as being updateable then?

After coming back from a hiatus I just wanted to be part of the wonder that the actual compatible KSP version for Realism Overhaul / RP-1 is the actual KSP version. So I did a fresh install, downloaded CKAN and let it do its job according the manual. Everything allright. I added a handful of suggested and compatible mods. Allright. Today I see there is an update for ROEngines, so I want to update it with CKAN. I click the checkbox in the "Update" column, click "Apply". It lists a whole bunch of mods it claims it will remove, saying "Auto-installed, depending modules removed". I don't believe that CKAN could be so dumb or malicious, so I click "Continue". Really, it deletes all those mods. What the heck? Is CKAN so counter-intuitive that it's impossible to update one mod without deleting dozens of others?

https://github.com/linuxgurugamer/FilterExtension/pull/54

This excrements is still a thing. Unbelievable.

Untick "auto" I assume.

I use JNSQ, JNSQ 10x, GPP, GPP 10x and GPP secondary with scatterer 0.0828 without issues - at least when tabbing through all celestial bodies in the Tracking Station I don't see anything weird. Is it different when "really" being in orbit of those affected celestial bodies?

With 1.1.0 the added textures still got mipmaps but most of the old textures lost them.

@PART[*]:HAS[@MODULE[ModuleDataTransmitter*]:HAS[#antennaType[INTERNAL]]]:FINAL { @MODULE[ModuleDataTransmitter*]:HAS[#antennaType[INTERNAL]] { @antennaType = DIRECT } }

Yes, read 2 posts above yours.

Finally somebody has read the needs of some dozens of helpless users.

Could you please alleviate the strictness of allowed science parts to fulfill the requirements, for example more magnetometer boom parts than just the one "dmmagBoom" etc?

It's the other way around. Core first.

Main issue: It's not possible to build a US core + fairing + wedges when building from bottom to top in VAB, it has to be built from top to bottom. Try placing a US core above another part - it's not possible anymore to attach the fairing. Even flipping parts 180° and trying to build upside-down is impossible - it seems to be restricted by the US code.

From Github? Then they're responsible for slow speed and sometimes this happens, could be a DDoS, could be a DNS issue, like as normal nowadays. Or a server room employee slave stumbled upon a cable jack. Now, 12 hours after your post, I downloaded with max. speed (250 Mbit/s in my case) without an issue. Edit: And you know what? Sometimes stopping a slow download and restarting it fixes the issue.

Altering variables' values can not be an issue regarding licensing. ~[snip]~ If anybody ever would disallow other people using patches on top of their configs this would just be *bruh* and *facepalm* and nothing else. Then the whole purpose of ModuleManager and the modding API would be in question.

Some of the orbital parameters came up to the protocol papers after the launch was done, written down by a protocolist - so it's easy to put those into contract configs, but nearly impossible in some cases to recreate them. Only parameters that have already been set before the launch should be in contracts.

either FOR or AFTER

@Shizen For scaling stuff to fit to planet packs I use a template like this: scalefactor = 1 @scalefactor:NEEDS[SigDim] = #$@SigmaDimensions/Rescale$ @scalefactor:NEEDS[!SigDim,RealSolarSystem] = 10.10625 @scalefactor:NEEDS[!SigDim,JNSQ] = 2.7 @scalefactor:NEEDS[!SigDim,GPP_Rescale_10x] = 10 @scalefactor:NEEDS[!SigDim,JNSQ_Rescale_10x] = 10 scalesqrt = #$scalefactor$ @scalesqrt != 0.5 and then from within a patch node I refer to #$/scalesqrt$ to for example multiply with it. In some cases I even use #$/scalefactor$ if I need the bigger number. In a later patch I remove those temporary variables to unclutter the MM cache.

GameData\QuickMods\QuickSearch\QuickSearch.version { "NAME": "QuickSearch", "URL": "http://ksp.spacetux.net/avc/QuickSearch", "CHANGE_LOG_URL": "https://raw.githubusercontent.com/linuxgurugamer/QuickMods/master/QuickSearch/README.md", "DOWNLOAD": "http://spacedock.info/mod/101/QuickSearch", "GITHUB": { "USERNAME": "linuxgurugamer", "REPOSITORY": "QuickMods" }, "VERSION": { "MAJOR": 3, "MINOR": 3, "PATCH": 0, "BUILD": 9 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 8, "PATCH": 0 } } http://ksp.spacetux.net/avc/QuickSearch: { "NAME": "QuickSearch", "URL": "http://ksp.spacetux.net/avc/QuickSearch", "CHANGE_LOG_URL": "https://raw.githubusercontent.com/linuxgurugamer/QuickMods/master/QuickSearch/README.md", "DOWNLOAD": "http://spacedock.info/mod/101/QuickSearch", "GITHUB": { "USERNAME": "linuxgurugamer", "REPOSITORY": "QuickMods" }, "VERSION": { "MAJOR": 3, "MINOR": 3, "PATCH": 0, "BUILD": 11 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 12, "PATCH": 2 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 12, "PATCH": 0 } } 3.3.0.9 vs. 3.3.1.1 vs. 3.3.1 (as previous post says). Confuzizous!

This is a personal zFinal patch that limits the minThrust to 25% and could be edited accordingly. It only looks for entries without minThrust or with a minThrust = 0, so any already existing custom value is not affected: @Kwebib DO NOT USE THAT PATCH This patch is not working in this way as it needs code (which would be Realism Overhaul). Just with this patch an engine never can throttle down. Sorry for the confusion.

https://github.com/net-lisias-ksp/ModuleManager/wiki/Patch-Ordering