Starwaster

They might be civilians, but in space they're still astronauts and they have to wear vacc suits. That's where the mass comes from.

What the heck? They can't live off of snacks? Blasphemy! Jeb has no use for Kerbals such as these.... and they produce a recruitable (adult?) Kerbal every 3 Kerbin months??? Well that definitely kills the 'Kerbals are plants' myth... Kerbals are obviously rabbits Well, humor aside, this definitely looks interesting

I'm still trying to figure out what the gain is that would make it worth the effort that needs to be expended in finding and implementing that solution. I'm just not seeing the gain. If it's just to appease those who think 'it would be neat', then I just don't see how it's worth it.

He just gave it to you. There's nothing about the IntakeAtm resource that makes it work in oxygen-less atmospheres. That's a function of ModuleResourceIntake

Download this: https://github.com/Starwaster/LayeredAnimations/releases/download/1.1/LayeredAnimations.v1.1.zip Then you don't have to make your own config file. Make sure Module Manager is installed. The plugin is public domain Source: https://github.com/Starwaster/LayeredAnimations

I don't think that would work out. You would have to have two ModuleFuelTanks MODULEs on the part but you can only have one GUI for the tank(s) in the editor and it would only be operating on one MODULE in the best case scenario I can think of.

~minimumCrew[0] only matches for parts that do not have 0 assigned to minimumCrew (if you saw my previous answer, obviously ignore it as I got it backwards)

Notepad++ FTW.

What the heck.... people that help themselves... by searching the thread for answers? I suppose you expect us to believe that you thought maybe someone had already asked the question and had it answered? I dunno man, sounds like magic to me...

Sounds like a Mechjeb problem. The next time you see it happening, turn off RCS balancing and see if the problem persists.

That you explicitly mention adding the dll in addition to installing the mod tells me that you are using an incompatible version just like the error says. Don't copy in other dll versions unless explicitly told to do so and only with the version of DRE / KSP that dll was meant for.

To what extent exactly? CRP is going to be an actual dependency instead of RF being a stand-alone mod? What's actually involved and what changes are being made?

STACK_PRIORITY_SEARCH only drains from tanks in the current stage. (does not cross decouplers or parts that don't have cross feed) STAGE_PRIORITY_FLOW will drain from anywhere but prioritizes the current stage. (in other words tries not to drain from top stages even if the engine is mounted there, like RCS) Edit: STAGE_PRIORITY_FLOW also works for radially mounted engines as is typical for RCS

In other words, instead of assuming that the baseline reentry time limit is based on EITHER stock sized Kerbin OR Earth sized Kerbin, I'll calculate it on the fly after looking up size/mass of Kerbin. For instance, stock Kerbin takes roughly 3 minutes to complete reentry, we want an optimal reentry to result in X amount of ablative material consumed. But that might not be enough for Earth where a reentry could take 15 minutes or longer.

Check the Custom Biome folder.... Now that I think about it I seem to recall having this problem too. I think that's what I had to do was delete something from Custom Biomes...

This is what I'm using: @PART[vernierEngine]:NEEDS[RealFuels]:FINAL { @MODULE[ModuleRCS]:NEEDS[ModuleRCSFX] { @name = ModuleRCSFX } @MODULE[ModuleRCS] { !PROPELLANT[LiquidFuel] {} !PROPELLANT[Oxidizer] {} PROPELLANT { name = Kerosene ratio = 0.38 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = LqdOxygen ratio = 0.620 %flowMode = STAGE_PRIORITY_FLOW } @atmosphereCurve { @key,0 = 0 304 @key,1 = 1 265 } } MODULE { name = ModuleEngineConfigs type = ModuleRCSFX //thrustRating = //thrusterPower techLevel = 2 origTechLevel = 2 engineType = O origMass = 0.01 configuration = Kerosene+LqdOxygen modded = false CONFIG { name = Kerosene+LqdOxygen //thrusterPower = 0.445 PROPELLANT { name = Kerosene ratio = 0.38 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = LqdOxygen ratio = 0.620 %flowMode = STAGE_PRIORITY_FLOW } IspSL = 1 IspV = 1 } CONFIG { name = LqdHydrogen+LqdOxygen //thrusterPower = 0.445 PROPELLANT { name = LqdHydrogen ratio = 0.72856139 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = LqdOxygen ratio = 0.27143861 %flowMode = STAGE_PRIORITY_FLOW } IspSL = 1.261 IspV = 1.3 } CONFIG { name = MMH+NTO //thrusterPower = 0.445 PROPELLANT { name = MMH ratio = 0.437 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = NTO ratio = 0.563 %flowMode = STAGE_PRIORITY_FLOW } IspSL = 0.953 IspV = 0.952 } CONFIG { name = UDMH+NTO //thrusterPower = 0.442 PROPELLANT { name = UDMH ratio = 0.413 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = NTO ratio = 0.587 %flowMode = STAGE_PRIORITY_FLOW } IspSL = 0.95 IspV = 0.943 } CONFIG { name = Aerozine+NTO //thrusterPower = 0.455 PROPELLANT { name = Aerozine50 ratio = 0.502 %flowMode = STAGE_PRIORITY_FLOW } PROPELLANT { name = NTO ratio = 0.498 %flowMode = STAGE_PRIORITY_FLOW } IspSL = 0.963 IspV = 0.955 } } } Raptor, feel free to use this as a base. It covers most of the fuels that a lifter body might use in addition to hypergolic combinations. Its downside is that at the moment it does not modify thruster power by fuel combination as I was being a bit lazy and just wanting a quick fix solution to the problem. Also, it sets flow mode to STAGE_PRIORITY_FLOW so that it works out of the box without the cross feed enabler. (I did this with all of the RCS engines for my install)

No point in that. Next update will have a dynamically determined metric instead of a statically determined one. (using Kerbin's size as a baseline)

Correct, except for the beta's alternate heating model which only uses shockwave temperature for simple comparison to part temperature; if part temperature > shockwave then no heating is applied. Temperature increases are calculated from an empirical formula (which I am probably abusing the hell out of) Aside from that, I can definitely see ridiculousMaxTemp of 150 causing serious problems and Deadly Reentry has that set to 1250 by default. If it were set to 150, going by your example, the final max temp would be 150 because the halved value (of 900) would still be lower than the ridiculousMaxTemp. If you've set it that low yourself or if you're using a mod that sets it that low that would be seriously problematic. I have no idea why you would have to buy heat shields again. That makes no sense to me. If you installed everything correctly and copied your save files over then no, you should not have to buy heat shields again.

Sounds like a problem with the ablation metric setting which isn't exposed in the mod's debug menu yet. Working on that in the next update.

They SHOULD change it in 1.0; honestly it's the first thing that should change or they're going to have trouble balancing the system. Not sure how much realism will ever enter into it though since as Nathan has pointed out, a realistic Kerbin reentry isn't nearly as deadly as one over Earth. That said though, the stock system dissipates a LOT of heat even for a default DRE Kerbin reentry. I put in code to measure incoming 'heat', and found that with the new experimental code, the shield had taken in enough to heat it by 90,000 Celsius. Re: Attachments on shields: The short answer is yes, but the degree to which that happens depends on whether or not the shield's heatConductivity has been changed. A lot of the shields that the mod comes with (and a few 3rd party shields like SDHI are modified by DRE) to have a value of 0.01 so they're only transferring about 1% of what they take in. That can prove to be a double edged sword though since it means that shields can take in heat from external, non-reentry sources that can destroy them. That mostly seems to be an issue with parts like the Mk1 pod, which will either have that property tweaked or restored to default next update. As far as DRE's future, post-KSP 1.0, I think it's likely to stick around, unless KSP's new reentry system mind bogglingly exceeds all possible expectations of it causing everyone to say 'holy crap, this is what we've always wanted!', or at least be extensible enough that either DRE becomes unnecessary or paves the way for a total re-write of DRE revolving around the new update. I imagine though that there will be a delay before there is even an update since I'd either have to bypass the new system or find a way to work within it.

Try reducing Density Exponent even further, like to 0.5

In general, that is true. You can get away with steeper reentries over Kerbin than you would over Earth IRL. I think in part that is because Kerbin has had to be made more dangerous than it would be IRL. It's a very small planet with a very thin atmospheric envelope. (thin as in only 69 km from atmospheric edge to ground ASL. Not thin as in low pressure). It's only 2-3 minutes to landing, or at least until you reach a safe velocity. Another reason Kerbin reentries are not deadly is because the reentry velocity is much lower than Earth, and as has been said constantly over and over, reentry temperatures are linked to velocity. There's also a third reason that isn't much talked about, at least not except in broad terms about the unrealistic heating model that KSP uses. More specifically, crafts / parts are constantly trying to shed heat through dissipation. Unlike conductivity, dissipation does take into account external temperatures such that a part can't shed heat to an environment with a hotter temperature. But we have no way of communicating that to the base code. DRE might think that the environment outside is a toasty 2000 degrees but KSP thinks it's only -20 degrees C and so the part will shed heat. I've tried experimenting with reducing the dissipation values so that parts don't shed heat and the results were catastrophic because DRE was written around a system where parts are constantly trying to shed heat. So turning down dissipation results in rockets that explode during launch much more frequently than they ever did before. Not good.

First things first: Don't edit anything in any .cfg (exception, custom.cfg is safe to edit, but don't do it anyway because....) all of those settings can be altered in-game. When you are in flight mode, click the DRE icon (looks like a little space capsule) Second, in the beta, heatMultiplier is set to 1 because of a new heating model in the beta. As an alternative, I suggest changing densityExponent. Change it to a lower number. The lower you set it, the higher the altitude that you experience heating. Third, when you change densityExponent, also change FX Density Exp (FX Density Exponent) to match. As a personal preference, I like setting it to Density Exponent +0.05. That will giver you wispier softer flames when the heating starts to be noticeable but still turn into really ferocious flames when heating gets serious. Other things that control when you see flames is Begin At / Full At (under F/X Transition). Those are the velocities where flames start and where they max out. (modified by density) In other news, I'm making progress on the next update. It'll have an extra setting button to enable the new heating model with proper settings without messing up the original three difficulty settings.

Built a shiny new space shuttle to carry some satellite into orbit. As it rolled over onto its back during ascent... I noticed a disturbing lack of landing gear on her belly. Oooops!

Aw kome on.... not even a little?