Fraktal

Startup loading, about 5 minutes for the main menu to appear and another 3-4 for it to become responsive. Exit loading, around 15-20 minutes from KSC to desktop.

Which is nowhere near sensitive enough to maintain near-1.0 TWR without constantly switching back and forth every few seconds. It has about as much fun factor as circumnavigating Kerbin at subsonic speed in an excessively stable plane without SAS, trim and physics time warp.

No, because the thrust limiter does not account for TWR increase from fuel depletion.

I don't know if there'd be a point to a feature request, but... would it be too much to ask to have the [x]Science! Selected Object window not reopen every single time I switch focus in the Tracking Station?

Something I just remembered, was probably asked before. Hovercraft engine. Not VTOL, hover. Fairly low thrust to limit the hovercraft's weight and only produces any thrust at all within a few meters of the ground. Two versions: Monoprop-fueled, high vacuum Isp. Electric, thrust depends on atmospheric pressure. Both should be very late in the tech tree, somewhere after the most advanced rover wheels. Seeing how people don't like rovers due to how speed-limited they are due to crash damage, why not give them an option for building something that can semi-safely skim across level ground at high speed to cross large distances?

Began assembly of the Kerbin Gateway Station at the boundary between Kerbin's low space and high space. Core, power module and antenna module have been launched and docked together.I repurposed my JA-4 light-duty munar launcher (2 Thumpers and 2 Reliants around a single-Swivel core) for this but it turned out to be overkill, so subsequent launches used a standard JA-3 launcher (2 Thumpers and 1 Reliant). Core was the hardest due to its size (a six-axis cross of Structural Fuselages with an OKTO clipped into the center) making it both highly un-aerodynamic and too large to fit into a fairing (though it was still fairly light, hence I didn't have to use my JA-5 heavy-duty munar launcher). After several failed tries resulting in the rocket flipping over from front-heavy drag, I finally managed to get it up by flying directly upwards until 30+ km altitude and then starting the gravity turn up to 250 km. Subsequent modules launched up to 120 km as standard for all my launches, then rendezvoused with the station core at 250 km. Power module is plugged into the ventral docking port, antenna module into the dorsal port. Fore is planned to be a crew module (Hitchhiker Storage Module with flat adapters on both sides), aft will be the maneuver module (four Ants, fuel and a medium reaction wheel), port will be a science lab once I unlock it, starboard will be a second core module for docking ships. Long-term objective is a full overhaul and upgrade to medium-sized docking ports and eventually a dedicated universal docking module with 1 large, 2 medium and 2 small ports in a five-axis arrangement (sixth axis is the attachment to the station). I'm currently undecided over whether to have a dedicated module for escape pods (that is, a Mk1 pod with monoprop thrusters for a deorbit) or have the crew module detachable and heatshielded for that purpose.

Finalized the design of a "reach anywhere in Kerbin's SOI" lander and tested it with a land-and-return flight to the Mun's north pole. Got back with about 200 m/s left, reentry successful. While I'm waiting for a transfer window to Duna for my first ever manned interplanetary flight (I already have a rover on Ike), I've been thinking about looking into station construction for the first time. What do you guys think, should the core module be absolute-barebones with only an OKTO core, structural parts and docking ports, with a separate power/comms module, or should I combine the two into a single module? I don't plan on keeping it, mind you, as I already have better parts unlocked. Also, I'm considering modifying the design of my Duna spacecraft a bit. Current design is a propulsion/lander manned section and an external fuel tank launched in a separate flight and docked in orbit. Mission profile is launching the two separately, docking them together in orbit, using the external tank to reach Duna, undock, land with parachutes to preserve fuel for the return trip, take off, rendezvous in orbit and use the tank's remaining fuel to return to Kerbin. However, I'm thinking of outfitting the fuel tank with a HECS plus relay antenna plus solar panels and batteries for the first flight and leaving it behind as a permanent satellite / possible future station core so that later missions only need to bring fuel and short-range ground-to-orbit antennas. Taking off from Duna should use up enough fuel to fully drain the external tank and leave nothing behind. Should I go for it?

Reaction wheels do not produce nearly enough torque for any kind of meaningful control against the oncoming airflow trying to keep you at low AoA. Tailfins produce waaaaay more pitch and roll torque than what a starter plane needs. Transmitting science on Kerbin is, for the most part, pointless. With the exception of surface samples, any early experiments that do not require a scientist for multiple uses bring back 100% science on recovery and until you have the OKTO core, you can't bring a scientist without tacking on another 1.5 tons for the Crew Cabin because trying to fly long distances without SAS is a waste of your time. And yes, I know people said the Juno isn't meant for long-distance travel, but two Junos with two Mk0 and one Mk1 fuel tanks can reach any biome on Kerbin, including the poles and the badlands. If you engineer your plane so that SAS requires minimal pitch torque to stay level, you can reach the poles at subsonic speed in about 20 real-life minutes using 4x physical time warp. I did this with only starter parts and inside the 30 part limit; took me about 2-3 trips per biome, though.

The KSC doesn't have flying situations. You're either landed in the specific biome, or flying low above Kerbin's shores.

Also. Since the starter landing gear is so rickety, you can spare yourself a lot of headache if you just plain forget about landing on wheels. Bring a radial-mount parachute and pop it when you're above where you want to land; at starter weight, 1 should be enough. If the plane starts rhythmically hopping up and down on the runway, you are too heavy. Lose some fuel or bring another pair of rear landing gear.

Was that answer meant for Goody1981 or me?

No, there's something else going on. I run the game on 4 GB and it works fine for the most part - but when I fired it up today, it became borderline-unplayably laggy to the point where it had 5+ minute loads, the entire window flashing while the game is frozen, Windows repeatedly graying out the screen and throwing up the "application not responding" popup, and the game window minimizing after long flashing sessions. At one point, I Alt-Tabbed out to Task Manager in the middle of one of these seizures without pausing the game; it showed 24% CPU usage, 85% RAM usage and 100% disk usage of the Windows system process hogging the pagefile to the point the game completely froze for nearly 10 minutes because it was waiting for drive access. Even quitting the game took 30 minutes to even show the menu and after clicking Quit, it brainstormed for a few seconds then crashed with this stackdump: I didn't even install Breaking Ground, yet something evidently changed in the executable, as it never did this before.

One leg kicks back with enough force to flip a lander 90° to its side before SAS stops the rotation. You try to get it back up, the instant one or even two legs are holding the lander's weight at about 160° from directly downwards, the leg(s) kicks out with enough force to literally send the lander flying sideways. You somehow get the lander back upright on its engine with legs retracted, then extend the legs, the lander does not rise off the ground, it jumps with enough force to become airborne for a full second under munar gravity. Granted, I've seen this behavior with the micro legs instead of the ones in the video above, but still. It's normal behavior for the legs to compensate for being compressed by exerting more force against the compression. The problem is that said compensation is far too quick and far too strong, resulting in rapid and massive overshoot. But there isn't much choice there: if the compensation is too powerful, it overshoots; if it's not powerful enough, it oscillates (ie. bounces up and down endlessly, mostly seen when you build a plane that's overweight for the starter landing gear) and people were up in arms when the latter happened in 1.5. Getting it just right would take literally hundreds of hours' of trial and error and Squad isn't going to invest that much time into a bug that isn't game-crashing.

They still kick out with excessively disproportional force when compressed, for one.

The problem with this is, what server would that patcher be connecting to? Because if it would be a Squad server, everyone would be hosed as soon as they dropped support for the game and pulled the plug. And rest assured, they will. Whether in 2030 or 2040, doesn't matter. What matters is that core functionality should not be hardcoded to require a single, fixed remote machine. It would be convenient, yes, but giving the devs an instant killswitch to permanently render every copy of the game in existence unplayable with as soon as it's no longer profitable has already killed multiple games in the past. Modding with the Sword of Damocles hanging above your head ready to render all your modding efforts null and void as soon as the IP holder's executives say so is an atmosphere I don't think many modders would enjoy working under.

Can you write one for 10% science returns as well? If not, some observations. Harvesting the KSC is no longer optional if you want to reach the Mun with anything other than an ultra-minmaxed craft beyond the skills of a beginner player to design. Consider getting KEI; I've done without it, but it's really tedious and doing a land-and-return mission to the Mun without a Terrier is so touch-and-go in terms of fuel usage that I'd rather not have to do it again. Focus on unlocking the bottom-most nodes at the beginning. That's where new science instruments are, which in turn will help you unlock topmost nodes. Being able to fly further is nice, but not if you get deadlocked by having exhausted all science options but not having the points to get more science. Three goo canisters are generally enough to not have to land in the same biome again. The Science Jr. is a bit harder nut to crack, as I've found (in LKO) it requires as much as four measurements before it stops giving any more science, but returning that many Science Jr.s through reentry is difficult. Two is optimal, as it means you can finish both low and high orbit in 2-2 flights. However, don't bother putting more than one of each instrument on a probe not meant to return to Kerbin. Transmission loss means you won't benefit from sending more than one package. Of course, you do need LOS or a relay to transmit, so keep that in mind. Speaking of which, three Communotrons (not the surface-mount ones!) or two High-Gains are required for Minmus with a level 1 DSN, if you go with direct connectivity; for relays, the lander only needs one Communotron to reach a relay with the above antenna configuration in munar geosynchronous orbit, and even then the signal is going to be weak. Invest in the first aircraft node early and harvest Kerbin bare. It will return the investment with interest, trust me. Later nodes are unnecessary until after you have a working interplanetary ship design. Probes are optional but highly recommended. Spending 90 points on the OKTO will just barely return the investment to unlock one more node from the Mun, yes, but it will help in building a better lander. Once you've got the OKTO, you can now take a scientist in the lander, allowing you to both transmit and return science in the same flight for maximum yield.

Okay, it's just that I've always been hearing the opposite from everywhere.

Good idea, though I have a question: how to reconcile part size differences? I mean, if there's only an attachment node in the middle, how to attach something half the node's size? Similarly, if there are two nodes for half-sized parts, how to attach a full-sized one? Also, though someone might very well correct me on this, if there are attachment nodes for both of the above scenarios but only one is used (there would be clipping otherwise), wouldn't the nodes not being used cause drag?

Did some experimentation with starter parts and managed to cobble up a three-stage rocket capable of reaching 50 km altitude on nothing but Flea SRBs and actually coming back down safely instead of nosediving into the ground like my previous Flea-only designs did. The key to a safe landing? Squeeze in another Flea between the last stage with the lowest amount of fuel allowed by the game (enough for a 0.9 second burst at 100% thrust) and pointed in reverse. When activated, it explosively decouples the command pod by burning away the girder attaching the pod to the rest of the rocket, allowing the pod's aerodynamics to safely slow it down to parachute release speed. Highly unconventional use of a Flea, yes, but it works and realizing that it does was fun.

The starter wings have such little lift compared to the weight of the aircraft that the plane stalls out before reaching safe landing speed. And once again, mounting more is a no-go due to part count limits. Drogue chutes are suboptimal for landing a plane because you can't toggle them off if you find you're slowing down too quickly and airbrakes are not available until much later. I don't have any problems landing with the retractable landing gear, mind you (I crash with them far more often from tipping over than from the landing gear being destroyed). It's just the fixed, rigid ones that are giving me trouble, hence I only use them for takeoff and rely on parachutes to come back down. Hell, I would stage them off entirely after takeoff if I could.

There's the problem. I'm incapable of landing with anything less than ~160 m/s if I don't have airbrakes (and you don't get those until tech level 6). Wheel brakes are nowhere near enough and make me veer to the side and tip over, braking chutes are just plain insufficient.

I wanted to amend this statement with one situation where 30 parts as starter limitation feels too restrictive: plane design. I've ran into situations when designing early-game planes where I was forced to compromise between payload part count and control surface count in order to stay within 30 parts. The absolute minimalist starter plane design, without payload: Mk1 Cockpit - 1 part 2x any wing - 2 parts Vertical tailfin - 1 part 2x horizontal tailfin or canard - 2 parts 2x Juno - 2 parts 2x Mk0 LF tank - 2 parts 2x Small Circular Intake - 2 parts 3x any landing gear - 3 parts 2x parachute because the starter landing gear is pretty much useless at actually landing - 2 parts 1x Structural Fuselage OR Mk1 LF tank to mount the wings and engines onto - 1 part 1x nosecone to close off the main body's rear attachment node for aerodynamic purposes - 1 part 4x Elevon 1, if I'm not using the FAT wing - 4 parts That's 23 parts, leaving 7 parts for the payload. If said payload is just a Crew Cabin, there's no problem. But if I'm building a plane for gathering science from the polar biomes and would prefer not having to make repeat trips due to how long it takes even at 4x physical time warp, 7 parts is a bit short: Service bay - 1 part Thermometer - 1 part Barometer - 1 part 3x goo canisters - 3 parts 3x materials bays - 3 parts That's 9 parts, 2 parts too many for the level 1 SPH limit of 30, forcing me to ditch the Elevons and rely entirely on the tailfins for attitude control.

Well, he would've figured it out anyway that doing what you wrote would be an unstable configuration once he tried it.

Other way around. Center of mass just in front of the center of lift.

The problem is that the configuration I described above hits the ground at supersonic speed regardless of whether it falls prograde or retrograde. Only if I struggle against aero forces to make it fall sideways will it slow down to the point where the parachute releases, but even then not always - and even doing this is damn hard, as a Mk1 pod with an RT-5 attached to it has no attitude control whatsoever once it picks up speed.