Starwaster

Keep a 45 degree angle Only put RCS and speedbrakes (if any) on the upper surfaces where they will shielded. If you use MechJeb then use SmartASS +SVEL (pitch +45) because it's your surface velocity vector that matters here and it will deviate from your orbital vector. (if you're eyeballing it from the navball then switch to surface mode manally when you start reentry) Edit: @Funk, Fell asleep before finishing my work on a module manager config for NFP's engine. Still working on that. - - - Updated - - - @Funk or anyone else using NFP Edit your EngineHeatAdjuster.cfg file and add this to the end. That should work but obviously I'm not familar with NFP or its VariablePowerEngine workings so let me know if this doesn't. (note that this patch only assumes a two element HeatCurve, so if there's an engine with more than two curves, this will fail and I'd have to add more key edits in) @PART [*]:HAS[@MODULE[VariablePowerEngine]],!MODULE[ModuleHeatShield]]:FINAL { oldMaxTemp = #$maxTemp$ @maxTemp = 1250 tempMult = 1250 @tempMult /= #$oldMaxTemp$ @MODULE[VariablePowerEngine],* { @HeatCurve,* { heat0 = #$key,0[1]$ heat1 = #$key,1[1]$ heat0 *= #$/tempMult$ heat1 *= #$/tempMult$ @key,0 = #$key,0[0]$,$heat0$ @key,1 = #$key,1[0]$,$heat1$ } } }

Nope, not handled. That makes it pretty obvious without the need for the log. I can't do anything right now but watch this thread tonight and I'll see if I can come up with a solution. In point of fact, engines are currently handled primarily through a Module Manager patch instead of via the plugin because it was a hassle dealing with Real Fuels/ Modular Fuels engine config nodes which do quite a bit on the fly and I got tired wrestling with reflecting into the class and just wrote up a MM hack. I can probably do the same for VariablePowerEngine's HeatCurve. Re: PP SRB: I'll look into it.....

You and me both. WANT WANT WANT! GIMME! </rant-rave-gnash teeth-wail>

The latest versions of DRE reduce heat output on any engine that has had its maxTemp reduced. Additionally, if Real Fuels is installed, it also goes through every engine configuration and cuts the heat output in those as well. If you provide a log (output_log.txt. player.log if Linux/Mac) I'll try to diagnose the problem but it's likely a conflict with NFP and I don't know that I can do anything about that. (I'm not inclined to implement any exemptions for engines in the form of config toggles or other forms) To the best of my knowledge, that is working properly and as intended and I have not received any reports to the contrary There's no document assembled but they've each been talked about at various times in this thread. It has been on my mind to document the various settings but I obviously haven't gotten to that

Warning, 'splice operator' is probably not technically correct since we're not dealing with lists, tables or dictionaries. Nevertheless I tend to think of it that way so I tend to call them that. When dealing with Module Manager, the @ is used either as a conditional to see if a node exists or to edit an existing node, key or field.

You're missing the splice operators. Also, you need to specify for each key which key it is (key,0 and key,1 for first and second) @PART[xxx]:Final { @MODULE[ModuleEngines] { @atmosphereCurve { @key,0 = 0 100 @key,1 = 1 62.5 } } }

There's a Nautilus X parts pack out there somewhere. Search the forum for it.

I think I just lost IQ points...

Proportional Integral Derivative controller In a nutshell, the difference between where you want something to be and where it is, is treated as an error. Proportional is the current set of errors, integral is the accumulated errors? Or past errors? And Derivative is predicted errors. As I understand it, they actually date all the way back to the 1700s (obviously not in digital) and were used in (among other things) steam engines on steam ships and even for rudder control of the same.

I don't know PID well enough to say but I think it's not seeing that there's errors on one of the 3 controllers. I.e. it doesn't realize the degree to which it's off course. @Sarbian: This part right here: [COLOR=#333333][FONT=Consolas]pidAction = pid.Compute(err, omega)[/FONT][/COLOR][COLOR=#333333][FONT=Consolas] + attitudeTargetAcc[/FONT][/COLOR][COLOR=#333333][FONT=Consolas]; [/FONT][/COLOR] Shouldn't attitudeTargetAcc be added to err instead of being added to the output of pid.Compute? Or if not then what is that actually supposed to be doing? Right, right. Because, of course REAL space ships don't have computerized landing computers...

Try doing a reentry from a Mun return. I don't know if that's a 100% repro or not though. I'm going to try one now. That's when it was most obvious to me. My Mk1 pod would not maintain orientation and I didn't see the control indicators moving at all. However I don't know if that necessarily translates to 'MJ didn't try at all' because I've seen it perform an orientation and the markers don't move at all. No repro on that either; I saw it a few times. Both might be intermittent

That seems unlikely. I had it happen on a ship that didn't even have SAS available. (career game w/ scientist as the sole occupant) Looking at the change logs, there were some attitude controller changes made here: in build #412 I think that was the build where this problem started and those were the sole changes. (some additions to MathExtensions and significant changes to the attitude controller)

Sorry, I misunderstood! (still, that was kinda funny though...)

No, not at all. I'm not sure what the solution there is since the game tracks by Kerbal name as well. Unless there's some way of being notified that a name change occurred.... or maybe if the index of the master roster remains the same over time, CrewQ could periodically check and see if Kerbal X has changed names. Honestly though it's really a problem to change Kerbal names because like I said, that's how the game identifies them and tracks them. There is no GUID for a Kerbal.

Yes. Why don't you have this already???? Go say 69,105 Hail Marys and then go download KAC.

Make sure that Deadly Reentry is updated. That sounds very much like a bug from an older version. Aside from that I suggest submitting output_log.txt instead of ksp.log. (some developers might be ok with it but it frankly lacks important data in its log. output_log.txt is much more informative, or player.log if Linux or Mac)

I'm not sure that's.... does bacon NEED condiments? I suppose a BLT should have mayonnaise but bacon itself is the perfect food..... sounds kinda sacrilegious...

Even in real life you can't predict with accuracy where something is going to land. Stock uses the same amount of drag for every single part regardless of orientation, size or mass and is highly predictable, unlike real life. Remember that FAR tries to provide realism and the more realistic its drag model gets, the less accurate landing predictions are going to be, even with the trajectories mod. As an example, refer to the image below. It shows the predicted landing zones for several Mars probes that we've sent over the past few decades. You'll note that it takes the form of an ellipse. The probes were predicted to land anywhere within the designated ellipses. You'll also note that with time we've gotten more accurate with our predictions as we learned more about Mars atmosphere and aerodynamics and as our technology has improved. Curiosity had the greatest degree of accuracy yet but it was made possible because Curiosity could 'fly out the errors'. In other words it actively steered towards its desired landing zone. You're already getting far more accuracy in predictions than NASA got

enneract has indicated that he's extremely busy with work and said I could release my build of CrewQ with a fix for duplicate crews. (I'm not clear under what conditions this happens because CrewQ usually empties the pod but I've seen it happen where I had 4 identical sets of the same crew) For the curious, this was a two line fix which you can see here: https://github.com/fingerboxes/CrewQ/pull/4/files Here is the fixed dll: https://www.dropbox.com/s/ueht0vt838i4hea/CrewQ-v1.03-starwaster.update.zip?dl=1 Unzip that to your KSP's GameData folder, overwriting where prompted for the dll. (the folder structure is kept intact; there are two files: CrewQ.dll and license.md. The license file is actually identical to enneract's so it's really just the dll you have to overwrite) (I left the license in there because I've got warned for not having licenses in uploaded files.... I don't think it had to be in there but better safe than sorry)

For the mass quantities of Tang?

Please make sure not to batch out to every possible core; leave 1-2 available for KSP / Unity. KSP struggles enough as it is without throwing unnecessary stumbling blocks in its path

You need to post that with the Keanu Reeves conspiracy picture.

Toolbar is complaining about its folder being in the wrong location. It belongs in GameData and not in the Achievements folder.

Damn, what a gullible breed.

FYI, you don't have to explicitly do anything to the camera. An error in any module at the wrong time could do it. The camera POV gets detached. Or the rigid body gets detached Bug report: Kerbals currently assigned to ships can (will) be assigned to new ships. I can launch endless successions of 1 man pods all filled with Jeb. Edit: Found the cause. Will do a pull request with the fix later.