Starwaster

I'm using the angle between the drag vector from center of mass and vector from center of mass to the part to determine if I need to offset. With only one radial active, the vectors don't diverge much so there's little offset. That's fairly simplistic, it could also have some threshold that needs exceeding before it kicks in. Or something...

Uh right... thanks for that.... but it's not about switching engines it's about configuring them in the VAB

Procedurally offset radials..... Code pending once I've tweaked it a bit.... nothing special.... if you want it.

I'm having the same problem in this last release.... symmetry transfer problematic...

Some of those spaces might confuse it... such as !MODULE[ModuleEnginesFX] {} should be !MODULE[ModuleEnginesFX]{} And I don't think you can do !PART[RAPIER]{} either.... I think that's technically root level and it's read only Don't think specifying ordinals on nodes work, only properties... maybe look for 1.5.7 in the thread, it might have added that sort of functionality but it's not officially released so not on the front page? (ok not actually sure there is a 1.5.7 anywhere, saw a reference to it elsewhere but I don't see it anywhere, not even on the github site....) (but, !MODULE[ModuleEnginesFX]{} at least should work. I did something similar on the B9 Sabre to get rid of its hydra controller and replace it with RAPIER style system)

They can be made to but that's not full RF support. The RAPIER actually has two engines defined in a way that RF can't deal with right now. Additionally stock RAPIER uses ModuleEngineFX which RF also cannot deal with. So you can make RAPIER work with H2 via config files but you won't be able to configure the engine for alternate fuels in the VAB/SPH.

It can handle it. It depends on your reentry angle though. Your trajectory. Depending on where you start from, it may not support such a maneuver nor would it be necessary. Apollo did that when returning from the moon, but I don't think you would be able to from a LEO...

Not with stock aerodynamics. Not really. The closest I've seen with stock is that I hit periapsis high in the atmosphere, started climbing back and and exited right before atmospheric drag brought periapsis back in so I climbed out for a little bit then dipped back in for final reentry. But no actual lift was generated, it was just the specifics of that orbit and its passage through the upper atmosphere. Now, if you have FAR installed you can indeed generate lift and this is useful for keeping g-forces under control. My understanding of real life is that it can also lower reentry heating, but my observations of DREC is that what will actually happen is that I generate more heat because the heat shield reflects some heat back before even absorbing any. That's based on whether or not your angle of attack is lined up with your reentry vector. The closer it is, the more of your rated reflection you will see. IIRC it's the dot product of the two vectors so facing full into it means full reflection (typically 5% for ablative, 25% for tile based non-ablative shields). Is that how it is IRL? I don't think so but I'm not 100% sure of that... So, tl;dr, more lift/less drag means you're absorbing more heat from reentry. More drag / less lift means less heat because you're reflecting more heat.

Yeah that should do it.

Ok, so someone asked about some 2.5/3.25 truss pieces. How are they just rescaled? And should the radiator piece go? Second shot shows a stock I-beam for comparison to the saddle truss beams. They are even thinner rescaled down; nothing to do about that unless new parts are created from scratch. Stock 2.5m tanks don't fit so well because they tend to have flanges and pipes....

Desaturated station hub texture. (gray/white) Goes very nicely with the FusTek modules. (or with Porkjet's parts for that matter) Use how you like.

Sokar, do you have a custom.cfg file anywhere in your DREC hierarchy? If so, delete it and try again

Ok, I use Notepad++ and I'm not having any trouble with formatting in non-Notepad++ applications. I don't believe Notepad++ is the problem.

That doesn't make sense. Deadly Reentry doesn't 'make the game think' anything regarding velocity or anything else except temperature. FAR however affects drag by zeroing out all part drag and then applying its own drag physics which may be more or less than stock depending on circumstance. Pedantry out of the way; DREC does affect AerodynamicsFX to make sure that the glow appears when it should and disappears when it should. I don't think it does anything about condensation FX (what you're thinking of as the shock). FAR might or might not... never really been clear if FAR has any effect on that other than affecting what speeds you might be able to reach... There might be a beta 1.5.7 buried in the thread, with the latest official being 1.5.6.

Your symptoms don't sound like you're hitting a memory limit. You should submit your output_log.txt file (Not the ksp.log in the main KSP folder, you want output_log.txt from the ksp_data folder)

What effect are you referring to exactly? Everything looks ok to me on reentry. Maybe some pics to help explain?

No, that was a mu file. He opened it in a text editor. That's exactly what they look like.

No, the science experiment module would have to have crew requirement implemented into it. I can't see any way of doing that through a config only. You'd need a plugin that extends the ModuleScienceExperiment and which makes such a check. Or possibly a more generic plugin PartModule that disables the part if it doesn't have minimum crew but that doesn't turn the part into a command module. No.

What, no indentation?

Try the texture compressor / active texture management mod

It gets confused because math is being applied to a shortened vector that generally relies on normalized vectors for accuracy. Math errors result. The problem is in stock KSP and affects the perceived position of the nodes and MJ relies on what KSP tells it. So as the remaining burntime drops under 1 (normal) it gets increasingly inaccurate. That's why you end up 'chasing' the marker. Nothing to do with gimbals, which are just for steering and for compensating for off-axis thrust. You can control their pitch btw independently of the steering aspect. So one thing you could try is pitch to compensate for uneven thrust but lock the gimbals so you're using RCS only for orientation. A properly balanced RCS array is probably better for steering than a gimbaled engine anyway.

not through configs only. Each experiment means a separate module. Each such module means additional menu entries.

Make sure to have some chicken soup.

The wildcard has to be in the first part, the @PART line. @PART[*]:HAS[@MODULE[ModuleScienceExperiment]] { MODULE { experimentID = * experimentActionName = Run Experiments resetActionName = Reset Experiments useStaging = False useActionGroups = True hideUIwhenUnavailable = True xmitDataScalar = 0.5 FxModules = 0 dataIsCollectable = True collectActionName = Collect Data interactionRange = 1.2 } } Look at the science links in my signature for examples. See how those are constructed. And experimentID has to have something valid assigned. Look in Squad's Resources folder. Look at ScienceDefs.cfg Every EXPERIMENT_DEFINITION node's id is a valid id to use for experimentID.

Unaffected. Unless I were to go over what can physically fit in there with reasonable room for life support, fixtures and plumbing. Do passengers on. 747 complain about game balance? Heck no, they say SHUT UP AND TAKE MY MONEY!!!