EthanKerbman

May I suggest a way to do away with the need for a blacklist in PEAR ? The issue is that both static and animated solar panels use ModuleDeployableSolarPanel, so there's a NRE when "deploying" static panels, hence the original dev adding a blacklist to prevent this explicitly for parts in the blacklist, right ? But considering static panels can usually1 be distinguished from animated ones by the lack of an animationName key, that could be easily achieved automatically by a small change in the pear4solarpanels.cfg patch; instead of : @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]] { MODULE { name = PearPowerController } MODULE { name = PearModule } @MODULE[ModuleDeployableSolarPanel] { @retractable = true } } using @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#animationName]] { MODULE { name = PearPowerController } MODULE { name = PearModule } @MODULE[ModuleDeployableSolarPanel] { @retractable = true } } should only add PEAR to parts with animated solar panels. This could allow for removing the blacklist and related code entirely, making it slightly easier to maintain for both you and the end users who won't have to add to the blacklist any more. 1: I have so far found only one exception to this, the hexagonal static panel in SXT (SXTsolarPanelhex), but having only one part being problematic due to not being properly configured is somewhat better than the current situation.

Yeah, figured as much, thanks for helping fix a potential headache that shouldn't be yours to fix.

There seems to be an issue in the Tankage part with MetalOre storage when used alongside Simple Construction. I'd suggest a simple change to B9PS_DrumTankOptions.cfg : SUBTYPE:NEEDS[Launchpad] { name = MetalOre title = #EL_MetalOre_displayName primaryColor = BrownishGrey secondaryColor = BrownishGrey RESOURCE { name = MetalOre unitsPerVolume = 1 } } into SUBTYPE:NEEDS[Launchpad&!SimpleConstruction] { name = MetalOre title = #EL_MetalOre_displayName primaryColor = BrownishGrey secondaryColor = BrownishGrey RESOURCE { name = MetalOre unitsPerVolume = 1 } }

No, no, thank you, you work fast as always and without your continuous efforts this game wouldn't be what it is, or lurkers like me would have to *gasp of shock and horror* put more work into it themselves, and we can't have that, can we ?

It's not mod specific, you can edit any stock part and it will do the same, I happened upon that one while integrating MAD/MoS into my 1.11.2 save, but that's only the trigger for it; as I said, I've tested it with other parts, ANY part will do that, it's the lack of a comma that makes it fail less than gracefully, not a specific mod. But hey, here's the relevant part of a log from a minimalist install (KSP 1.11.2, Module Manage 4.1.4, ClickThroughBlocker 0.1.10.15, ToolbarControl 0.1.9.4, Janitor's Closet 0.3.7.6 and SpaceTuxLibrary 0.0.6.0) with the stock aerodynamicNoseCone edited to trigger the bug. [EXC 17:21:00.660] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) JanitorsCloset.ModFilterWindow+PartInfo..ctor (AvailablePart part) (at <e283773f1a5a4cf79933af77639d96cb>:0) JanitorsCloset.ModFilterWindow.InitialPartsScan (System.Collections.Generic.List`1[T] loadedParts) (at <e283773f1a5a4cf79933af77639d96cb>:0) JanitorsCloset.ModFilterWindow.InitData () (at <e283773f1a5a4cf79933af77639d96cb>:0) JanitorsCloset.ModFilterWindow.Start () (at <e283773f1a5a4cf79933af77639d96cb>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) P.S. : And yes, that's the only relevant part, I've checked against the log for the same install without the edit and loading correctly, the rest is utterly irrelevant, mostly timestamp differences and MM cache related shenanigans that I already checked.

In case some people want to know, it still mostly works with 1.11.2, however if you intend to use it on an install with Janitor's Closet, be sure to edit 3 files : /MoS/MAD/Parts/Aero/MoSNoseIntake1.cfg /MoS/MAD/Parts/Aero/SpineIntakeMid.cfg /MoS/MAD/Parts/Aero/SpineIntakeSmall.cfg to add a comma (,) between the different bulkheadProfiles definition or you will have an editor bug You might also want to edit /MoS/MAD/Parts/Aero/MoSCone1.cfg to update the texture path of the MODEL, as the correct paths are Squad/Parts/Aero/cones/Assets/Cones Squad/Parts/Aero/cones/Assets/Cones_Heat the original files missed the "/Assets" part of the path.

I've found an "interesting" "bug" with Janitor's Closet while tracking something weird it did. Consider a part with a malformed bulkheadProfiles declaration, missing a comma between different profiles (eg. "bulkheadProfiles = size0 srf" instead of "bulkheadProfiles = size0, srf"); while the base game will just ignore those after the first and work fine otherwise, if Janitor's Closet (at least the latest) is present, then JC's windows will spawn in the top left portion of the screen in reduced size on editor scene load and no part (including Squad) starting from the first part with that typo will be shown in the SPH/VAB and no mod will be shown in JC's filter list beyond the mod with the first offending part. It's not a bug per se as the problem is not truly with JC, but it still doesn't fail cleanly in that situation. Took me quite some time to figure as I kept missing the damn missing comma. It seems "new" as the same malformed statement from the same mod didn't trigger that bug in 1.9.1.

It seems that Tetraflon's latest B9 pWings fork (https://github.com/tetraflon/B9-PWings-Modified), the 0.42, loads without issues (haven't tested the functionality yet).

Aaaaand the winner is... MechJeb... Whenever MechJeb (2.12.0.0) and B9 pWings (latest) are installed together, the incompatibility message pops up and the loading stalls, remove one or the other and everything works fine. Should have known, that is an old issue but it was solved in 1.9.1 at some point, but seems it reappeared since. FAR used to have the same problem, but I don't use it.

Actually, I'm in the process of moving/adapting my long term game from 1.9.1 to 1.11.2 and it DOES work (as in it loads, you can build wings and they seem to have the right weight, lift and drag), until you run some other mod along and suddenly you get this compatibility warning and a loading stall. Unfortunately I installed B9 pWings late in a 300+ mods install, so I validated that it works in a minimal install but haven't had the time yet to find in the logs or through trials and errors which mod triggers that behaviour. If your install is a bit less ridiculous than mine, you might more easily identify the culprit as it is not stricto sensu B9 pWings that is the issue.

The problem seems to be in the ModuleDeployableSolarPanel (as in the MKS Sunflower), just commenting that module allows that part, and the game, to load normally (minus the solar panel functionality on the part of course). There seems to be a transform problem, but I stupidly didn't keep the log when it finally logged and so far it stops before logging the error again (then again, because of that logging problem, it might not be the transform error that freezes the game, but the one after that that isn't logged before the game freezes), I'll post the relevant info as soon as I get it again.

Is there any way to get this to work without TU or at least to have TU render things stockalike for those of us without magpie ancestry ? Never mind, I'll use the old models, you already answered that a few pages back, sorry.

Two words verdict on the DLC : Meh, underwhelming. @sjwt the value and context suggest that GBP is meant to be Great Britain Pound (£).

With a quick glance, they're gone, they've been replaced by new versions with the same name, in both game version they're not accessible as WAV files, but are packaged in shared asset files.

The Panther is meant to be a F404 analogue, a late 70's/80's engine design. The Whiplash is a modern take on the J58, itself a 60's design, but the Whiplash performances make it unlikely to be anything other than at least a late 80's tech (of course it's a game and the lore might be different but if we were to draw a parallel with real engines). Let me elaborate (we'll disregard IVA and doppler effect to tackle only problem at a time). In the real world, as the distance between the observer and the engine increases, the high frequencies become quickly less present, until they're not heard anymore, the low frequencies can be heard from further away. You quickly lose the hoovering whine and hear the low rumble of exhaust from a longer distance. In KSP, as the distance between the observer and the engine increases, the sound level of both components (whine and rumble) fade away equally, but since the whine volume is higher than the rumble, there's a distance where the rumble (yes, the rumble of many jets is still quite high pitched) almost disappears and the whine is still present, exactly the reverse of what should happen in reality. This was already the case in previous versions, but 1.4.0 made the whine more predominant and annoying, making the problem much more noticeable than previously. So while the sounds are "accurate-ish" from the perspective of someone close to a jet taxiing, starting its take-off dry or looking at an engine testbed, they are wildly inaccurate and inappropriate for engine mounted on an actual craft, flying, seen from either a distance or from the cockpit, which will be your points of view most of the time. If you want to understand the problem, look at : Take note how the sound evolves with the distance and engine regime. 0:18, that's how 1.4.0 engines sound, it's fine for that part... 1:26 notice how fast the whine fades away with distance (the speed isn't enough for the Doppler effect to be a major factor)... 2:14 where is the whine gone ? My problem is not that the sound modelling is simplistic, but that the sound they've chosen as their basis is not accurate for a craft in flight, seen from a distance, as will be the case for 90% of the time we'll be using these engines. Also, keep in mind that most of the videos you will find (including the example above) are not entirely representative of how engines sound because of the limitations of the recording equipment and audio codecs (and to a lower degree the player side of things), missing components both in the high and low frequencies.