EthanKerbman

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.

Some of the engines are passable, but the Whiplash and Panthers, nope, they sound nothing like what they are trying to depict, they are closer to 50's era jets than anything they're supposed to be. Yes, they sound fine if your only reference point is jets taxiing at relatively close range or some static engine tests, but in reality the whine is quickly covered by the growl, even once you take into account the doppler effect. And in Afterburner, yeah, the whine is the least of your worries. Moreover, the whine fades fairly quickly with distance, meaning that viewing your craft it shouldn't be predominant, likewise, from the inside, between the sound transmitted through the structure and the doppler effect, the whine is fairly different and attenuated compared to an observer outside. That's where the sound fail, it takes a very specific case and makes it the general case.

1) The new EULA are utterly ridiculous and most likely unenforceable in some of the saner parts of the world (as most EULAs really, it mostly relies on the fact that it would be prohibitive to challenge them). 2) There's no added DRM (yet). 3) The new jet engine sounds are an unmitigated disaster (unless you consider your viewpoint to be at short range and the engines somehow being at low regime and relatively static to be normal). 4) The game works fine by selectively using the 1.3.1 parts with the 1.4.0 code, making transition require little work (you will want to keep the "new" Cargo and Service Bays, as well as Internal configs though, all other parts can be replaced by their old version without adverse effect in sandbox mode so far), however, as pointed by RoverDude, older parts are hidden but present, thus not breaking crafts (the reason why new/modified parts have new names) making it unnecessary (except for weirdos like me who want to try it). 5) Stock performances have improved a bit. 6) Personal parachutes are great. Now to try and migrate my circa 300 mods install... (and enough core mods are broken or not working properly for me to stay on 1.3.1 for the time being, I'm usually 1 to 2 version back anyway.)

Fairly rare and innocuous, it was atrocious at some point but, after culling and modding a few mods, things ended up quite usable considering the monster of an installation that it is (and the number of exceptions still thrown despite my best efforts). However it does tend to crash when missions start getting too long (depending on the vessel complexity and neighbouring vessels). I'm not complaining, I've had much worse and with worse framerate. Lately I'm mostly on a purely aero trip, finished a whole WW1 era and going into WW2. (Relevant because that means I've not explored the whole physics since my last round of tinkering.) I used to use a mod that supposedly tried to help with GC, but after extensive testing it and tweaking, it only made things worse for my specific case.