LatiMacciato

Same here too! This effects the light parts: domeLight1, navLight1, spotLight3, stripLight1 in the file ../[GameData]/SuperfluousNodes/SN_utility.cfg. Quick workaround was to write a cfg-file with following content: // re-add surface mountability to these lights: domeLight1, navLight1, spotLight3, stripLight1 // [GameData]/SuperfluousNodes/SN_utility.cfg @PART[domeLight1,navLight1,spotLight3,stripLight1]:NEEDS[SuperfluousNodes]:AFTER[SuperfluousNodes] { @attachRules = 1,1,0,0,1 } @Geonovast please consider updating this in the following release because the lights are meant to be attached on surface by the stock system. Regards

Hi! I have noticed in KSP 1.12.3 no Kerbal is taking any snacks on the road (EVA), for me they are only getting EVA Propellant. 1 snack is getting substracted properly from the part where the Kerbal sat in right after going EVA tho. Is this a known bug?

Honestly I was blushing, when I saw my forum name on your release name MUCH thankies @zer0Kerbal!! Yes, the reason why I used :FINAL in first place is that not all labs get the blue description text while using :FOR[] caused 2 parts remaining which don't get the module nor the description. I have figured my issue is caused by ScienceLabInfo and I wrote a cfg for mod compatibility. Maybe the :HAS is unecessary tho but the :AFTER[ScienceLabInfo] did the trick: I confirm my lazyness and apologize for that, thanks for your understanding! I love the idea! It will make things easier!

Hey there! I was wondering why none of my labs has any FTF modules, so I checked the cfg-files. I noticed this release might have a wrong dependancy in "FieldTrainingFacility/Compatiblity/FieldTrainingFacility.cfg": // original: @PART[*]:HAS[@MODULE[ModuleScienceLab]]:NEEDS[FieldTrainingLab]:FOR[FieldTrainingFacility] { @description ^= :(.)$:$0\n<#6495ED>Field Training Facility. </color>: // suggested replacement: @PART[*]:HAS[@MODULE[ModuleScienceLab]]:NEEDS[FieldTrainingFacility]:FINAL { @description ^= :(.)$:$0\n<#6495ED>Field Training Facility. </color>: With this modification it works again. I have also added a ":FINAL" to make sure that every part that includes a "ModuleScienceLab" module gets a blue description text/info after everything for proper patching within the patching order. ":FOR[ ... ]" and ":FINAL" cannot work together. Maybe the ":FINAL" fix could apply for FTL too to make sure all parts with a "FieldTrainingLab" module get a proper description too. I decided to suggest this because I think "FieldTrainingLab" shouldn't be a dependancy for "FieldTrainingFacilities" or is this intentionally? Waves!

Considering that you might not be able to recover with the current KSP version (v1.11.x) for funds you could dump the rare resources into the planetary depot for later usage. That's what I do atm instead of trying the Nth resource to recover but ending up broke again.

that was not my point, I think 'better' is a choise of taste. KIS/KAS is not maintained by RD

define better, but regardless what is your source?

Well, it would be cool to have a toggle option for the BlacklistedHomeworldResources (found in the WOLF.cfg) or I have misunderstood the existing options. EDIT: after digging deeper and catching up on stuff I've found USI_Core issue #118 maybe that is connected tho. I also noticed that all expensive resources with high "unitCost" values (RefinedExotics, ExoticMinerals, RareMetals, even ColonySupplies) are getting the "+-" values when recovered. (I possibly should ask that in another spot) Is that intended to be a feature of USI or am I missing something?

I really would wish for an option to toggle or choose resources that are allowed or forbidden to recover on homeworld so any player can choose a "cheaty way" or not for the career gameplay. Regardless of that I like big parts that combine steps without having too much parts after all. Ty for the new features! That's just my 2 cents after considering to uninstall MKS but decided to keep it anyways.

Heyas, my persistence.sfs contains a Snacks section and there I have noticed a typo where I'm not sure if it's a big issue or hassle tho. I have found the corresponding part in your source: .. /Snacks/SettingsAndScenario/SnacksProperties.cs I'm just trying to drop constructive critics

The original mod from @Shadowmage has a great spirit to control how Kerbals are spawned when they are distressed, I also enjoy seeing this is kept alive by this follow up. Regardless of that is is essential to rescue Kerbals from space I'm trying to focus on other things in my career game so I've limited the allowed pods to easy MK1-sized via this script: On a side-note diversity in pods that can be rescued can be fun too! (it's yet a hassle IMHO)

I guess having a log file would be helpful in any case so we can verify what happened when and what is installed etc.

nobody said that .. maybe things just did not went well because the one or another mod installs or overwrites the B9PartSwitch mod to a previous version .. it's a wild guess. Making sure having the latest verions of the dependencies is the first I would try. Oh and I'm using KSP 1.9.1, maybe that diffe4rs from your version. All I can say is that I do not have this issues and I have a heavyly modded KSP.

for me things are fine after the latest update! check the B9PartSwitch version, I'm using v2.16.0

so far my script works just fine and was just made to evaluate the issue. I might need to check out the parts USI_Nuke_*, FTT_Service_375_01 and FTT_Reactor_500_01 but I assume they behave line the Duna/Tundra parts. my small script: I raised Issue #122 for this.