cantab

I haven't used it that much myself. But yeah, one of the most common things I see is seven Vectors under a 3.75 m tank, for real monster launchers. I've rarely seen it in a 1.25 m stack, I think it's just too much thrust for them usually. Performance-wise, it's "really" a 2.5 m engine, and it fills the niche between the Skipper and Mainsail. You can use a 2.5 m fairing under it as an interstage to fashion your rocket.

I'd say the part selection feels fairly complete. But as far as additions: Boat and submarine parts. We have three worlds with oceans, we need more to do in them. That could well be the main focus of a major update - imagine a whole bunch of new parts, new science experiments, a revamp of the underwater visuals, and maybe even a subsurface ocean on worlds like Vall and Eeloo. SRBs in other diameters, the current selection feels a bit limited. Preferably some powerful 2.5 m ones with thrust vectoring so people can make real shuttles. Limited 5 m parts. I don't think it warrants a full set of tanks and engines in stock. But a couple of 5m orange tanks with matching pointy and roundy end caps would make for shuttles that look the part more. Plus a 3.75m to 5m adapter. People can make Mainsail/Vector/Rhino/Whatever engine clusters to taste to power their 5 m lifters. The Flea re-optimised as an upper stage SRB with high vacuum efficiency, high fuel mass fraction, and relatively low thrust. Such engines are fairly common in real life as a cheap, simple, reliable way to kick satellites and deep space probes out towards their destinations. That would give the Flea a new lease of life after its early career get-off-the-ground role. Finally, I'd really love a steerable parachute/paraglider. Something that will give you a bit more control over landing site than the regular chutes, or be fun for a spot of low and slow flying.

Yeah, it's a fairly straightforward file format. I don't know if it's any standard or something Squad cooked up. There is already a program capable of reading and parsing the .sfs format - KSP itself! It's nothing like XML. It's not JSON, though at first glance it looks close. Practically, probably the biggest deal is that .sfs is a line-by-line format, whereas JSON uses punctuation. It's not INI, YAML, or libconfig either. It is I think the same basic format as the .cfg files for parts, and the settings.cfg file. And the format is inherited and extended by Module Manager. I believe the KSP Trajectory Optimization Tool also reads .sfs files , though it only cares about a small portion of them.

Maybe Microsoft Combat Flight Simulator 3, for a bit of a different experience? Old game now so hardware performance should not be an issue, though OS compatibility might be. The flight physics are the same as in FS2002.

But at least it's not 'free-to-play' Lego Racers on the Gameboy Color. It would have been a nice Mario Kart clone, if it wasn't for having about a three yard draw distance meaning you can't see turns or powerups until it's too late.

Except Falcon Heavy won't put as much to LEO as SLS. FH looks set to be a great rocket, 50 tons in LEO is awesome, but it's not 70 like SLS Block I and it's certainly not 100+ like later SLS variants are planned to be. Indeed SLS Block 2 claims are more in line with the lower estimates for BFR.

By my reckoning Bloojay's micro-shuttle is pretty close though. It just needs RCS and a cargo. (And Ain't No Rule about how big the cargo has to be for STS-1 pilot/commander ranks). It's also completely awesome.

Fjord Science!

I'm another who gets KSP from Steam but never runs it through Steam. And I get loads of crashes. And I'm on Linux and I know it makes a difference - running the game through Steam means it uses Steam's versions of certain system libraries instead of the operating system's versions, even before you consider the Steam-specific extras. Maybe I should try letting Steam do its thing. It won't be hard to add my modded KSP as a "non Steam game".

Well my experience is in FAR, stock can be significantly different. But so far my preference has been RAPIERs as primary propulsion, and Panthers as VTOL lift engines. The former offer simplicity and high jet speeds, while the latter have the highest static TWR of any jet in wet mode. In a design where the Panthers can thrust forwards, such as a "tailsitter" or a tilt engine/wing design, then they can do double duty - extra power to blast through the early ascent, and range extenders for approach and landing. Not enough TWR is a problem during the push to hypersonic jet speeds and the switch to rockets. One iteration of my 40 ton SSTO Gallifrey used four Panthers and one RAPIER, and I found the RAPIER just squandered its thrust fighting drag and it failed to make orbit. Switching to two RAPIERS and three Panthers, with everything else the same, made the difference - even though the airframe was a little heavier, it wasted less thrust as a percentage and thus made LKO. Ascent profile matters too. I admit I still know very little, but one thing I've found is it seems good to have some vertical speed before making the switch to rockets, that way you aren't pulling such high draggy AoA trying to pitch up to climb out of the atmosphere. A corollary is it's not so good to do the jet acceleration as high as possible where the plane can barely fly level, being a bit lower seems like it can be helpful. I like the various non-SSTO concepts suggested. Letting a chunk of mass go is not to be sneezed at. It might be fun to take an established SSTO spaceplane, and see how much more payload you can get out of it using drop engines or drop tanks.

Once is an accident. Twice is a coincidence. Wait until a third long-time member leaves this month, then we can start talking conspiracies.

I used to try and standardise action groups, but decided it was too much hassle with various different craft, Now I'd say the only constant is 1: Science!. After that it varies. And on a lot of craft I'll manually extend stuff like panels. I mean my Shuttle/spaceplane requires six action groups just for engines - engine switch, mode switch, and gimbal switch for the panthers and the rapiers separately. That would never work in a standard scheme. Plus a group to toggle the solars and radiators because I need to do that fairly often.

You can also move the vessel around by using the offset gizmo on the root part. This gives a lot more control over how the vessel actually moves, you can easily take it left and right without it also jumping into the background.

But then the part count limit can itself be lowered. Perhaps as low as ten parts, say, more than enough for a two-stage rocket.

Granted. It's a shark. It eats you. You can't fight it because it's incorruptible. I wish I was home.

I mooted a similar idea myself back when part tests were new. But rather than just outright failure, what I advocate is some "fuzziness" in the performance. The experimental part might perform nominally, or it might underperform, or it could even *overperform*. Or some mixture, like too much thrust and not enough Isp.

I don't really want that size myself. I find the existing part sizes fine for most purposes and think adding 1.9 m parts would be too "fiddly". Now if KSP moves to a more flexible model, then maybe that increment would come in naturally. But I fear KSP is too far developed now to switch, even though "procedural" parts would be far better in almost all respects IMHO.

Granted. It's got two fish in it. One says to the other, "How do you drive this thing?". Then they accidentally shoot your house. I wish .ica files would just open.

Meanwhile I feel the exact opposite - I won't let visual mods anywhere near my KSP install. I'd like to run them, but I feel the game performs terribly enough as it is, I can't afford to make it worse.

Exactly, and why IMHO moving them would not be appropriate.

Agreed. For my part it's PreciseNode, followed a close second by FAR.

Pictures? And did you use that "25x" piece by itself or with another eyepiece? I'm wondering if it wasn't a 2.5x Barlow lens, which is used in conjunction with an eyepiece to increase its magnification by the factor stated.

If you let CKAN install FAR, either as part of Realism Overhaul or otherwise, then ... that. Or completely delete the FerramAerospaceResearch and ModularFlightIntegrator folders from your GameData, then reinstall FAR manually, and see if the issue persists.

But doesn't the Mk2 cargo bay also offer body lift and durability?

Normally the decouplers will block fuel flow by default. But there can be situations that doesn't work as expected, perhaps if you constructed the ship in an order other than "top down". And if you used either jet engines, the Rapier (in either mode), or Vernor thrusters, they all consume fuel in a different way to normal rocket engines.