Loskene

What on Kerbin are you doing that would cause this, lol. The navball is aligned to your control point so is your cockpit/probe core angled 20 degrees down from the rest of the plane in level flight? I mean I've just never seen this particular problem come up before.

Oh that's clever, I like it a lot

While I wouldn't say no to an Expanse-type "ruggedised" Vac-suit, I'm liking the idea of the bubble helmet with a little spire on the top now, for kitschy pulp scifi style and so we can look at something besides the back of a kerbal helmet when walking on the Mun.

I think it's generally good form when submitting a challenge to consider the ruleset before posting it, and to also do an example run yourself to make sure it isn't pointlessly easy or hard. There are no-ISRU single stage to anywhere designs and there are options for going to Eeloo staging one separatron at a time, what is it we're meant to be doing here?

"This is fine"

Tilt rotor blades are designed to be halfway between a prop and heli blade, essentially, and the patch only gave us one or the other. I wonder how much of a fudge factor between the flight regimes of the two types of blades there is, because presumably they knew people would make tilt rotors and didn't see reason to add a special blade model for it. The small heli blade and the large prop blade are roughly the same size aren't they? An engine nacelle with a mix of blade types might be interesting for jack of all trades flying.

Strange. Crossfeed enabled on the decouplers, yeah? And fuel from all tanks is feeding to all engines in the fuel flow display? If the centre engine is node-attached and the others are surface attached there may be flow problems idk.

I'm asking what those conditions are because the DV calculator is affected by a large number of inputs. Bring up the fuel priority display so we can see when (the game thinks) the drop tanks are supposed to stage. The only difference I can think of is the number of engines changing the rate of fuel consumption, which might in turn affect when the calc thinks the tanks are supposed to drop and the resultant dry mass values. There's not a lot to go on here and we don't really know what the DV calc's exact order of operations is when figuring this out. Drop tanks always give it problems.

Learn. That was your first plane, now see how your second one goes.

ooh lovely, wasn't expecting this to be ready just yet. Nice one

Yeah I've found that only parts blowing up on land contact actually slow down the craft a bit when they explode. For splashdowns they just disappear and the part behind carries on at full speed. ie there is lithobraking but no aquabraking for return capsules, ditch the shield and slow down over water.

The kraken is salivating at the thought of elastic kerbal tether physics. I support it.

Are the drop tanks set to feed fuel into the core tank or is it drawing from all tanks at once? It tends to get confused when it has no way of knowing when drop tanks are supposed to be staged. It's possible that both of those readings are wrong, regardless of engine count. The DV calculator requires very clear staging/fuel drain order to give accurate results.

I jettison it whenever I want to destroy the capsule by having the shield fly straight back up due to KSP errordynamics. Wait.

Nice, looking real smooth there. Bonus points for the Robot Wars-worthy "srimech"

I think you can put AG triggers on the timeline, meaning you can make a timeline over X seconds and place the actions along it in order, though I guess you'd need a dummy robotic part for doing that and nothing else. Might be good to have a proper delay system as well.

Forward time travel at a rate of 1 second per second is available for everyone in the base package, modifiers are DLC, coming soon!

So basically a stock version Smart A.S.S. from mechjeb (we rarely need all of mechjeb but it has some very useful tools) so we can input a numeric heading and pitch/roll/yaw angles to try and hold. Stock SAS just tries to hold "this heading" but any motion beyond a certain range makes it forget what "this heading" is and just settle for whatever, meaning it'll never hold perfectly level and can't compensate for horizon drift. Being able to just order it to hold the horizon or a specific "default" angle it can't lose track of is all we should need. I would like it, since SmASS is one of few things I always want mechjeb for. I mean we could go full fly-by-wire (many such mods exist so it's doable) but that should be the bare minimum to accomplish the task.

Yes!

Conservation of angular momentum will bite you the moment you "unfurl" the tip and it ends up subsonic, if I get what you're thinking of here.

Yeah I found orientation much easier to get around when I started using WASD to fly the navball, not the ship. It's also the key to low flying, like super low flying. The prograde marker is the only thing your eyes will see the whole flight, so I use NavHUD to see it projected into the world. Helps a LOT.

That's a good use for a stayputnik actually, I might steal that for a small quadcopter drone.

Oh. Well you're right I have no idea if they did, but I believe large publishers also hook their various studios up with industry contacts they have to get a better return out of it. There have been a lot of new hires since then ¯\_(ツ)_/¯

Nothing on this yet huh. Is there a bug report filed for it?

Strange one alright. Neither of those are modded tanks? Any modulemanager patches that might cause conflicts? Radial vs node attachment? idk mate, usually it's just a crossfeeding issue. Might have to build a few test articles on launch clamps to eliminate part configurations until you find the culprit.