• Content Count

  • Joined

  • Last visited

Community Reputation

21 Excellent

About EthanKerbman

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Two words verdict on the DLC : Meh, underwhelming. @sjwt the value and context suggest that GBP is meant to be Great Britain Pound (£).
  2. 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.
  3. 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.
  4. 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.
  5. 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.)
  6. EthanKerbman

    whats your RAM usage? lol

    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.
  7. EthanKerbman

    whats your RAM usage? lol

    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 ?
  8. 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.
  9. 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.
  10. Of course, because it's meant to apply to others mods so they use the revamp models instead of stock ones.
  11. @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.
  12. @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.
  13. 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.
  14. EthanKerbman

    [1.2] Mission Patch Manager v1.2.0 - 15th September 2016

    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.
  15. 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.