Starwaster

I agree, that's probably not the ideal solution and I think I actually experimented with something like that since posting about it. What I settled on locally was to patch the Progression node in the Contract.cfg, awarding an additioinal 16 rep in place of the 80,000 funds. There's also contract portion but I'm pretty sure it gets intercepted so I didn't bother with it (if you incorporate this then technically you don't need the NEEDS, but this went into my permanent repository of tweaks so I didn't want it applying in the event that I run without MB) @Contracts:NEEDS[MonthlyBudgets] { @Progression { @Funds { @BaseReward = 0 } @Reputation { @BaseReward = 32 } } }

Yeah, post processing effects is usually cheap enough that you can layer multiple PP passes and not have to worry about frame rate drops at all. High end games might even do 5-10 different post processing passes at a time since it's just using the already rendered scene.

What actually happens is that it was on the surface of the water and for a brief instant I can see it on the surface when switching to that vessel but then right before physics kicks in, KSP looks at the vessel's situation and if it says landed then it literally teleports it to the ocean floor. Which sucks because if a vessel is not the active vessel then it's not always possible to reliably determine if a vessel is 'on the water' or not.

This plugin allows for decouplers to animate when decoupling, or to animate before decoupling. It was created as a resource for other modders and players don't need to download this unless another mod requires it. This forum thread has been created as a landing page for support issues dealing with this plugin only. (should have done this a long time ago) YOU DO NOT NEED TO INSTALL THIS UNLESS ANOTHER MOD REQUIRES IT: Mods known to use Animated Decouplers: (if others are reported to me I will add them here) License: http://creativecommons.org/licenses/by-sa/4.0/

We should probably move this to private since this isn't really an SDHI issue... but the initial problem has ceased now, doesn't play the animation unbidden? Just decoupling without animating? Can you send me the files necessary to test that part? Edit: Decided at long last to create a landing page for Animated Decouplers that support issues can be directed to: @sumghai

They need to make the shopping cart wheel squeak then

Are... are those shopping cart wheels???

Turn off the pre-recovery option. It recovers Kerbals from parts that it thinks might be in danger of being destroyed by going off rails. Also, I too love using this to gather science with my mobile labs. I even hacked BonVoyage apart to allow amphibious travel with Lynx's boat propeller and hover jets, though it barely works and is currently more trouble than it's worth because it has to change the vessel situation on the fly. (apparently if a vessel is moved out over the water and it's not properly set to 'SPLASHED' and you switch to that vessel...? DOWN TO THE BOTTOM OF THE OCEAN and crushed like an egg shell by the pressure. Ooops.)

Unless it's also doing an unwanted decouple then there's nothing for me to do here. The module looks like it's doing what it's supposed to. That tiny log extract you posted indicates that it found the animations that you told it to look for. That's all. @almagnus1 yes.

Sounds like he's as bad as me. Well, probably not. NOBODY is as bad as me... I went so far as to recompile several mods back to 1.2.2 and implement localization before I came to accept I was expending more effort sticking with 1.2.2 than if I were to just bite the bullet and switch over. (I'm The Doctor, I'm worse than everyone's aunt!)

So they weren't really missing at all

Resilient little sucker...

Hey, space is a tough place, where wimps eat flaming plasma death. Sorry... couldn't resist throwing in some Star Control humor...

@Garlik BV is a little touchy about existing craft and BV module changes (including the addition of the module when there are craft in the field) If after adding the module, it does not appear on those craft, switch to them and quick save. Then reload the quick save. That usually does it for me

@Briso not just the log file, ModuleManager.ConfigCache too. And it looks more like you broke something or didn't install something properly or didn't install the right things than anything else.

'Incompatible Mods Detected' just means that there is a mismatch between the version of KSP and the version of KSP that the mod reports it is for. So either you are using the wrong version of Real Fuels OR someone forgot to update the compatibility checker code in Real Fuels when rebuilding it. For KSP 1.3.1, THIS is what you should be using: https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v12.4.1 - I know for a fact that it is built for KSP 1.3.1 in spite of any compatibility warnings.

Real Chute creates a category for parachutes. It sets the category to none in the config file to prevent chutes from showing up twice. If one of your other mods is doing something with PartCategorizer in a way that prevents RC from creating is category or deleting it then RC chutes won't appear at all.

Those got removed because people were having trouble with them and the mod author couldn't get them working... I guess?

There are inline drone cores

No, as stated above, patches that specify AFTER and BEFORE will fail if the mod doesn't exist. Either it has to have a folder by that modname directly off of the GameData folder, a plugin by that modname or :FOR[modname]. Incidentally, that last is why you NEVER use :FOR if it's not your mod. It will cause conditional :NEEDS to pass which can be problematic if the mod isn't really installed. For example, heat shields have to be configured properly if RealSolarSystem is installed. Deadly Reentry does that automatically for RSS or other upscaled star systems IFF RealismOverhaul is NOT installed because RO takes care of heat shield configuration itself. So let's say some other modder decides to specify :FOR[RealismOverhaul]. But let's say RealismOverhaul is NOT really installed. But now MM fails to apply DR's patches because the :NEEDS[!RealismOverhaul] fails because of the illicit use of FOR. Players NOT using RealismOverhaul no longer have adequate protection for their upscaled non-RSS heat shield. It explodes spectacularly and the player has no idea why.

:NEEDS does not imply any pass whatsoever. It's just a condition for the patch to be applied. Standard pass determination applies. Ordering is as follows :FIRST legacy (cannot be assigned manually; this is the pass a patch falls into if no specific pass was specified) Then, each modname is gone through in alphabetical order and BEFORE/FOR/AFTER passes are done for each one. (if a mod is not present by GameData/foldername, plugin name or does not have a :FOR[modname] then BEFORE and AFTER patches for that mod will not be applied) :BEFORE[modname] :FOR[modname] (do not use this if it is not your mod. EVER. It will fulfill :NEEDS[modname] even if the mod isn't really installed) :AFTER[modname] :FINAL (don't use this as a modder. It is reserved for the end user so they can have ultimate control over their game)

Some thoughts: It sounds like you're using a scaled up star system so you are probably looking at the wrong configs. There are a set just for scaled up systems: https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/DeadlyReentry_AlternateStarSystems.cfg (these almost universally assume a Real Solar System or Kerbol x10 sized system) pyrolysis loss = pyrolysisLossFactor * ablator resource hsp value. It is the amount of flux removed from the shield per ton of shield ablated. (the amount actually ablated is on the order of kilograms/second) The amount of material lost per second is lossConst * EXP(lossExp / skinTemperature) * resource maxAmount * resourceDensity lossExp should be negative because of the way it gets applied. If it's positive then your shield will probably use up ablator at a faster rate than you want. ModuleHeatShield is an extension of the stock ModuleAblator. It allows for the heat shield to have different (lower) max temperature ratings when the shield is depleted. The first point is probably most important, if you want to skip figuring out the formula (though it is simple and lends itself to being used in a spreadsheet easily) just look at how the scaled up system shields are configured. They do work (though I also do feel that more intuitive settings are possible) Be sure that your shield's conductivity is low enough to prevent heat from bleeding through and I set up ModuleHeatShield to allow normal conductivity to be applied when it is depleted.

Something in this new update is introducing a lot of visual noise or static in flight and map scenes. I'd turn it off if I knew which feature was causing it....

Go into settings (from Main Menu, not while having a game loaded up. Exit to Main Menu if needed) and under Gameplay look for something that says Display Earth Time and click on the bubble next to that. It's under Gameplay and is the third option down. You want it to be filled in green. (and then it won't say Earth Time anymore; it's potentially confusing because it changes the menu option to say Display Kerbin Time because that's what it will do if you uncheck it... toggle menu display text should NOT change when clicked and it's the only thing on the menu that does) So in summary, when you go in the menu it looks like this Once you're done it should look like this: Once your saved game is loaded up, check the settings for Monthly Budget and make sure that it's set how you want. Edit: It looks like it actually use double the interval that you set in the MB section; I had to set it to 15 days to get a 'monthly' budget. (maybe that's some quirk of using Earth time; not sure why it does that, but 15 days is what I had to go with)

I've got 34 KSP installations to choose from dating as far back as KSP 0.23.... (some are duplicates for development purposes of various mod combinations)