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.

KSP 1.3 (not touching 1.3.1 yet, not all mods have updated and even when they do, it takes me month to validate my whole install), 18GB out of 32GB at launch (the most I've reached in play is about 26GB IIRC), about 310 mods installed at the last count (plus quite a few custom patches) for close to 7GB of Gamedata, takes about 22mn to load (on a fast system, on NVMe SSDs), up to 1mn to change scene under certain circumstances, but otherwise fluid enough, stable and with no jerkiness. So... What did I win ?

No trouble, I like this kind of tedious fun... the "funny" undisclosed end of the story is that after all that work, my seaplane still doesn't take off, but now I'm entirely sure it's the design's fault.

TL;DR : In OPT Legacy, k_oms is somehow bugged and interferes game-wide with, apparently, water physics (don't ask me how and why), commenting out ModuleAnimateGeneric and ModuleCargoBay on it is the only cure I've found yet. Let me tell you a little tale : Once upon a time, a brave soul wanted to design a seaplane, but no matter what he did, clever geometry, cunning aerodynamics, overwhelming thrust, no design would reach a speed allowing it to leave Kerbin bright blue waters. The curious little designer then turned to his wise ancestors for guidance and took a look at how Squad's seaplanes were designed and was surprised to find out that they suffered from the exact same problem, he then embarked on a journey to find which of his 350+ installed mods broke seaplanes. Very long story short, after a few dozen hours (testing each mod individually, testing interactions, testing individual files), I've pinpointed it to two culprits on my install, one being OPT Legacy's k_oms part (the solid one), specifically the ModuleAnimateGeneric and ModuleCargoBay Modules. I first thought it was only due to the referred to nodes being commented out, but that didn't fix the problem, I had to comment out both modules to fix the problem. How that fixes a game-wide problem affecting planes not using this part, I have no clue (yet), but I've now tested it dozens of time, with the same result. With these two modules active on k_oms, Squad's Gull's maximum speed in water is around 22m/s, not enough for take-off, without them, it's about 42m/s, with take-off possible starting from 30m/s. For the curious, the other culprit was SM Marine's HeliDeckDecal, limiting the Gull to 26m/s, seemed somehow linked to ModuleAnimateGeneric too, but I'd had enough of testing done for the month so since I didn't use the part, I just deactivated it.

Of course, because it's meant to apply to others mods so they use the revamp models instead of stock ones.

@evileye.x, TL;DR : NEEDS is to control for a dependency, FOR, BEFORE and AFTER to enforce an order of execution. No, FOR is not an alias for NEEDS, it's only there (in this case) to ensure it executes after most other patches, because when there is a FOR clause, they are executed in alphabetical order (FOR also serves to control the order, with BEFORE being executed first, then FOR, then AFTER). For instance, if you have a BEFORE[zzzVSRPathPatch] patch, it will execute before the FOR[zzzVSRPathPatch]. Likewise an AFTER[zzzVSRPathPatch] will execute after FOR[zzzVSRPathPatch]. Finally, if there was a patch name declared as yyyVSRPathPatch for example, the BEFORE[yyyVSRPathPatch], FOR[yyyVSRPathPatch] and AFTER[yyyVSRPathPatch] patches would execute before any of the zzzVSRPathPatch ones, because they are before it in alphabetical order.

@evileye.x, it's meant to replace any duplicate (either standalone or as part of a composite part) of the stock part by its VSR variant.

Here, FTFY @PART[b2_4m_adaptor_variant] { MODULE { name = FStextureSwitch2 textureNames = OPT_Legacy/Parts/Stail/texture_ij_4m_adaptor;OPT_Legacy/Textures_Legacy/texture_ij_4m_adaptor_alt_n objectNames = ij_4m_adaptor textureDisplayNames = Original;Night statusText = Current Texture showPreviousButton = false } } @PART[b2_adaptor] { MODULE { name = FStextureSwitch2 textureNames = OPT_Legacy/Parts/Stail/texture_ij_4m_adaptor_alt;OPT_Legacy/Textures_Legacy/texture_ij_4m_adaptor_n objectNames = IJ4mTRI.001;IJ4mTRI textureDisplayNames = Original;Night statusText = Current Texture showPreviousButton = false } } @PART[b_2m_bicoupler] { MODULE { name = FStextureSwitch2 textureNames = OPT_Legacy/Parts/Stail/texture_j_2m_bicoupler;OPT_Legacy/Textures_Legacy/texture_j_2m_bicoupler objectNames = j_bicoupler textureDisplayNames = Original;Night statusText = Current Texture showPreviousButton = false } } The bicoupler was referencing the wrong texture, one of the adaptors was referencing the wrong object and texture, and the other was missing its entry entirely.

Actually I meant 1.2.1, I just forgot which was the latest and looked at OP rather than the mod, hence the mistake. So yeah 1.2.1 doesn't work. The really good thing about this mod is that adding new patches was drag and drop, you just put your flags in the right folder and you could use them rather than having to add them to the CFG.

Keep in mind that Scatterer is somewhat buggy with 1.3 as of now (you have to deactivate the ocean shaders to avoid an annoying glitch that makes terrain tile float around or disappear). There are currently 3 major visual overhauls : - Stock Visual Enhancements + Stock Visual Terrain, which is the most basic and the most RAM friendly (with all options, a stock x64 install consumes about 2GB idle). - Astronomer's Visual Pack, which is the oldest of the bunch, it has some effects that are not as good or subtle as the other two, but it's still quite nice, however it isn't RAM friendly (with all options, a stock x64 install consumes about 4.8GB idle). - Andromeda Visuals Daydream, which is the newest, has some of the nicest and most subtle effects and it comes at a similar RAM cost as Astronomer's Visual Pack (5.0GB idle, which is within the margin of error). My take on things is that if you run a lot of mods (I run about 350 lately, consuming about 15GB idle, 24GB peak so far) and/or are limited in CPU/RAM, SVE+SVT is a good way to have nicer visuals without overtaxing your system and losing too many FPS. If you can afford to go toward something nicer, I'd take Andromeda instead of Astronomer's, it's about as taxing for your system and it has the benefits of being, as of now, the better looking one.

For those wondering, v1.2.0 crashes on load with KSP 1.3.0