Starwaster

Assuming you're coming in from ISS altitudes, set a periapsis of 60-65km. Through most of your reentry you'll probably want a pitch up of 35-40 degrees When you reach 73km you should be down to about 6.3km/s. At 70km you'll be around 5.5km/s and that's about where you'll really hit some major braking. Your skin temperatures should be dropping by now. Max Q will probably be reached at around 45km altitude and be over 2kPa. (depending on your design it might be higher. I actually hit 2kPa around 70km and it gradually climbed to about 2.3) By this point you should feel free to pitch down whenever you feel like it. Pretty much you'll want to do so by the time you're subsonic or you could lose control. But again, from this point on you should be able to fly your plane normally. If it's purely a glider design then you'll want to be pitched down a bit so you don't slow too much and stall. Edit: On the subject of S-Turns: I have no idea if you'll really need to or not. The shuttle had to in order to prevent overshooting the runway. The purpose is to divert lift off to the sides. As each turn takes you off course, you reverse the turn to the other side and bring yourself back on course. (roll reversals)

If you're burning up then your reentry angle might be too steep. It needs to be shallow with your plane doing as much braking as possible while still in the upper atmosphere. You should be taking about one half of an orbit at least before even hitting max Q.

ModuleEngineConfigs is used by Real Fuels to switch between different fuel mixtures in engines. (such as kerosene, hydrogen + liquid oxygen or other oxidizers, etc) So it probably would make sense not to have Tweak Scale affect it directly since it's going to be used on the engine module (ModuleEngine, ModuleEngineFX, ModuleEngineRF, etc) after it's been configured.

Either they don't have RC configs at all or they have RC parameters that are designed to be unalterable in the editor.

You already made a thread about this in Real Fuels and honestly there's probably nothing @Raptor831 can do about this since the only thing this mod really does is edit engine configs and add RF engine configs to them. A few tanks get touched but even then it's going to be a code issue in Real Fuels or Tweak Scale not interacting properly. (i.e. compatibility fixes to one or both of those needs to be done which Raptor won't be able to effect)

So what exactly are you saying? Are you still confused about something? Or is everything good now?

That doesn't look right. You don't specify what parts to grab. The problem with the line that you're trying to fix is that it was not syntactically correct. @PART[AdjustableRailScaleable|dockingwasher_stdScaleable|dockingwasher_freeScaleable|GantryLargeScaleable|GantryLargeScaleableVariant|IRHingeClosedScaleable2|IRHingeOpenScaleable|IRHingeTallScaleable|IRHingeTallNDScaleable|IRPistonScaleable|IR_RotatronScaleable|IR_Rotatronmk2Scaleable|IR_RotatronVTOLScaleable|TelescopeFullAScaleable]:NEEDS[MagicSmokeIndustries]

Or use it in upper stages so that the lower stages (burning other combinations) have more delta-V / TWR as in Saturn-V. Also people, about the Isp - thrust relationship, higher Isp propellants have more thrust per unit mass of the propellant. I think that's part of what confuses people new to RF about hydrogen. It's a high energy fuel but its low mass gives it a low base thrust.

That will horribly break reporting for designs that have boosters that aren't dropped. What if someone mounts SRB and doesn't jettison them (literally because they have no decouplers) and they are present in later stages? TWR will be wrong in those stages. And it will still not meet the criteria created when you stated that you wanted to ensure that you could land at a given target because you won't know if the real TWR is high enough to allow landing until you actually get there.

It's not a question of whether there are multiple engines feeding off of the same tanks. It's that decoupler/separator that is crossfeed enabled. That design is capable of completely draining those tanks before it even gets to the stage that you want it to report TWR for. If that happens those engines have no thrust. So no TWR. Or do you think it makes sense to report TWR for a stage with empty tanks? Because that's what you're proposing when you suggest not looking at the tanks. The calculation is automatically wrong no matter which way you look at it because either you're reporting thrust for engines that have no thrust or because you assume empty tanks when in actuality they have propellant in them. Propellant has mass. That mass is part of the TWR equations. Ignoring the tanks would break behavior for existing designs because all TWR would be wrong. Including for your specific cited situation it would definitely be wrong. You cannot ignore the tank's contents.

And a thruster with propellant. If it projects that the thruster will have no propellant at the start of that stage then it has no thrust and therefore no TWR Edit: You acknowledged that it has no way of knowing what the delta-v is going to be for that stage so you know that it has no way of knowing how much propellant is going to be available, so how much mass would it even use for the TWR calculation? Propellant has mass and is part of that calculation.

How would it even know what value to assign to TWR for the second stage? What would that logic even LOOK like? Maybe that makes sense to you but it doesn't make sense to MJ and quite frankly it makes no sense to me either. You've created a situation where the second stage might very well have NO fuel in it when staged therefore it HAS no thrust and therefore can't assign a sensible value to TWR. You yourself indicate that MJ has no way of knowing what you're really going to do with that craft. It can only assume that you're going to thrust until all available fuel has been exhausted, including fuel from the second stage across your crossfeed enabled separator. Seriously, what should the logic look like? Even if you can't code it, can you at least provide a valid set of logical rules for MJ to follow for crossfeed enabled designs that doesn't break logic for existing default designs with decouplers that block crossfeed?

From a modeling standpoint, I don't know, sorry.

No idea. If Lithobrake has chute parts, there are no configs present in RealChute that convert them. Have you asked in Lithobrake's thread?

It throttles the engines independently of each other to steer the ship. So if you're steering to starboard it will throttle back the starboard engines. The port engines are providing more thrust so the ship turns to starboard.

I find that sometimes that message is erroneous. It'll say that it failed but I can actually see the engines individually throttling...

Just click the GIthub link in the very first post where it says Download. It takes you right to the latest release. Mediocre! (we're doing a Mad Max thing, is that it?)

Reduce engine gimbal authority to 33%-50% Don't use control surfaces on rockets for ascent. (or if you really want them try using the Dynamic Deflection mod which reduces control surface authority at high speeds) Link here: Plugin Workshop If skinMaxTemp isn't defined then it uses maxTemp (so, 1073.15 per your previous example)

Is that skin or internal? SkinMaxTemp should be higher to represent heat resistant coatings. (IRL that would actually be part of the heat shield if one is present or applied as an ablative paint to withstand ascent) In Deadly Reentry I actually give those parts a skin temp of 2300 until the cap is ejected. (which happens the first time a chute is (pre) deployed from that part) (oops it's just 2300... didn't actually implement a lower temp after deploy...)

Parts packs are usually immune to version changes, with a few exceptions that you probably won't find in parachute parts.

What he probably wants for scale is @rescaleFactor = 1.5625 if I understand their scaling correctly and if they're consistent about that scale.

That doesn't sound very controllable to me. If you have to compensate with reaction wheels then you're wasting thrust that could be applied to translational ability instead. When translating, your thrust should be centered around your CoM. That ensures that more thrust is being applied to translating instead of increasing angular momentum. Basically, everything I'm hearing and seeing about that first ship is telling me that there's a design flaw. If it's already off axis when docking, its attempts to close the gap are only going to make things worse.

What have you done to ensure that your craft's RCS is balanced? What happens if you try to translate side to side or up and down? You need to be able to do that without any rotation happening. If you try to translate to the side and the craft begins to rotate left or right (same for up/down) then you have a problem that MJ may not be able to cope with. Turning on RCS balancer may help. However, your RCS thrusters need to be throttleable or it won't work. (Always Full Action needs to be off)

Yeah I've heard that before too.

If you can provide me a station that demonstrates what you're talking about using only stock parts, I would love to see it. Every other time that someone has said that MJ is 'aiming' or 'targeting' a point that is off-target, it's been a case of something else. Usually an inability of the docking craft to close the gap between the two docking axes. I've even demonstrated this in the past using custom code that shows how MJ is thinking and where it is really aiming at. (remember that in the final phase of docking, it keeps its docking axis parallel with the target docking port's axis)