Starwaster

I haven't been able to replicate your ascent issues. But, I'm also using Real Heat right now for DRE testing purposes and I think it tones down some of the early supersonic heating. Not sure if that's intentional so I don't know if it will keep on behaving that way, but it might help you with your launch issues. Otherwise, use the difficulty slider and turn things down a bit. Or raise conduction factor a bit. (lowering conduction factor is part of how I increased the effects of convection heating. It prevents heat from escaping into the rest of the craft) Not shields like the ablative kind, but I did try to pattern their behavior after the space shuttle tiles. There is an issue right now where their overheating gauges will light up fiercely and it's pretty alarming to see but if you keep your reentry shallow then you'll survive. (I might bump up skinMaxTemp just a bit to kill the gauges but if I do that too much then it renders DRE useless against spaceplanes) TL;DR keep your spaceplane reentry shallow. You'll see them overheat badly anyway and you'll be all like ZOMGWTFBBQ KEVIN STARWASTER LIED TO ME THAT SUMBICH but then halfway across the planet you'll break through the clouds and your ship will start cooling off and you'll smack your chest a bit to try to restart your heart and everything will be ok.

Jump to image #15.... that's a large assembly encased in one of e-dog's Procedural Fairings (with the non-detachable fuselage) with 4x 3.75m KWR boosters. Also skip past that to the station core I put up in one piece with the same technique. (that one's more detailed in its space operations but skips most of the launch)

Also what's your terrain detail set at? Set it to maximum detail. It's possible that as you load that base in, the terrain is at a lower setting momentarily and swallows the base whole

It doesn't matter where the root is. It's like you said, it's the tree. You can re-root it to the payload and it won't make any difference at all. But I just tried the reverse, first I made my payload then saved it as a subassembly. Then reloaded the test vehicle that I based off of yours in the first post. Removed the payload from there and then loaded in my subassembly payload. That worked. You don't even have to reroot to the payload even. (though I did the first time around just to be safe, but it didn't really care) Here's the finished craft. https://www.dropbox.com/s/9qz8aa7lzf8vzx0/STAGE_PRIORITY_FLOW%20issue%205.craft?dl=1 Payload subassembly : https://www.dropbox.com/s/bnr8ekb3ayzqrpo/payload.craft?dl=1 Ahhh that's technically using Real Fuels, but with stock resources. If you don't have MFT or RF then it might whinge in the logs about the missing modules but should load up.

Doesn't KIS/KAS have some sort of pylon base that mounts to the terrain that you can attach things to? Maybe you could strut the base to that?

Depending on which DRA you're talking about, it's not a deviation. Also, a lot of those are artist conceptions where they may have omitted planned body flaps and stabilizers. Not sure WHERE those body flaps would be unless they are curved and fitted to the bottom of the aeroshell. In fact I think that's the only way that would work. But there are documents out there that do depict body flaps on the aeroshell landers. (fins would be retractable... probably)

Not sure why you assume that he has his root anywhere but the cockpit but I duplicated what he made with the cockpit as the root. In fact, the root doesn't really matter. You should have tried making the craft he made and seeing how it behaved for yourself That's why the jet engine's flow mode was changed, yes. I'm referring to the flow mode itself and why it exists and how it works. Remember that it existed before jet engines were changed to use it. Ok if you want to get technical STAGE_PRIORITY_FLOW draws from the highest numbered stage which you can find referencing part.inverseStage. Instead of theorizing I decided to write up something simple to show me what stage each part thinks it is. Note that this has doesn't necessarily correspond with the staging queue displayed on the side and it is possible for a part with no staging icon to have a stage assigned to it. On the subject of root placement I changed the root on OP's example craft to something bizarre and made it one of the jet engines itself. The effect on staging was zero. No impact whatsoever. Regretably I don't have screenshots for each of these little situations. Compare the two example craft. The tanks should show staging 2 except for the ones above the decouplers. Image #2 demonstrates this for the tank directly above the engine which is stage 0 because I crammed everything into one stage. So even though all stageable parts were 0, the tanks between the engine and decoupler were 2. However, for the one using spaceplane parts this is not the case. Everything except the payload tank was 0 and the payload tank was stage 2. The highest part. This is why fuel is drawn from it and it alone. Ignoring the bicoupler tank which should have been stage 2 and the payload stage 0. (only because I crammed them all together) I'm starting to think this is actually an issue with the code that determines stage location. Maybe because of the way the cargo bay nodes are placed. Or maybe because of the bicoupler part which uses a different crossfeed mechanism. - - - Updated - - - It's not supposed to drain upper stages first though, and usually doesn't do that.

Experimenting with this more and in greater detail. I want to further stress what I said earlier: STAGE_PRIORITY_FLOW draws EVENLY from every possible resource in the current stage. By no possible definition can the payload fuel tank be considered the current stage. Even if somehow according to flow rules the resource system thought it WAS in the current stage, it's drawing ONLY from the payload and is ignoring the bicoupler tank. Think about that a minute This only happens to things in the cargo bay btw. I moved the tank to the top node and it still happened. (not surprised) It occurred to me that maybe the top/bottom stack nodes are playing a role here so I played with the part file and arranged it so that the inner stack nodes were top/bottom and outer ones were top2/bottom2. (technically top/top2 and bottom/bottom2 occupy the same space; it's only their attachment order and order they appear in the part file that govern where things attach) I arranged it so that the inner top was the NODE_STACK_TOP and attached the decoupler and tank there. The fuel flow system should have been tricked into thinking that the tank really was part of the next stage and not drawn from it. (bottom of decoupler attached to the top stack node. I even changed the cargo bay inner/outer identifiers to match) And it still draws from that tank first without touching the bicoupler at all. There is something very wrong going on here.

Having to take issue with the bolded parts of your quoted text. Firstly, the fuel tank in the OP's example plane is in FRONT of the decoupler. By your definition it should not be doing what it's doing. Note my example below. This is basically the same thing except for the arrangement of the stack nodes (the cargo bay having two bottom and top stack nodes because of the way it works). This works correctly and is doing what it is supposed to be doing Also, the point isn't to control center of mass, it's supposed to ensure that resources are drawn from the current stage first and ONLY look outside the current stage if resources are no longer available in the current stage. That's the intended behavior and the OP's example is not behaving according to intended behavior.

Then maybe you need to do something about your ascent profile; perhaps you're going too fast too soon. Your starting TWR should be 1.25-1.6 if you want to go shallow ascent. Use fairings too. Fairings in DRE can have ablative shielding assigned to them now. If all else fails turn the difficulty slider down.

They are. But don't call me Shirley.

FAR is probably imposing less drag on you at high speeds in the upper atmosphere than stock aero is. Drag is based on the square of velocity in either case but supersonic convection heating is based on the cube. So you've got a lot of incoming heat but not enough drag to slow you down. Try setting to Pe 20 Edit: Also, what is your KSP reentry difficulty set to? (in-game, press escape, click difficulty options. Look at the bottom of the menu)

Somehow, I have the feeling that he's not using RO.... and he's not using a recent version of Deadly Reentry either. (which has a fallback configuration for shields in RSS that kicks in if RO is not installed)

Hopefully the blowing up is just a matter of modifying your reentry profile. For returns from LKO, Munar and Minmus returns, setting your Kerbin periapsis to 20-25 should work well for you. (EXCEPT for spaceplanes. You want to be roughly halfway around the planet from KSC and set it to something like 45-50...ish. If heat gauges are on, your ship will light up like a christmas tree except all the lights are red. That's.... ok. Try not to panic)

The cache shows every sign of the physics.cfg file having been rebuilt rather than being copied over. (aeroFXScalar = 0, newtonianDensityExponent = 0, etc) Go doublecheck your D:\Games\Kerbal Space Program(1.0.4 Modded) folder. Delete physics - copy.cfg if it exists, or any variation thereof. Then copy in the file that you downloaded from my link. Copy it over the existing file. (or, just this once you can delete the physics.cfg and then copy the fresh one in... that's the only time it's ok to delete) In the next update of Deadly Reentry, I'm just going to have to take any of those settings that get zeroed out in rebuilding the physics file and set them myself in DeadlyReentry.cfg so that they'll be sure to be set to appropriate values. That will prevent this problem going forward.

Is that a Scatterer mod I see there before me?

I agree with others. It's long enough already. Your design is not necessarily broken however, if it cannot take off in the allotted runway space. Rather, you may need some JATO rockets to help you get off the runway. (small jettisonable solid rocket boosters)

Parts fell off of the actual plane? Sounds like some breakingForce / breakingTorque fields are set too low. (or, not set at all in the configs which means defaulting to 22 which is too weak)

Each bunk lifts up to reveal a toilet.

My fake internet points? Don't know; don't care. Here's some cat tax

I PM'ed you a link for it.

It's not fair to accuse people of 'nitpicking' when they speak out on the roof hatch issue. It's legitimate feedback. The current location of the hatch is unfavorable compared to its previous location and it's ok to say that.

How it appears from the exterior isn't relevant. A window that is meant for viewing through should be more optically clear from the interior. case in point: I can provide configs for Ioncross

Looks like an issue with the depth buffer. Is depth data for the terrain being written at all do you know?

It reminds me of the shell that's used to render the atmospheric haze. Maybe it's an EVE issue or Planetshine. (not sure if Planetshine actually modifies the appearance of the atmosphere though....) Also have you made any changes as to what graphics drivers are in use? (Forced DX 11 or OpenGL, etc)