klyith

Proton v8 is somewhat nicer that Proton v9 on my machine, but that also may be GPU dependent. (I've got an AMD.) Here's what I got as a fix: //remove mach effects in normal atmospheres @PHYSICSGLOBALS:FINAL { @aeroFXMachFXFadeStart = 1.55 @aeroFXMachFXFadeEnd = 1.5 } Save that as a .cfg file in your gamedata. This makes the mach aero effects not exist until above 1.5 atmospheres pressure. AFAIK those are purely visual effects, and this won't change anything about the aerodynamics model (mach drag etc). It's not perfect: there's still a moment of the ugly bugged mach effect that plays after the thermal effect stops, no matter where you are in the atmosphere. Oh well. I'll deal with it to have the sweet firefly re-entry. I bet someone who knows more than me about shaders could turn off the mach effect entirely -- I think Shabby has the ability to change shaders out.

Turns out the fault for my problem on the previous page is because I am on linux, running the windows version of the game through steam proton. Firefly is working fine, no errors in logs. Changing to proton version 8 produces a very pretty butterfly wings effect! Running the mod on the linux version of KSP has no bad effects, everything appears as it should. Sadly, the linux version is pretty crappy in a couple other areas. So, uh... if you want to fix this, I'm available for whatever testing or stick-poking you need! I know jack squat about shaders though so I'm useless at anything more than that. But I also totally understand if this is a "lol not my problem" situation.

I have a wack issue, reentry effects work great but the mach effects look like this: Is this a thing you've seen in testing before? I can start doing the mod compatibility mambo if it's not a known problem. As I understand it KSP uses the graphical shaders to calculate which parts are being exposed to reentry heating. My guess would be that the BDB parts, since they're fit so closely together, are now exposing the capsule to heat. Compare to stock parts, where the heatshield sticks out a bit around the rim to insure that the capsule doesn't get hit by the effect.

After a lot more experimenting, and a whole lot of waiting for load times, I think I have a decent answer. You're definitely right about the fade stuff -- seeing a sunflare through the planet isn't ideal! It's a combination of parallax being tuned for stock scale, and the person who did the JNSQ patches for Parallax not doing anything to help things. I was focused too much on JNSQ because I used to play at 2.5x Rescale, and it was pretty much just like stock fo Parallax. So I figured it had to be a JNSQ thing that was "wrong". But the way rescale works seems to automatically rescale the Parallax maps as well. So anyways, here's my results for making things look better: #1 is to rescale parallax textures larger, which I think looks better all around (not so crisp and bumpy, can't see the repeating tiles) // rescale parallax @Parallax:FINAL { @Body[Kerbin] { @Textures { @_SurfaceTextureScale = 2.5 @_displacement_scale = 0.39 @_displacement_offset = 0.09 } } } #2 is to shift the PQS fade to a spot that matches when Parallax is less prominent. I have two options: a: this is what I'm using @Kopernicus:FINAL { @Body[Kerbin] { @ScaledVersion { %fadeStart = 70000 %fadeEnd = 80000 } @PQS { %fadeStart = 77000 %fadeEnd = 88000 } } } b: This looks better in orbit, but my GPU (6700XT) can't handle it. Clouds stay high-detail until you get out of PQS, and looking down at Kerbin from 125km was pushing me under 30fps. If you have a good GPU use this. @Kopernicus:FINAL { @Body[Kerbin] { @ScaledVersion { %fadeStart = 100000 %fadeEnd = 110000 } @PQS { %fadeStart = 110000 %fadeEnd = 130000 %deactivateAltitude = 135000 } } } Both of these use :FINAL which is not good practice normally, if anyone else picks this up to incorporate into some mod patch.

I've written a new feature for myself where recovery distance from KSC gives a bonus/penalty to R&R time. (In my headcannon there's no way a Kerbal isn't ready to go back to space the next day. But I can imagine them getting very distracted on a trip home from halfway around the planet. Plus I need a reason to make mid-tech spaceplanes and lifting bodies in JNSQ.) Is this something that you'd be interested in LGG? Right now it's very basic, hardcoded and always on. If this is a thing you're like to incorporate I can work on settings / customization and make it respectable. StarDagger: You might want to look at the optional 'Stress' component of the Snacks life support mod. Kerbals on missions build up stress, when totally stressed out they lose all skills. They can remove stress on a ship/station with plenty of living space, big windows, etc. So in your Minmus operations you'd need to bring Kerbals back to the station every so often to recover, and rotate fresh crew to your other ships. Everything in this mod works based on the KSC part of the game, not vessels / crew in flight. So your feature, while it fits in concept, would be pretty much an entirely new mod to write.

Ok, but why? I can see the reason for Kopernicus saying to keep them the same -- the stock planets are probably set that way, because you're fading between the two systems. And doing it that way makes your planets look bad with Parallax, which I think most people want to have these days. So even if it looks slightly better in the otherwise-stock game, it looks crappy in the modset that pretty much everyone uses.

RE: ocean disappearing and showing parallax bump maps Problem is not actually caused by this mod, it's in base JNSQ. They have PQS and ScaledVersion fade at different altitudes, while Kopernicus specifically says these should be the same. My guess is that this doesn't show up in the "standard" JNSQ because the older version of Scatterer covers it? Here is a MM patch that fixes it for me: @Kopernicus:LAST[JNSQ] { @Body[Kerbin] { @Ocean { %Material { %fadeEnd = 60000 } } @ScaledVersion { %fadeStart = 120000 %fadeEnd = 140000 } @PQS { %fadeStart = 120000 %fadeEnd = 140000 } } } (The PQS -> ScaledVersion change being that high might be a performance issue for some people? I think it made ~100km a little worse for me. Don't care I like pretty. If things get choppy in low kerbin orbit you could try dropping those numbers to put the transition below your normal orbit height.)

Bug report for the SnackResourceSwitcher module: the resources from the first option are still added to the subsequent options, unless the subsequent option has the same resource type. So on the Snack Tins, snacks are still added even if you set them to soil only. A more complete example: This set of options will produce FuelTank = LiquidFuel 3240 / Oxidizer 3960 (correct) mega snack: LiquidFuel 3240 / Oxidizer 3960 / Snacks 7200 (wrong) Oxidizer Only: LiquidFuel 3240 / Oxidizer 7200 (wrong)

This. You can save that information, it would not be difficult. And the default should be that no information is collected without the user saying yes. A data collection plugin should be surfaced to average users, not just the ones who read forums and license files. I'm not against your concept, though I'm pretty ambivalent about it being a 3rd party initiative rather than an official Squad thing. But you really should not be doing it opt-out and silently.

For anyone else who wants a slightly more interesting / distinctive button for the toolbar, I made these: (cybutek feel free to use them if you like)

The new version of MuMechLib introduced with FixedCamera has made a bug with the servo setup UI. If you create or load a ship with servo groups, they stick in the setup window when you make a new ship or load a different one. It doesn\'t clear until you fully restart ksp. If you load the second ship (already set up), it doesn\'t affect the control screen when you launch. So as long as you only want to design one mecha ship per time you launch the game, it\'s cosmetic...