Loskene

I mean, c'mon. But if they turn the MH mission editor into a career/sandbox VAB/SPH testing tool like I keep asking we may have more to argue with.

I started working on a big complicated quadcopter crane thing powered by LF rotors and vernier rockets, with folding arms to fit inside a fairing and ducted (looking) fans for lift. Turned out to be extremely wobbly and too heavy to lift off, so I tried something a bit smaller and more nimble instead. Clips here from my first 2 test flights. Got around 50m/s out of it in level flight, it's not exactly built for aerodynamics, but it was fun to fly. It was a bit of a handful with a keyboard though, I'll have to tone down the reaction wheel torque, and finding the sweet spot for the AoA and blade pitch ended up being my undoing every time so far. A few degrees either side and it drops out of the sky like a stone.

Stock FAR yes please, it just feels weird designing planes without it now. How the plane's surface features and shape appear should affect how it flies, that just feels more intuitive to me and it's generally how I design my planes to look with either aero model.

Made a wee counter-rotating prop plane to see how quirky they are to fly. Answer: very quirky with the new blades and motors, but easier to get to grips with than I thought. It took a bit of fussing about and there were a few "oh, duh" moments in the editor when figuring out the relative configuration between motor direction and default blade arrangement, but I was able to get it to produce thrust in the direction I wanted before my first test flight, which is where these screenshots are from. So I don't think it's too difficult to work out even with trial and error. They are very much their own thing compared to the ease of jet engines and rockets though, and you need to have a rough idea how real prop engines work before going into it, because there is more to it than suck-air-in-shoot-air-out in real life too. I had the motor torque limit assigned to the main throttle and blade pitch set to translate forward/back (H/N). The rear motor was a copy of the front motor rotated 180 degrees and with no settings changed except inverting the deploy direction on the blades. You're probably meant to futz around with the relative settings for rotation and blade direction to optimise thrust but this worked to control both sets with the same controls fine to begin with. The front prop is the one I have the PAWs up for since I don't need to monitor both. I flew it manually to the airfield and then hands-off by SAS and trim back to the KSC, and got up to a pretty reasonable speed I think, the whole flight took 5 minutes before attempting landing. This is with FAR installed so I don't know how it figures out the airflow over the new blades, but it all seemed ok. In order to get it up to speed I left the throttle on full and adjusted the blade pitch to maximise acceleration, eyeballing the rate by the navball speedometer since KER wouldn't give a thrust readout like a true engine as far as the game is concerned. I found it peaked at around 80 on the limiter and it would harshly lose speed if you moved it any higher or lower while flying at top speed of around 220m/s. 0 pitch had the blades perpendicular to prograde. The torque was balanced out pretty well from the two engines but there was a fairly persistent roll to port throughout, though nothing you couldn't damp out with a few taps of aileron and elevator trim, after which it would fly level with SAS. I found near the end of the flight, when trying to slow down for landing, you could cut the motor torque down low or off completely and so long as you maintained the appropriate blade pitch for the speed you were going, it would maintain its speed for a long time. It was actually hard to slow down, I had to turn the blade pitch out of the sweet spot to apply more drag, but this stopped helping when the engine RPM finally reached 0. Airbrakes would be a good idea. But none of that ended up being important because we had a gear out situation on final, the starboard gear reporting it "cannot be deployed while stowed" even though the port side was fine. Must be Kremlins in the fuselage pontoons. I ended up overflaring and tumbling on the runway, when what I probably should've done was fire up the engine for a second and glide for a splashdown with the gear up. Oh well, lesson learned, and fun times with the new DLC. Worth the money so far. Final notes: Please make the LF motors into alternators when you shut off the power and they're still spinning.

While the G-turns in RSS are fundamentally the same as stock, the scale differences and tighter deltaV budgets make it much more sensitive to losses from steering, drag, etc. Many hardcore RO/RSS players use kOS scripts, mechjeb or other autopilot mods to fine tune and revise their trajectories on the fly to get the most efficiency from the tighter margins. Ideally you want to have it so that rather than boosting up out of the atmo and coasting to apo before circularising, as you would in stock, arrange it so the engines are burning for the entire duration and your vertical speed is near 0 at apo while circularising. Requires more planning in your rocket and launch profile ahead of time, tweaking the staging/burn time/TWR to maintain an optimum profile for the entire flight. You can't really brute force it as easily as in stock, an efficient gravity turn is more important, or else your rocket will end up ballooning in size to make up the lost dV. Tyranny of the rocket equation. Even flying "manually" still tends to mean using Smart A.S.S. for steering one degree at a time and carefully managing your time to apoapsis, vertical speed and acceleration curve. There's really no one-size-fits-all gravity turn for rockets in RSS though, the exact profile you take depends heavily on the TWR/ISP/drag of each stage. Low-thrust upper stages may need to veer wildly above prograde to make sure they don't fall back down during the long circularisation process, while solid motor upper stages may just need to clear the atmosphere and burn like hell at the horizon, even pointing down to make sure the orbit isn't lopsided. I don't know how well it works in RO, but in stock I find the GravityTurn mod very useful for finding the optimum launch profile for your rocket, as it refines itself every time you repeat the launch to minimise losses. It's good to just watch what it does and learn its methods, though don't let it control staging, especially in RO, best handle that yourself or ullage motors and interstage fairings will confuse it. In any case if you already know the fundamentals of the gravity turn then all you need is practice to get good at it in RSS, and eventually you'll be routinely building rockets with exactly the dV needed to reach LEO and not a single drop more. Good luck.

Fascinating. I know they said they went to a lot of effort to simulate/abstract realistic prop effects but I didn't know they went that far. I thought it was mostly just compensating for the (game) engine RPM limit.

Ah, good choice, Svetlana was the name of Stalin's daughter

I think this is just a physics engine thing squad have had a hard time getting around, since the best they could say when releasing the props is that they should pull away from the point of rotation "a bit less". No idea what causes it, I'm not a programmer, but it's an issue that's been with us a long time and so smacks of a Unity problem that's out of squad's hands.

Let's not toss out the pontoons without second thought now. Those were always the biggest impediment to making a good seaplane that keeps its fuselage out of the water without having really awkward mass distributions, since all we've had to work with so far is fuel tanks made from WW2 tank armour. A lightweight (hollow fibreglass) pontoon/float would be lovely, ideally modular pieces in 2-3 standard sizes, for fuselage and wing supports. High crash tolerance and low water drag too please, for obvious reasons. Skids are actually the parts I'd have the least use for, after airbags, which would be handy for low altitude abort systems.

Any fusion torch drive burning at a steady 1G will peak just shy of lightspeed in about a year of travel. They all have an Isp in the hundreds of thousands or millions of seconds so propellant isn't a huge concern, and you don't even have to go shopping for mods, just edit a stock engine config for whatever wild values you want, there's functionally no difference. That's why fusion torches are called the holy grail of rocketry, high thrust and high efficiency, you never have to turn them off. In KSP it'd reach the speed of light and keep accelerating until you hit some computational precision limit and krakenthings happened. If you want it to take less than a year just crank up the thrust.

Has this happened on any other craft or just the once? Readout might've bugged and thrown up a NaN or something, might not be anything to do with the craft.

It's completely rigid, like any other part, the inflatable bit is just flavour text/verisimilitude. Should work fine, just don't accidentally retract them :V

If you want useful IVA instruments in space you need to install RasterPropMonitor. I would like more reasons for IVA flight in the stock game though, it's a very different experience.

Even remotetech doesn't make you physically point the dish (only assign it a target) as you need yet another mod (persistent rotation) to have the smallest chance of keeping the dish aligned. The game doesn't really have much in the way of stock or modded tools to enable this behaviour, or compensate for loss of dish alignment during manoeuvres. Remotetech has the option to queue commands to an autopilot but it's janky as hell and doesn't include an option for component facing, only gross ship movement.

It's meant as a bodge to fix some other issues with craft stability, use it sparingly, grandparent autostrutting on parts you find unacceptably wobbly. Don't use root or heaviest on anything that has to dock, as sometimes a sudden shift in which part is heaviest or considered the root will cause... incidents.

No, it just doesn't display values above 15G. You can press F3 to see your peak G-forces on the active craft. If you have Kerbal GLOC enabled in difficulty settings they'll pass out and become temporarily unresponsive after sustained high-G. I think those otherwise flavour text kerbal stats might have an effect on individual G-tolerance.

Oh. How come you're building sloping cockpits without a separate control point aligned with the craft's propulsion axis to begin with? SAS will do funny things in level flight like that.

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.