Gordon Dry

I tried adding it to the decouplers from UniversalStorage2 with their own module USDecouple but that did not work. The MM patching is allright, but the ModuleDecouplerShroud is gone in VAB ... it's in ModuleManager.ConfigCache though: https://github.com/nav0t/DecouplerShroud/pull/9

This old thing: Building a custom mun lander setup with a descent stage and an ascent stage on top of it only gives proper dV readouts (KER, MJ, doesn't matter) with LF+Ox, but not if both engines use MonoPropellant. This is an old issue and never has been fixed. As soon as the fuel is MP (or XenonGas) there is global crossfeed enabled. This is a bummer. Is there a mod that breaks the "global crossfeed rule"?

@Araym could you please allow opening issues at https://github.com/Araym-KSP/BDBNIC ? Meanwhile, I get this error with the latest version of your master branch: [WRN 17:27:19.147] Warning on PartSubtype BDB Apollo Gray on module ModuleB9PartSwitch (moduleID='textureSwitchPaint') on part bluedog.Apollo.Block1.Nose: Texture 'Bluedog_DB/Parts/Apollo/bluedog_Apollo_Capsule_New' not found! With Bluedog_DB apollo-saturn-revamp that is.

I dared to add those four patches to GameData\KerbalInventoryForAll\InventoryforAll.cfg @PART[*]:HAS[#title[*ervice??odule*],!MODULE[ModuleInventoryPart]] :LAST { MODULE { name = ModuleInventoryPart InventorySlots = #$../mass$ @InventorySlots *= 10 @InventorySlots ^= :\.\d+:: packedVolumeLimit = #$../mass$ @packedVolumeLimit *= 750 @packedVolumeLimit ^= :\.\d+:: } } @PART[*]:HAS[#title[*ervice??ank*],!MODULE[ModuleInventoryPart]] :LAST { MODULE { name = ModuleInventoryPart InventorySlots = #$../mass$ @InventorySlots *= 4 @InventorySlots ^= :\.\d+:: packedVolumeLimit = #$../mass$ @packedVolumeLimit *= 150 @packedVolumeLimit ^= :\.\d+:: } } @PART[*]:HAS[#title[*dapter??ank*],!MODULE[ModuleInventoryPart]] :LAST { MODULE { name = ModuleInventoryPart InventorySlots = #$../mass$ @InventorySlots *= 3 @InventorySlots ^= :\.\d+:: packedVolumeLimit = #$../mass$ @packedVolumeLimit *= 75 @packedVolumeLimit ^= :\.\d+:: } } @PART[*]:HAS[@MODULE[ModuleInventoryPart]:HAS[#InventorySlots[0]]] :LAST { -MODULE[ModuleInventoryPart] { } } The first checks for parts which should be a "service module" and uses the mass as calculation base. The second is a sanity check, if the part's mass is so low that after the calculation and regex the value of InventorySlots is 0 just remove the whole ModuleInventoryPart again ... My first check: It did this to bluedog_Apollo_Block2_SM MODULE { name = ModuleInventoryPart InventorySlots = 2 packedVolumeLimit = 75 } and bluedog_Apollo_Block3_SM gets MODULE { name = ModuleInventoryPart InventorySlots = 1 packedVolumeLimit = 56 } bluedog_Gemini_ArrowSM gets MODULE { name = ModuleInventoryPart InventorySlots = 2 packedVolumeLimit = 75 } Those inventory slots are good for putting EVA repair kits or such.

The easiest way is to let the mod create the GameData\partVolumes.cfg then quit, move the folder GameData\KSP_PartVolume out of GameData and if existing, also remove GameData\KerbalInventoryForAll\AllowModPartsInStock.cfg As long as no part mods are added, the GameData\partVolumes.cfg alone is good enough. Removing part mods is no issue, because the patches for those parts are ignored then.

I guess the most important thing is the way Kerbalism handles science. There is a "Transfer Data here" button on any controllable part with a "HardDrive" when more than one part with a HardDrive is in the vessel - and a "HardDrive" can store data and/or samples in slots. There is a difficulty setting as well, to toggle the possibility to move samples automatically (by pressing that "Transfer Data here" button) or only when a scientist is on board. I suggest that Kerbalism's setting gets priority for the handling of samples. So the SM method of moving science should trigger the Kerbalism method (I don't know if there is an API for that @Gotmachine) and obey the Kerbalism difficulty setting,

What the? GameData\002_CommunityPartsTitles\Extras\CPTE_category_hide_cck_parts.cfg is just checking for all parts with any tag that contains *cck* and just changes the @category = none Why? Some people are using FilterExtensions. Here: https://github.com/yalov/CommunityPartsTitles/pull/11

Well, here are fixed configs, the archive only contains the changed files, so overwrite yours. btw even the LF / Ox ratio in the Hex and Octo core parts is not correct, for example 200 LF / 240 Ox (should be 244.44 Ox then, or 196.36 LF the other way around). So I also fixed that. https://www.dropbox.com/s/6w5pozz437mq47i/Universal Storage II (Kerbalism fixes).zip?dl=1 Edit: darn, there was a copy&paste-typo-error, please redownload

Hmm, the life support tank wedges got Mod specific patches in them (again, patches inside part configs...) - also for Kerbalism, and those are not balanced out against each other. For exampIe, on top of the already existing life support for 1d on my vessel I get 48d food vs. 32d oxygen vs. 82d water when I add same sized wedges. Adding the combined life support wedge I get 12d food, 8d oxygen and 7d water. Are those outdated Kerbalism values from back in the days?

How do you mean? Before, as fiddling? Or after, as fixing the issue? I guess the issue is because the heatshield clips into the pod with the actual node position and so the conduction is too high. Edit: Could­™ it be that only parts with ModuleConductionMultiplier are affected, besides the obvious clipping?

Minor? During reentry I was quick enough to enable the "ignore heat cheat" (which luckily is possible in pause menu) to avoid the death of 3 Kerbals, as the pod got hotter than the heatshield in a matter of seconds. Without DRE, without FAR, on JNSQ 10x.

see https://github.com/Kerbalism/Kerbalism/issues/790 I this related?

As I cannot access the inventory this way I don't know how to deploy ground science. Last year - before hiatus - I was able to move the view so much that I was able to righ-click the inside of the helmet to get the Kerbal's own PAW - this is not possible anymore.

For some reason the bluedog_LM_Ascent_Cockpit (LM Ascent Stage Cockpit) got food, water, scrubber, pressure - but no Oxygen at all. That makes no sense, after inspecting all the KerbalismConfig patches that should not be the case. see https://github.com/Kerbalism/Kerbalism/issues/789 solved by https://github.com/Kerbalism/Kerbalism/pull/771

Yep.

With Edge I cannot type a post at all, only title and tags and with the browser Pale Moon (which strictly follows W3C-rules and is my usual main browser for years now) the site is white background with text only. But at least I can post...

The best burn is the 6 months 1G burn. Afterwards enjoy the universe.

I know, but I don't have a "decent amount of RAM" - I got a semi-decent-potato-rig, no internal graphics, but still ... see the sig.

First experience: At Space Center, timewarping (KCT), as soon as sun is low and shadows are long the fps drop, compared to previous version. At noon or at night the fps increase. Checking the log I see that even in the Space Center the Mun and Minmus are loaded and unloaded by ScaledSpaceDemand - is this a new feature? The overall responsiveness/performance at the Space Center seems slower.

@Lisias ^is that so?

IMHO the feature "FlightSceneLoadKraken" from does the job very well on KSP 1.12.2, so WorldStabilizer is not needed, especially as it's not up to date.

The maneuver is 1 hour long and done with a Xenon Ion engine. Not sure if it's BBT or stock behaviour, but as the KER readout is correct I assume it's BBT: btw no matter if I created a maneuver node with more or less than this one, the BBT/stock readout always showed a burn time of "1d 3h".

My last hiatus made me lose some - but as I remember all those pesky transmission and signal issues have been solved? Or was it "new KSP patch, new issues"? This is relaying from Kerbin orbit to Mun orbit and back to DSN - on 10x JNSQ.

@Starwaster thank you. What is the role of pyrolysisLossFactor as it's not mentioned in the formula?

The parts inside GameData\DMagicOrbitalScience\UniversalStorageScience\ are all good, they got PART:NEEDS[UniversalStorage2] but the parts inside GameData\DMagicOrbitalScience\UniversalStorage\ don't. @DMagic And there are even a few duplicate folders and configs. Remnants of older versions? So, which of the both folders is "the real one"? That one that anyway got the correct PART:NEEDS[UniversalStorage2] and in all cases got the newer timestamp on the .cfg files - so "UniversalStorageScience"? The fact that the other folder got more subfolders and more configs confuses me. Are they all obsolete or still need to be updated? And last but not least: the fact that this is a case since August/September 2018 even confuses me more... Edit: I just recognized, inside GameData\DMagicOrbitalScience\UniversalStorage\ they all got TechRequired = Unresearcheable so they're obsolete for real. Edit: Not to be forgotten the fixes from https://github.com/7ranceaddic7/Orbital-Science