Timmon26

Hopefully sometime this month, fingers crossed? Really depends on Dakota and I being able to wrangle a few unsuspecting test subjects co-workers on relatively short notice. I already have the slides prepared for the next one though. We'll be going a bit more in-depth about ISP, covering launch vehicle control and stability, then flying efficient gravity turns in-game.

Hi, all! Last Friday we did a livestream of our KSP Academy: Rocketry 101! This started as an internal Slack channel where I could give KSP lessons and post tutorials for the Community Team or new Intercept hires who were new to the KSP franchise. We decided we should start streaming them, and the first lesson is now up on Youtube! This stuff probably pretty basic for you all, but it was a lot of fun to make, and I hope you enjoy! Some corrections: Escape velocity from LEO is closer to 11km/s, not 8. That's LEO orbital velocity. The boiling point of LH2 is about 20K, not about 3K. That's liquid helium. (See, even when I'm wrong about things, it's only because I'm right about other things. HA! ) Class slides (click to view in full res):

Thanks!

I was just wondering about this the other day. I also think the "Abstract Network" is the most likely solution and the way to go, even if it is a bit gamey, particularly since it's so robust. I totally agree with this. Setting up low-consumption flight paths is hard and time consuming and players should be rewarded for pulling it off. It's pro-problem-solving and anti-grind game design. Might not be absolutely realistic, but it's an acceptable abstraction. ____ Some hiccups with the Abstract Network though: Let's say you have a colony Alpha producing 100 widgets/launch window. You want to ship these widgets to colony Bravo, but Alpha doesn't have the best shipbuilding infrastructure yet and can only build and launch a small ship carrying 10 widgets. So you do that, and save it as a delivery route: 10 widgets, Alpha -> Bravo. Cool... But once you've established that as a delivery route, in principle there's no reason why you couldn't multiply it. "Hey, Alpha, just send ten of those same ships per launch window, okay?" 10 widgets, Alpha -> Bravo, x10. Now you have all 100 widgets going from Alpha to Bravo per launch window, despite Alpha's low state of development. This is how things might work in real life, with Starships colonizing Mars for example. Hundreds or thousands of Starships could be loaded and staged in LEO, then depart all at once in flotillas every two years. But is that fair in the game? Should there be a button in the Delivery UI to duplicate export shipments up to the maximum a colony could support? Maybe, but it would obviate the need to launch bigger delivery ships, which would eliminate that as a design challenge for the player. I'm sure bigger ships could be more efficient and replace the smaller ones later, but still... Okay, so let's say you don't include a multiplier button. Well now you've just incentivized the player to manually launch 10 identical low-tech transport ships, stash them in orbit, then have them all burn for their destination in one launch window. That's the same as doing the first delivery route x10, just grindier. Might as well give the player their route multiplier button back and save them the trouble. Mining missions have this issue too. If a colony sends out a rover to dig up and return 100 ore from a nearby deposit, can the player just... do it again and make 200 ore? Then 300 and so on until their colony has an unreasonable income due to grind? What's the launch window for a mining mission? Nearby craters don't have synodic periods. One option is to simply restrict the number of abstract delivery routes from any colony A to any colony B to 1 ship per window. This is quite unrealistic of course, but now all of the trade from Alpha to Bravo depends on one ship design and one flight plan, which seems in the spirit of the game as a rocket design and astrogation challenge. The amount of resources transferrable from Alpha to Bravo depends on the player's design of one ship for that purpose, and larger more ambitious designs are incentivized to maximize payload. It simplifies things a bit further too, in that there's now only one route to be replaced if the player launches a new mission to update it; there won't be a mess of different ship designs going from A to B to keep track of. Resource locations could also function as "colonies" for this purpose, so players will need to make their mining missions count. Of course, this creates the problem of having to constantly design new ships to update your delivery routes as your colonies grow, which is its own brand of grind. Maybe the delivery multiplier button is the best option and only the prospect of better ship design or flight path efficiency creates the incentive to update delivery routes. TL,DR: I'm confused and I hope the developers aren't.

Got a pumpkin this year that was suspiciously Kerbal-shaped.

Here's the SP-100, the kind of reactor the one in the screenshot was likely based on. Space fission reactors tend to be conical so shielding can be minimized – everything is designed so that sensitive bits and the rest of the spacecraft can fit inside the radiation shadow of the shield. In the screenshot, some of the outboard fuel tanks and radiators look like they're still in the radiation zone. Hope that won't cause any problems

You should always be in one star system's SOI, no matter where you are in interstellar space, as long as we're assuming patched conics. Although it's less of a sphere of influence now and more like a "cell" of influence. A local map of SOIs would resemble a 3D Voronoi diagram, although not exactly because the stars have different masses and the boundaries would be convex or concave.

Here's my spitball attempt at a highly simplified life support design that still ticks most of the boxes. This is based somewhat on my speculations on colony LS detailed here... ... as well as the Snacks mod and similar ideas. (Ships ought to work a bit differently from colonies though) _____ Per the poll, I think life support should be nonlethal on colonies, lethal on vehicles, and take into account food, radiation, living space, flight time, and power. All direct consumables like oxygen, water, and food are rolled into one resource - Snacks. Kerbals each consume 1 snacks/day (every 6 hours) and turn them into 1 volatiles/day. Snacks/Volatiles are stored in radial or inline pods that come in a few sizes and their flow to kerbals obeys crossfeed rules. Command modules and space suits also have token snack storage. Kerbals must continually consume snacks (as if it were electricity) or become Starving. Starving kerbals live for some number of hours to days before they shrivel up like raisins and die. Starving kerbals lose access to class abilities. Upon entering a craft with available snacks, kerbals immediately lose the starving condition and return to normal activity. ECLSS modules are radial or inline parts that provide recycling and reduce the rate of snack consumption on the vessel by some factor (I picked 0.9 because that's the reclamation efficiency of the ISS's ECLSS but the factor could be anything for balance). The parts come in a few sizes and each has a certain capacity (points?) representing the number of kerbals the module ideally supports. These points can be stacked with multiple modules. If there are more kerbals on a vessel than the ECLSS modules can support, the reduction in snack consumption is reduced, reflecting the oversaturation of the environment systems. Snacks can only be 100% reclaimed from volatiles by colony greenhouses. Vessels always experience losses. Bunks represent the living space a kerbal needs to be comfortable on a long trip. Habitat modules like the Hitchhiker provide bunks. A Kerbal with a claimed bunk on their vessel will remain happy indefinitely. A kerbal without access to a bunk (if you didn't include one or they left their ship temporarily on a rover mission or something) will remain happy for some number of days before becoming Grumpy. A grumpy kerbal loses access to class abilities. Upon returning to a vessel with an open bunk, a grumpy kerbal becomes happy again. Bunk-providing modules generally require power. Kerbals can handle a certain amount of constant radiation flux up to some threshold (in watts). If the threshold is exceeded, the kerbal becomes Irradiated for the duration of the exposure. While irradiated, kerbals lose access to class abilities. Radiation sources include nuclear engines, radiation belts, and stars. If kerbals are exposed to a radiation flux past a second, higher threshold, they melt and die. Basically, walking on the Mun is fine, standing next to an active fission reactor is bad, and staring into a running open-cycle NTR is deadly. Kerbals also have a limited endurance for space missions, and eventually will go Space Crazy. Kerbals that have gone crazy lose access to class abilities and must return to Kerbin or a colony for them to be restored. Craziness typically takes a long time to set in; probably a few Kerbin years. The statuses and cutoffs above would be affected by a Kerbal's Level and their attributes - Courage and Stupidity. Higher level kerbals take longer to starve, can handle more radiation, and can stave off grumpiness and craziness for longer. Courageous Kerbals tend to be bad a rationing and don't heed radiation warnings, reducing their starvation time and radiation thresholds, but they're better at staying happy and sane no matter their living conditions. Stupid Kerbals' small brains require less food, and are highly resistant to boredom. But they tend to wander into radiation fields and become upset if they aren't kept comfortable. I like reversible class ability loss, then outright death, as consequences of life support failure. Class ability loss would be punishing but not crippling, hurting the player for making suboptimal or unrealistic decisions but giving them a way to recover. Death only occurs when the player truly screws up, like forgetting to pack any food or blasting their kerbals with NSWRs. I don't consider kerbal death unfair so long as it comes with forewarning. If the UI gives the player enough information, like how long a trip will take and how long their Snacks will last, then packing enough life support for a mission becomes part of the play/fail/learn/play loop just like packing enough fuel. Space missions revolve around time, and it's reasonable for time limits (what life support effectively is) to be a part of that gameplay. ____ Colonies, on the other hand, are a whole other ballgame. The purpose of colonies is to be sort of like "checkpoints" that the player builds themselves; safe spaces they can retreat back to or sortie out from as they explore deeper into space. They should be more or less closed-cycle and never fail once established, and their life support systems have to be stable for the colony to grow at all, making them effectively timeless and impervious to time warp, much like KSC already is. Of course, for this to work, the technical division between what is a "colony" and what is a "vessel" needs to be precisely defined.

Really, no one's gonna make a Command & Conquer joke? Okay.

When it comes to mining gasses from atmospheres (let's assume planetary and not stellar to keep things simple), there are generally two proposed methods. The first is to drop a refinery into the atmosphere, a big airship basically, held aloft by either lifting gasses or heated air. This refinery would take in atmosphere, crack whatever propellants you need out of it, liquify them, and store them for visiting spaceplanes and rockets. This was the method proposed for fueling Project Daedalus. The main problem with this is that in order to get the mined fuel into orbit, your visiting tanker ships need to accelerate it up to orbital velocity from near zero, fighting gravity and atmospheric drag and all that, presumably in a deep gas giant gravity well. So there are a lot of losses getting the fuel to orbit, naturally, and your tanker ship needs to be fully reusable and capable of reentry, docking with the airship again, blah blah it's a hassle... The other method is to collect fuel gradually from the rarified upper atmosphere, with some sort of dedicated scoop ship, while near orbital velocity. This has been proposed as early as 1959 in the form of PROFAC (PROpulsive Fluid Accumulation), and ToughSF has a good rundown of the method here. The scoop ship doesn't have to be especially aerodynamic, it just needs to have lots of frontal area for collecting gas. Basically the main problem with this method is power. Your scooper needs power to cool the incoming (at orbital velocity) air so it can be stored as a liquid, it needs power to perform whatever ISRU chemical conversions are needed, and it needs power to re-accelerate the collected air back up to OVER-orbital velocities with some kind of rocket engine to counteract the drag forces so it doesn't re-enter. This suggests some kind of high-Isp electric engine is probably needed, like a plasma or MPD thruster. The high power requirements could be met by a nuclear reactor or gobs of solar panels (stretched long and thin along the scoop's main truss so as to not increase drag). The scoop will also need substantial radiators to handle the heat from the engine, reactor, cryocoolers, turbomolecular pumps and such. An alternative source of power could be via remote beaming, from one or several laser satellites or stations in higher orbits. The overall mass of the scoop ship almost doesn't matter, only the frontal reference area and the available power, as these determine how much drag the ship experiences and how much it can overcome with thrust. Somewhere along the scoop's truss will be a number of tanks that will slowly accumulate propellant. When the scoop is full, the engine throttles up to kick the scoop into a higher orbit where it will rendezvous with a depot or waiting ship. The propellant is offloaded, then rinse and repeat. With the delivery routes system in KSP 2, player's should be able to model something like this, by launching a scoop ship from a space station and recording a delivery mission with it. If there won't be any aerostat colonies or vehicles in the game (no evidence so far), it'll be the only practical way of mining gas giant atmospheres, which are realistically the best source of He3.

Haha, if only! Hire me, Intercept! Sometimes I draw things, sometimes kerbals, sometimes decently! I did this in Photoshop, but first made a very simple model in Blender and took a screenshot of the wireframe to give me a guide for the perspective.

AAAAAAH, I almost missed this! I only just saw this thread Monday! Would've liked to have added more details and funny things going on, but I wanted to make sure I made the deadline.

Learning 3D animation by testing a tripod walk cycle, which the big herbivores will need to move around... This is the left>right>back cycle. There's a case to be made for the L>B>R>B cycle but I thought it overworked the back leg too much. Since the abdomen is unsupported when the back leg lifts, it needs to be counterbalanced, so I had the long neck jut forward during the back step to act as a counterweight. This suggests even tripods that spend most of their time on three legs should still have their centers of mass just behind the front two. Probably not the most convenient walking strategy for poor Mr. Stompachonk; I guess that's why we don't have any true tripods in real life.

It definitely looks like a Z-pinch engine. If you look close you can see the ring of capacitor modules like in the HOPE design. Atomic Rockets says these get ~38 KN thrust at ~19,000 seconds Isp, vs Daedalus' 7.5 MN at 1 million seconds. That suggests an interplanetary ship.

Found some time to get some more work done on these and have updated the OP. In addition, I've decided to finally buckle down and learn Blender to possibly bring some of these guys to life. The results of Day 1 (I have no idea what I'm doing): Assuming I manage to produce a game-ready asset eventually, would anyone be interested in trying to mod some critters into KSP1, as a proof of concept? I don't have experience in these matters, but I should think it would be possible to piggyback on the surface feature system to randomly scatter aliens around other bodies like Laythe. I'll start a thread for it in the addons forum if anyone's interested.

So this kinda blew up when I wasn't watching. Don't worry guys, I haven't forgotten about these. There won't be a "Part 2" but I'll be adding drawings to the original post periodically. As far as something like this being in the game on release, I actually hope it isn't. I want my spaceflight/colony simulator ASAP, please. Adding aliens to Lapat, not to mention doing them justice, will take a lot of dev work, and will represent a shift in artistic focus from hard-surface modeling, terrain modeling, and physics optimization, to organic modeling, rigging, animating, and AI. AFAIK, there're only one or two creature-style rigs used in KSP2 - for the Kerbals - and they don't have any AI that we know of. However, I do think something like this can be done, but only as a DLC after the core game has shipped. My understanding is that the artists on a big project like this will usually get their work done first, then the second half of development is the engineers squashing bugs, so the artists need something to do between late alpha and gold that can be easily added to the game after release. A suite of funny aliens to sprinkle around on Lapat would seem to me to be a more art-heavy than code-heavy project, so something like this could fit the DLC bill. The question for the devs will be, is the time and effort to bring all these animals to life worth getting what is basically Surface Features 2.0?

Encountering a recurring issue and I can't tell if it's a bug or what. When designing a new craft I'll naturally check to make sure the center of lift is behind the center of mass, including both when tanks are full and drained. Invariably, when designing spaceplanes or similar craft, a CoL placed ahead of the CoM will have moved behind the CoM after test flying the craft and returning to the editor at least once. Here's a VHTL plane I was working on and the CoL was well behind the CoM when I launched it (with both full and dry tanks). It flipped out on reentry so I reverted to VAB and the CoL was suddenly here: This explains the instability, but it would have been nice to have known this was the true CoL beforehand. This has happened with every single VTHL spaceplane I have ever built. KSP is apparently able to calculate the true CoL, but will not until the craft has been launched, otherwise it will show the CoL as being behind where it actually is. Naturally this makes adjusting control surfaces unplayably tedious, as a flight is required between each adjustment. Has anyone else encountered this issue or can replicate it?

Like others are saying here, the biggest problem beginners face when doing anything new in KSP, like precision landing, is not lack of fine control over their ships that they need an autopilot to make up for, but lack of information they need to approach a situation without doing a bunch of scary math. The Trajectories mod doesn't automate anything but is absolutely invaluable for the information it provides. With just the Time-to-Impact and Impact Velocity indicators, you have almost everything you need to perform a close-enough suicide burn anywhere you want. I suspect players who learned by watching MechJeb would find that they could learn just fine, maybe even better, if the game just had better tutorials (which we're getting) and flight planning information available. The one main advantage of autopilots is the reduction in the tedium of flying dozens of missions to LKO to build up the infrastructure to do anything interesting beyond it. Right now, progression in KSP is like having to replay all the previous levels in a game that you've already beaten, again, before you're allowed to advance to the next one. But the delivery route system in KSP2 may actually help eliminate this problem. By using delivery launches to cache resources and production facilities in orbit, players may be able to reach a point where they never have to launch from Kerbin's surface again if they don't want to. As the player's colonies expand outward from Kerbin, there's decreasing need for them to ever retrace their steps. I'm hoping for something like this myself. A stock autopilot won't be a crutch so long as its functions are earned over time by the player's manual actions. Launching enough times into orbit unlocks AscentGuidance, manually rendezvousing unlocks InterceptPlotting, manually docking unlocks AutoDock, landing on a pad unlocks DescentGuidance, and so on. These functions could be tied to Kerbal pilot experience (although that may encourage players to grind out training missions so their pilots have all the "skills") or scientific data, e.g. DescentGuidance is unavailable on planets with atmospheres until you've collected atmospheric pressure and composition readings. A slow rollout of autopilot functions over the course of a playthrough can hopefully mitigate tedium without spoiling the game at the same time.

It's just a small payload atop tapering fuel tanks, with six aerospikes and an inflatable heat shield for reentry. Has about 3.5-4km/s dV and a TWR of 1.4 or so, depending on the payload mass. It's not as fuel efficient as an equivalent HTO space plane, but it sure is expedient - just flies straight to orbit, then reenters like a capsule with parachutes. This design can't land without crushing the heat shield, so it has to splash down just east of KSC. Definitely improvable with a few tweaks, could maybe lose the heat shield if the engines won't explode... I just needed something to GTFTO quick. The closest real life equivalent is probably the DC-X.

Visited the artificial gravity station I'm building with a new reusable SSTO ship. The station will take six more launches to finish the contra-rotating lab and habitation sections.

I sent Bill, Bob, and Jeb on a mission to the edge of Duna's northern polar cap to collect science from six different biomes (Science mode, hard settings). The launch of the Duny I rocket: The Duny I spacecraft consists of a nuclear mothership carrying a science base rover, a hab module, and a descent/ascent command module to return the crew to the mothership from Duna, and land them on Kerbin later. Kerbin departure and Duna arrival: Bob and Bill descend in the base rover. The rover is equipped with parachutes and monoprop jump jets for landing and hovering. After collecting science from all six target biomes, Jeb lands the command module to pick up the crew. Bill repacks two of the parachutes for the Kerbin re-entry and Bob transfers the experiments. They pose for a photo op before heading home. Thanks to my massive overbudgeting of dV (I forgot to account for the gains from leaving the rover on Duna), I'm able to capture the mothership into LKO instead of ditching it. Hope to reuse it for future missions. The command pod makes an easy descent: OVER 9000 science from one mission to Duna, and without a lab. Nice.

This post is a bit hard to categorize. It’s part fan art, part suggestion, part general discussion topic, and part personal creative exercise. Mods, move this if necessary. In the Celestial Architecting video and latest atmospheric scattering show and tell, we saw a planet in development called Lapat that was apparently covered in vegetation. While the devs have been cagey about the possibility of complex life on other planets, I think this provides us with ample grounds for rampant, optimistic speculation about life on Lapat, particularly animal life. This post is my “blank check” wishlist for the kinds of things I’d like to see. In designing these alien animals, I'm trying to keep things both within the bounds of scientific plausibility and KSP's art style. With kerbals setting a precedent for the kind of life appropriate for the KSP universe, we can assume that any alien animal life will, like kerbals, be fairly simple, colorful, and funny-looking. Staying rooted in biology, the aliens also have to look like they're related to each other, but not to the kerbals. It should be possible to identify different phyla and draw speculative cladograms, but the Lapat family tree should still be kept fairly simple (like how the planetary systems are simple "toy" versions of real life). All major ecological niches should be filled, and we can expect that the Lapatians have found recognizable ways to fill them by convergent evolution, e.g. there will probably be things like "whales", "lions", "turtles", "birds", and "crabs". The animals must also be reasonable to implement into the game as animated actors with limited AI, hypothetically as DLC or something; so no intelligent aliens allowed, nothing so complex that the game becomes all about them and not the rockets. Gameplay-wise, aliens should be like mobile surface features for the player to find and catalogue. I have a loose family tree that in mind that I'm building as a draw these. I wanted most of the dominant "vertebrates" to be tripods because it's simple, funny, and creates weird design constraints. We also have to have to goofy-looking bugs and squid things of course, since you can't have an alien planet without those. I decided that all the eyes should be just like the kerbals': white spheres with black dot pupils. This is the KSP version of a camera eye, which has developed in many unrelated species on Earth by convergent evolution, and is one of the features we would expect to see in real aliens if we ever found them. So not only are the googly eyes funny, they make scientific sense in-universe if we assume the kerbal eyes are "typical". Anyway, my wild speculations follow. I will update this post as I add to the list. Life on Lapat, A Traveller's Guide: Stompachonkus seesawi Stompachonks are the dominant herbivores on Lapat. Their enormous size makes them unassailable by predators, and their long necks allow them to reach vegetation anywhere. Like all members of phylum Tripoda, they have three legs, and while they walk on all three, they can stand on their front two, which they often do when they eat low-lying plants. The rear leg acts as a counterweight to the neck, allowing them to stand in one place and hoover up grass like a bucket-wheel excavator. Chungutherium hedbutti Chungutheres travel in herds across Lapat's savannas, feeding on grasses and other ground-level plants. Their antennae are encased in large bony sheathes that they use as weapons, to contest dominance with other chungutheres and to repel attacks by large predators. Jumpalopus hippidihoppidi Jumpalopes are nimble herding herbivores. When threatened they can leap great distances and bound across Lapat's plains at high speed. They often find themselves running desperately from... Cursorus Vex C-Vex is the apex land predator on Lapat, running down and chomping its prey with its massive jaws. Unlike most other tripods, it moves entirely on its front two legs, its third leg being entirely modified as a tail counterweight to its massive head. This bipedal stance is an evolutionary holdover from its flying cousins like the Duffin, which perch on two legs when landed. Dromidudius wileium Dromidudes are small, nimble land predators. They are extremely fast and will chase down anything they think might be mocking them. Thankfully they seem uninterested in prey that's kerbal sized or larger. Smeerpium mintyleafium Smeerpies are tiny and ubiquitous herbivores. They can jump high in the air when threatened and their antennae are long and leaflike to disguise them amongst Lapat's grasses. Dromidudes interpret this form of camouflage as mockery. Duffus duffus Duffins are a plague. They are stupid and they are everywhere. Avoid flying your rockets through flocks of them. Thtorkus nosedivius Thtorks are Lapat's seabirds, patrolling the cliffs and coastlines of Lapat's oceans. They will patiently soar on thermals until they spot something in the water for them to dive upon and spear with their pointed head. Dagronium lockheedi Dagrons are large, predatory, flying tripods that mostly hunt other fliers like thtorks and duffins. They are solitary creatures that build their nests on remote mountain tops and cliff edges. Although their names sound similar, they should not be mistaken for dargons, and certainly not for dragons. Galumphagumpis swirlitops Galumphagumps are the turtle-analogs of phylum Noodleboia. They use their four proboscises as legs, stomping on and swallowing appetizing herbs as they walk. They can retract into their spiral shells when threatened. Their secondary appendages are modified as manipulators which they use to dig for food. Like all Noodlebois, they are radially symmetrical and have eyes on both sides of their bodies, providing 360 degree vision. Dippidorpus kyklopter Dippidorps are flying "insect" noodlebois that feed mostly on carrion or decaying plant matter. They're mostly harmless and mostly annoying and often preyed upon by Duffins and Dromidudes. [To Be Continued] _____ If there is ever to be alien animal life in KSP 2, I think it needs to be a balanced combination of silliness and plausibility. It needs to make you laugh first, then think "hey, that kinda makes sense". This bestiary is my humble attempt to check all those boxes and make a desperate case to the developers that they should add aliens to the game, because... I want them. Really bad.

Yeah, that's a downside to stock landform names. A renaming function would fix this, but even if there wasn't one, I think the benefits outweigh the drawbacks. In almost ten years of head canon, almost no fan consensus has emerged about what to call specific places, aside from the canon biome names. The one exception may be the mohole, which was canonized in response to fan consensus. So I don't think people will mind if the landforms are named in advance by the devs. It also gives the devs another creative channel, as it's an easy way to world-build, and many of the labels could be humorous, based on easter eggs or in-jokes. ____ This is a bit of a tangent, but landform names being revealed as players discover them would tie into the exploration system. My hope is that planets and moons won't be detailed at the start, and will only become visually interesting when players actually reach them. Exoplanets and exomoons initially won't be visible in the map at all, and once discovered would only present as indistinct spheres. Direct telescopic observation from Kerbin (or within the same system, for exoplanets) would reveal rough shapes and colors. Only when a player gets up close will the landforms of the planet appear, at which point they would be given names. From there, the player can do more detailed scans to find biome boundaries, resource deposits, and anomalies. Something like this:

This is more of a cosmetic thing, but I'd love to see the landforms and regions on different planets named and labeled, in the style of an atlas, like this NatGeo map of Mars: The labels would follow the curvature of the planet and bend around natural borders, as if they were printed on a globe, and could be toggled on or off along with the biome overlay. Here's how the Mun might look from space: Labels would only appear after the landform or biome was discovered by a telescope or overflying spacecraft. I think something like this could give players a real sense of direction and place within the game world, which is sort of lacking in KSP1. It's often hard to tell apart the islands of Laythe or craters on Tylo; one region is the same as the next. Having consistent names for all these places would also give the community a sense of continuity when they share stories of where they've been or what they discovered. Having proper names for landforms is a lot more convenient than having to refer to "the big island" or "that little archipelago west of KSC, you know, the wiggly one". The major landforms would be custom named by the developers, while smaller ones could use a random name generator like KSP1's waypoint naming system.

I mean it ought to. And not just for crew modules but for probe cores and scientific experiments too. The Pioneer probes had their RTGs mounted on booms to keep their radiation from interfering with science instruments: I'd love to see players do this for gameplay reasons instead of just role-play. Giving nuclear powered parts restrictions on where they can be placed relative to other parts makes for much more interesting game balance than simply making them more expensive or heavy to offset their usefulness. The more I think about it, the more I like radiation as a mechanic, because it will force players to use good design principles organically, in a way that can't be brute forced... Well, that or everyone just adopts the adage MOAR SHIELDING! to go along with MOAR BOOSTERS and MOAR STRUTS!