Fearless Son

Can I say how much I love your crew names?

The other night I returned the Seal spaceplane tanker from orbit. Overshot the KSC because I tried for too aggressive a descent but lacked the oxidizer pull off the full burn. Ended up over the ocean with just enough liquid fuel to get to land. Realized too late my flaps were extending the wrong direction during breaking, flipped the craft nose-up, came down hard on the back end. Fortunately it lithobreaked effectively. Lost a couple R.A.I.P.I.E.R. units but the thing fell over onto its wheels, otherwise intact. Managed to recover it and recoup most of the hardware cost. Decided to tweak the design incorporating these lessons. I had a surplus of monopropellant but maneuvering with it was sluggish, so I doubled the number of RCS ports. That lets me use up excess monoprop doing long-burn maneuvers to set up rendezvous without spending oxidizer and liquid fuel. Removed the breaking from the flaps, but I added a couple pairs of A.I.R.B.R.A.K.E.S. to the rear of the craft, as I lost some control during descent and it took me until just a few thousand meters above the ocean before I could recover control. Rendezvous and landing should be easier next time.

I feel like it needs a little something more. All the plants would instantly die if someone opened the hatch in a non-Kerbin biome. They either ought to have airtight enclosures built into the shelves, or have an interior wall flush with the ladder to have enough space for an airlock. I mean, with other parts that is less of a worry because the Kerbals inside can put on helmets and depressurize the entire compartment, but not so with the plants.

I agree with what others have said, a big part of your problem is that the center of thrust of those engines is out of line with the center of mass and lift, and the problem just gets worse at higher speeds. It would also wreck your maneuvering once you get to orbit, where it will want to nose-down every time you thrust with the nuclear engines. I would move the engines into a line with the center of mass. This might mean that you need to move the wings too, so that the base of the wing is attached near the top of the fuselage (if the engines stay below the wing) or attached near the bottom of the fuselage (if the engines get moved above the wing.) Either way, you will probably want to use the rotation tools to add a gentle curve to the wings to bring the center of lift back into alignment with the center of mass, even if the base of the wing is above or below that center of mass.

Just looking at that base I get a sense of dread creeping up on me, as if the Kraken knows and will visit its dread wrath upon us for our hubris.

Hey, any landing you can collect Science from is a success in my book.

Old joke, "Yeah, NASA faked the moon landing. They got Stanley Kubrick to produce the video of it for them. But he was such a perfectionist he insisted on on-location shoots."

Are we to assume that the lithobreaking was a *ahem* secondary landing option after the loss of a primary chute?

I wanted to make sure the Fission Star was topped off before I bring in crew or attach mission modules, so I developed a drone tanker SSTO spaceplane to bring fuel up to it: I call the tanker "Seal" and will post more pictures after I deorbit and return it to KSC. Almost ran out of oxidizer, but fortunately I had enough to make the rendezvous and I still had plenty of liquid fuel left over, so a powered flight back to the airfield should be easy. Come to think of it, by swapping some of the tanks the Seal would make a good tanker for other missions too.

Oh, no-no-no-no, I do not mean that it gets to Duna orbit from a different orbit, but that it gets to Duna orbit from Duna's surface. That is my fault, my wording was ambiguous, sorry about that. That was what surprised me. I know anything with any amount of thrust whatsoever can get between any orbit with enough fuel, regardless of its thrust-to-mass ratio. But I would not have pegged a bunch of 'Twitch' engines as lifting engines for an atmospheric lander of that size. I stereotype them as small probe lander engines or terminal-descent breaking engines, I had not considered them as an option for viable surface-to-orbit flight around an extra-Kerbin atmosphere.

Can I tell you how much I love those designs? In particular, I love how practical both of them look. The 'Cricket' looks wonderful as a non-atmospheric lander, with its strut-mounted RCS thrusters and asymmetric geometry mass balance. The 'Armadillo' is especially impressive as you made a stock atmospheric lander that looks like plenty of real life concept designs I have seen. I love the application of fairings to make that teardrop shape and the thrusters inside the intake housing look perfect. I am surprised you could get something that big to Duna orbit with just 'Twitch' engines though.

Frequently happens to me in early career games, where part count and weight considerations mean I sometimes have just less delta-V than it turns out I needed. Mostly I only need to do it enough to begin aerobreaking, as it is usually on the return trip when I run out (if it is more obvious before then I usually abort the mission.)

I hope you had Val remove the data from the Science Jr. before she tried returning to Kerbin. It renders the Science Jr. unusable without a qualified scientist to reset it, but it would at least save the valuable part in these cases.

Consider having a small, disposable "mothership" to stick the debris into before deorbiting it all at once:

I put a new interplanetary vehicle into Kerbin orbit. I call it the Fission Star: It runs on sixteen nuclear engines (four per engine pod) and is capable of non-atmospheric landings on its own. The wings both provide excellent liquid fuel storage as well as set the engine pods and landing gear well apart from the center of mass. This also gives it plenty of space behind it to attach other mission-specific modules, such as dedicated landers, base or station components, or supplemental fuel tanks. There are also attachment hardpoints under each wing for further fuel tanks, or in certain cases for additional boosters if it needs to make an atmospheric landing and launch. Speaking of atmosphere, the engine pods have a few A.I.R.B.R.A.K.E.S. each to enhance aerobreaking, where their wide spacing also offers additional leverage for atmospheric control. Building an appropriate launch vehicle for this thing was a challenge though, since a traditional under-the-payload booster would result in far too much drag in front of the center of mass to be controllable due to the wide wings. I had to go with four Mammoths, one on each side and raised high up on the craft so that the majority of the wings' surface area hung below them. The Mammoths each had additional orange drop tanks hanging down off the side of them to give their hungry nozzles enough juice to make it into orbit with enough left over for circularization. Probably going to refuel this in orbit (it intentionally launched with only a partial fuel load) and take it to the Mun for a trial landing (and another refuel) before I send it out-system.

Heh. I grew up reading Tintin books. Heck, I credit those books with actually teaching me to read. I struggled a lot in first and second grade, but when I discovered those books in third grade? My reading skill started improving rapidly.

I never leave a Kerbal behind. Ever. My first experience with the game was before science and career modes were added, and I did nothing but uncrewed launches and Munar landings until I was sure I had a good handle on playing the game, just so I knew I would not be risking lives unnecessarily. Indeed, any extra-Kerbin exploration I do usually involves sending probes ahead of me before I send crewed missions just to make sure I know what I am sending them into. Now, I have miscalculated and left a few brave Kerbals stranded, whether in orbit due to lack of fuel, on the surface due to lack of fuel, or after a survivable crash due to mistiming my landing burn. In that case my first priority is mounting a rescue expedition, usually armed with a little more practical experience with the specifics of the situation that got them stuck to begin with. I might, in theory, leave some Kerbals "on station" somewhere, either in a space station or a surface outpost, for an extended period of time. That science is not going to do itself! But always with the option to return them when the low gravity is taking too big a toll and they need to rotate back to Kerbin for some well-needed recuperative physical therapy. Have him drive that rover over to the top of a mountain (it might take a while.) Land a rescue craft on that mountain top. Should be easier than at see level (if still challenging.)

So of course this is right where my mind goes:

I was just on my way to see if someone posted that. Watching it give me flashbacks!

My first (successful) Mun landing. It was a one-way trip for a robotic lander with a detachable robotic rover (back when drag was more abstractly calculated so this was less challenging to get up there than it seemed.) I managed to touch down at just the last of my fuel reserves. Phew! ... then after I landed I realized that the fuel reserves were so low because I had installed the fuel lines backward and I still had a bunch of fuel in the central tank. Back then there was no way of transferring fuel mid-mission, so good thing I managed to be a bit overbuilt on the thrust-to-weight ratio!

I could not tell you why KSP specifically breaks, but I know of some processes that, if left to run long enough, have some really weird effects. For example, I once wrote a clone of Asteroids for a college project, with polygonal asteroids with procedural randomized rough edges that spin around at a random angular velocity. I left the game running without collision detection on Friday, came back to my class computer on Monday. All the asteroids had changed sizes, some getting really small, others getting really large. Turns out that small rounding errors in the floating point calculations for the asteroid vertexes caused the vertexes to either get further apart or further together, depending on the spin direction, and that those errors, while tiny, were cumulative and built up over long periods of time.

That is actually something a patch last year handled pretty neatly, by spinning the physics calculations for separate ships out to separate threads. The total part limit per thread might still be an issue, but two three-hundred part ships in an rendezvous will calculate like two three-hundred part ships, as opposed to one six-hundred part ship which is what it was effectively doing before. So long as you have multiple core CPUs (as most computers these days do) you have to try a lot harder to drag down that physics performance now than you used to. Fun fact: middlewear physics packages like Havok and PhysX are already heavily code optimized, and I speak from the experience of someone who did professional performance testing on a game that used one of those regularly. So long as you keep the physics objects under a budget, they run incredibly quickly. Unfortunately, anything that allows users to arbitrarily add things to the simulation is going to go over its nominal CPU budget at some point. As being able to add objects in various configurations and quantities within the simulation is pretty core to the KSP experience, I cannot see this changing any time soon.

I feel like the auto-strut feature has actually resolved this pretty handily. I mean, I think it is part of the intended gameplay design that rockets should be delicate in some ways, players should have to think about the balance of different forces on different parts of the rocket and weigh the benefits of strength/weight requirements of various pieces on various missions. That said, rockets should not be built out of matchsticks either, and a little forethought on the part of the player during the design phase should be able to overcome these issues. Manually placed struts are one of the ways this can be resolved, but the auto-struts are a more subtle way of doing it. They are there if a player needs to use them, but the point is that a player still has to think about how to use them if they do. I tend to think that kind of consideration is part of the fun, but as fun is subjective your mileage might very.

I sense a few unspoken assumptions among some commentators in this thread that I would like to address. First, there seems to be an assumption that Unity is a crap engine. As @Alshain pointed out, this is not true. Unity is actually quite a capable engine. Unreal or Cry Engine might be a little better optimized for super-high end rendering, but the differences are not all that much. I think this perception comes from the fact that Unity is one of the most accessible engines, which is a big point in its favor. It is very easy to develop for, very inexpensive to license, and very easy to mod for as well. However, its low barrier to entry means that Sturgeon's Law applies more liberally: it means that the crap does not get filtered out if someone decides to make crap using it. That is not Unity's fault. Second, there seems to be an assumption people are making about how optimization works. First of all, it is never a matter of "just tighten up the graphics on level three." Performance optimization is like a kind of careful balancing act. A seemingly minor enhancement to graphics in one part could lead to a massive performance hit somewhere else, or taking a seemingly "little" item out of memory might result in a drastically smoother framerate. So if someone says "I want better graphics!" the developers have to balance that against everything else they have going on in the game, which might have an impact outside of what the person asking for it thinks it will. Likewise, if someone says, "I want better perf!" they have to understand that might mean giving up something else that might otherwise be important. Sometimes you can make a few code tweaks that, on balance, gain you more than you lose, but those are the low-hanging fruit, and the gain is not always big enough relative to the effort it would take to make them. And sometimes what is being traded away to get it is stability, and I doubt anyone wants less of that. Finally, a lot of these kinds of complaints are from people who tend to use a lot of mods. Everything I said above about Unity and performance? That goes double for mod-makers. Unity's ease of developing for means that mods are easy to make, but that can also mean a lot of neophytes can end up making mods, and they might not be cognizant of everything they are trading to add what they put in the mod. Someone who loads a bunch of high-resolution textures for example could have a drastic effect on performance, especially if combined with other mods that do more of the same. Squad knows what they put into KSP and they limit it to a budget for a reason, but mod-makers do not have to fit themselves into that. And further, you cannot hold Squad responsible for what other people do to their game. Any mods you install are done at your own risk (to performance/stability) and Squad can only do so much to facilitate them. Unfortunately, the more they do the more likely mod makers are going to try and push the envelope. This is true virtually every time a piece of underlying technology gets better. Having both worked in Unity and worked on performance optimization for a major multi-platform AAA release, I felt the need to frame these things appropriately.

"RX-78 to White Base..."