Starwaster

Decided not to risk the sammich. You have both Real Fuels And Modular Fuel Tanks installed - Looks like the MFT defs are overriding the RF defs. Delete MFT

@AdmiralTigerclaw No logs, no ModuleManager.ConfigCache, not even a tasty sammich by way of incentive.... Need at least two of those three.

What you're doing wrong is not ignoring that message. It's only happening because someone didn't designate that RF is compatible with KSP 1.3.1 - the compatibility checker only KNOWS RF is compatible with a given version because we told it so: https://github.com/NathanKell/ModularFuelSystem/blob/rf-v12.4.1/Source/assembly/Checkers.cs#L67

Make sure you have the most recent Smokescreen

Are you able to translate those without angular momentum being introduced?

@StickyScissors @Shadowmage Having trouble with docking then give this a try please (assuming KSP 1.3.1) https://www.dropbox.com/s/9swbqvqrhxfjptq/MechJeb2.dll?dl=1 Added another safeguard to move away from the dock if it's too close and hasn't yet lined up.

I use this on the landers @Jasseji @PART[SSTU-LC2-POD|SSTU_LanderCore_LC3-POD|SSTU_LanderCore_LC5-POD] { @node_stack_top[1] -= 0.13796 !MODEL,1{} !MODULE[ModuleDockingNode]{} !MODULE[SSTUAnimateControlled]{} !MODULE[SSTUAnimateLight],0{} }

Like we used to?

I kind of like the current music regardless of where it's from.

Not seeing any pictures at all @ToxicSerum Just got to be careful when driving that you don't go too fast. Let go of the key when that happens. You also have reaction wheels so use SAS to try to keep it stable on low G worlds. Maybe think about adding RCS. That would help you keep upright and might be enough (MIGHT) to right the rover on low G worlds. If you use Realism Overhaul it also helps to use the center of mass shifter to lower its center of mass. I do that once I've landed it on a world using the following config. (bind it to an action group so you can shift the mass when it's not going to be on a rocket stack anymore) Be warned that this config is old, like KSP 1.2.2 old so there's new parts that are not part of this config. IIRC I shifted the mass about halfway between the current center of mass and the wheel attach nodes where it logically would be with mechanical parts and what not. My assumption is that when it's in default mode, some mass is redistributed to make it stable when on a vertical rocket stack and once it's on the ground, the Kerbals have to move and install things like furnishings or batteries or maybe ballast or something... yeah, ballast. Let's go with that one. @PART[Lynx_Cockpit|Lynx_FuelTankBig|Lynx_FuelTankRear|Lynx_FuelTankSmall|Lynx_CargoBay_Big|Lynx_CargoBay_Small|Lynx_FlatbedBig|Lynx_FlatbedSmall|Lynx_FreightBig|Lynx_FreightSmall|Lynx_ServiceBay|Lynx_MobileLab|Lynx_CrewCabin]:NEEDS[RealismOverhaul] { MODULE { name = CoMShifter DescentModeCoM = 0.0, 0.0, 0.625 } }

Have you counted all the doors on the VAB? Count them again... it will change your life...

@severedsolo So, this isn't a big deal I guess, more of a minor inconvenience but budget time is rolling around and I'm trying to run my existing budget into the ground so I don't get penalized when I suddenly hit a milestone... a speed record. And I got a payout which I guess the contract interceptor can't do anything about since it's not technically a contract. One way of dealing with it would be to hook into GameEvents.Modifiers.OnCurrencyModifierQuery and switch the funds for some rep. I've tested that and it works but the displayed message is constructed before the award actually is made so it still displays that funds were awarded. Another way would be to change the BaseReward values in the FinePrint.ContractDefs. There's a few dozen of them but I think only Progression would matter since the others end up being contracts that get intercepted? If you're interested, let me know and we can discuss it further.

It wouldn't even have to be a TARDIS.... it might just be a common police box that somehow mysteriously appears at the KSC... and then just as mysteriously vanishes

@Tonas1997 Well there's a few things you can do about cost. You can edit baseCostPV (base cost per volume) in RealSettings.cfg For resources you can patch the unitCost of each RESOURCE_DEFINITION You can also patch the individual TANK nodes inside each TANK_DEFINITION (RealTankTypes.cfg in RealFuels/Resources) and add a cost to each one. (that's tank cost per volume - currently unused)

I was scratching my head over that... what was it supposed to be before autocorrect?

Do you mean the tank price or the resources? And just how many Funds do you think they should cost? You do realize that the 'Fund' is an arbitrary unit and is intentionally kept small so as not to inundate the player with unwieldy numbers? If you're thinking that a Fund is something like a dollar or some other real world unit of currency then yeah - 150K is too cheap. Except that a Fund is NOT a dollar; I think it's something like 1 Fund = $1000 but it could also be higher. (I think it might be higher for RO or RP0). Those conversions would be in 1965 USD which is about the right time period for most of the technology involved. If thinking in modern terms (adjusting for inflation) then a 'fund' is worth much more (6k-7k USD) So if you adjust your thinking to take into account those numbers then 150K is not that unreasonable. And I would look at adjusting other parts before touching the tanks or the resources anyway. (things like engines)

I have another suggestion: Instead of letting KSP deduct funds for failure, how about intercepting that too and then deducting those funds from the next budget?

Anyone using alternately sized star systems should re-download the file DeadlyReentry-AlternateStarSystems.cfg and copy it over the existing file in the DeadlyReentry folder. Otherwise certain shields will NOT ablate. This bug does NOT affect Realism Overhaul as its configs only go into effect in the absence of Realism Overhaul. https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry_AlternateStarSystems.cfg

Yeah, I helped design the early prototypes for 'pose balls' in Second Life and look how widely those are used. And in things people make money off of! Didn't see that coming...

Realistically speaking, yes, running propellant through it would produce thrust. (don't call it fuel. The fuel is the radioactive isotopes in the reactor) Some NERVA documents even discuss this and called for minimum levels of thrust / Isp when operating under cooldown thrust. But for a game, would you really want go there? Where both throttle up and throttle down times are up to ten minutes or (possibly) even more?

The only real effect that RF has on IntakeAir (as far as the definition goes) is to change its density You can easily undo that change with the following patch @RESOURCE_DEFINITION[IntakeAir]:FINAL { @density = 0.005 } I'm assuming this is for your personal use rather than for a mod so I used :FINAL If this is going to go in a mod like KSPIE then don't use FINAL! (instead, use :AFTER[RealFuels] or define some KSPIE pass that will execute really late in the MM cycle like :FOR[zzzKSPIEFinal]

I'm kind of confused actually - we did discuss certain parts packs a lot but I didn't know any of it was applicable here. Oh well, if I was helpful then that's good!

Usage would be to allow players to change the defaults for new games instead of having to wait until after the new game was started before making changes when it's known that the same changes are going to be made to each new game. And if it's done as a set of configs then it could also be patched via MM.

Are there any plans to move defaults to or otherwise allow the plugin to read from an external configuration file to override its defaults?