Ryu Gemini

So is it actually possible to mess around with the "building/structure" objects in this game much via mods?

Indeed. We may not be able to have what would effectively be a scaled down weather prediction program in KSP. But I don't think we really NEED one if we just want weather conditions in our simulator, and there is likely a way we can get weather that is "good enough" for being reasonably sensible in the way it works. Hence some of my thoughts on possible ways we might be able to implement weather in a way that is at least more complex than the weather in a typical game that has visual weather effects in it (which basically amounts to "every X minutes, randomly generate a value and set the weather to that type without caring where you actually are").

In theory, you could also use something that adds a Kerbal version of the Lockheed compact fusion reactor, if such a mod exists. By which I mean, having electric jet engines. Which you power with a fusion reactor small enough to fit on a large cargo plane. Then, you would switch to plasma engines or something like that which use lots of power to eject its fuel with more energy than you'd get from just burning it with oxidizer. Seriously, if Lockheed's Reactor, or for that matter any other compact fusion reactor comes to be, it will open a whole new set of possibilities for spacetravel in real life.

This is just a funny idea I had, but what if you had a mod that you could toggle on and off while on a mission. When toggled on, it would purposely add a user-defined number of seconds of input lag. It does take time for signals to move the sorts of distances involved in space after all (from Earth to the Moon is what, about a second?) If you wanted to make it a more automated "challenge" mod, rather than a just-for-fun thing you toggle, you could have it add some amount of time for any vessel in a sphere of influence without a manned vessel it can connect to. Naturally, to avoid the problems that would occur with signals taking multiple hours to get around the Kerbol system, you could act like the signals still do travel much faster than the speed of light in our universe, or just do something like add one second each time the signal has to change sphere-of-influence on its way from a manned ship to the unmanned vessel you are controlling. Or, you could input some controls, then hit a button to carry out what you input to simulate having to wait a while for the signals to reach the target. I mean, yeah, the assumption is that most unmanned KSP vessels have an onboard AI that operates them to a partial extent, but sending of actual commands should realistically take time and add to the challenge, right? Speaking of challenges, I could totally see there being challenges to launch a rocket to the mun and back with something like 2-3 seconds of input lag or something the whole way. Much crashing I imagine.

In the spirit of the necro, anyone have kerbals survive things they really, really shouldn't have lately?

No pics. But for those who have used the airship mod? Apparently those balloon-parachute things can summon lesser kraken forces if placed too close to each other. Spent a good half hour trying to figure out why my science plane started to suddenly fly off sideways in circles after lifting off before I figured it was the fact that I replaced the conventional parachutes with newfangled balloonachutes that are apparently made of krakenskin. ...what? I didn't want to have to get out and repack the darn parachutes every time I took back off in the thing, okay?

PC Flight simulators have been simulating wind, storms, and such things for 15+ years now. But they do not actually simulate how weather systems interact with each other and all that. So really then. Why do we assume that KSP has to? As long as weather can happen, and can move over the launch site and then move away from the launch site (and, well, any other sites we might have a loaded craft on planets with atmospheres), that will satisfy many players of the game. Design-wise, it also just comes down to a simple question: "What is it people actually want to do with weather?" Now, I can only speak for myself, but for me it comes to something like this. -I'd like to see weather that may change conditions at a particular place from time to time. On planets with atmospheres anyway. And even if wind and wind gusts are the only thing that have actual mechanical effects on your craft, having clouds, rain, snow, and lightning as visual effects can be fun too. I want to be able to have to delay a launch to wait for a storm to pass. Or to just launch anyway because its urgent, or because Jeb is overconfident in how many struts he put on his rocket. -The clouds or other visual effects do not need to look that awesome. Modders will make them look better for those who want fancier clouds. Stock clouds should though be 3D in some way, even if it is just as boxes like Minecraft's clouds. And when far away, or looking down from orbit, clouds can be rendered as 2D layers to save performance and I won't care. The important thing to note (at least, if other people are like me) is that I never once said I want a full-blown planetary weather simulation program. As long as it is possible for weather systems to exist and move, I don't care if its just sending randomly generated groups of clouds along straight lines across the planet's surface, or actually having interactions between airmasses and so forth. Thus, my suggestion is to just keep it simple. You can get at least a semblance of reasonably realistic weather without having to simulate a weather prediction program. Locally, weather doesn't usually change directions anyway so just having the weather itself move in a straight line actually doesn't hurt realism as far as the game's players would be concerned. So yeah. If most other KSP fans are like me, then they want rain, storms, wind, clouds, fog, and so forth because it adds a new dynamic to designing craft and making sure you launch at a proper time. NOT because we just want to simulate what kind of weather Kerbin would actually have on a supercomputer.

Another reason we haven't seen much on the weather front is in part due to the expectation of a full-on weather simulator. Like, with an actual, simplified weather dynamics simulation with cells located across the planet and generally acting like a substantially scaled down version of simulators that actual weather prediction software uses. Those weather prediction programs tend to run on supercomputers. So even a significantly scaled down and simplified one WOULD indeed be a MAJOR processing power concern. And such, as Gaarst is concerned, it would only be usable by people with better computers. That's why, after some thought, I decided the most realistic approach is the route I numbered as "1" in my original post, and expanded in a subsequent post. It does not seem like it would need too much processing power to do what it would do. The whole planet (or just each biome) would have a single, consistent and unchanging weather "pattern." And some regions that have a different weather pattern would effectively generate and move across the surface in a straight line at a set speed for a set time, almost like it were just moving in a low altitude, slow "orbit" as far as the game is concerned. The game is able to fairly easily handle us putting hundreds of satelites (and pieces of debris) into orbit without issue, so 50-100 weather systems (depending on how many each planet with an atmosphere gets) shouldn't be too bad. Like satelites, only 1 or 2 would be "loaded in" at a time. Hence my theorizing that with this system, the big leap to make is to introduce the actual weather itself. Namely, wind, and the necessary physics engine changes to support wind. Well, ok. Wind, and the necessary graphical changes to see clouds, and visual effects like rain and snow and lightning. The stock graphics should of course be fairly low power as is viable without reverting to 2D images (you could even imagine having boxy minecraft clouds), but at the very least it would be a visual thing and thus something that can be offloaded to the graphics card. Modders can then make the clouds (and other visual effects of weather) look awesome, like they have with other visual aspects.

Ah. In my naivety, I guess I figured it would just be something like "change it so you get all possible science from transmitting," which is usually less than the full 100% from recovery, so I made the assumption that would make it so that it gives you all the science a transmit can give you from a single transmit. Which means that you would then need to adjust all stock science transmit values from their various 30-100% so that they all are 50% instead. Which may well be more than mere config edits (although, if its just in a different config could it be doable with just the caveat that it won't effect non-vanilla science parts?). But yeah, this is just me acknowledging assumptions and making some new ones in hopes that there is a simple way to achieve the basic effect.

One thing that could be neat is if transmitted science can transmit, say, 50% of the total science, but cannot transfer any more. In other word, transfer would tranfer ALL the science it CAN transmit at once, but it would be limited to 50% of the total (for the other 50%, you'd need to recover it).

No one expects the Kerbish Inquisition!

If someone does take it up and considers multiple resources, then I would suggest maybe 3. Silver, Gold, and "Crystals" (which could mean anything from diamonds to corrundum-type things like saphires to whatever weird and possibly valuable things you might find elsewhere in a space setting). Three seems like a good number for sake of balancing rarity and value with distance.

Could also set it so that Engineers can repair some effects that result from damage, depending on their level. i.e. an engineer past a certain level can completely repair a leak. Additionally, if some damage completely disabled something (like a control surface's ability to act as a control surface, or the gimbal effect of an engine), a good enough engineer could potentially repair that part to partial effectiveness.

To give some further thoughts/clarification on how idea Number 1 in the first post could work, mechanically: -(Before this, of course, you need to get the hard part of getting wind support in the physics engine out of the way, which would probably entail "just" taking the resulting vector of the vessel and the wind and treating the aerodynamics for the vessel using the resulting vector). -For purposes of performance, it can be considered to set it up so that wind (and other weather effects) would not be applied to all loaded vessels. Perhaps instead, it would be only the current vessel and any objects that are fairly close by. Naturally, the system doesn't need to be running when no loaded object is actually in an atmosphere either. Step 1. Default Weather. You do one of two things. Either, you set the entire planet to have a "default" weather, or you set each biome to have a "default" weather. If you take the biome approach, then you don't need to worry about the "1B" section of the original post since you can just use a biome to create a permanent weather effect (such as a "Great Jool Blot or some other Great Red Spot analogue). It will also allow science parts that deal with weather to potentially get biome-specific data if you want. Regardless of the approach, the default weather would be unchanging. For Kerbin, it would generally be sunny skies with no clouds. If taking the biome approach, a biome like mountains could have some low level gusting effect if you want to make things interesting, but each biome would generally just be a clear skies, no wind, and a temperature that fits the biome, with no changes of any sort, ever. No processing power would be used for any form of dynamic weather simulation or anything. Step 2. Introduce the weather systems. These weather systems would generate at a random location on the planet. Upon their generation, they become a random type of weather system, with the odds of each (and which ones are possible) being weighted by where on the planet they generate. At this point, it then randomly generates a direction, speed, and length of time. The random generation for each of these three values could be weighted based on latitude and what type of weather system was generated. At this point, the weather system is generated, and proceeds to move in a straight line in the generated direction at the constant speed that was generated. When the amount of time that was generated ends, the weather system disappears. Each planet would have a "weather system value" allocated to it, which is the number of weather systems it has at any given time. So when one system disappears, the number of weather systems is now below that value, and thus a new weather system is then randomly generated. -For simplicity, the weather systems are divided into distinct, preset types, the same way biomes are. Aside from the randomly generated values, they would generally be identical to other weather systems of the same type. i.e. a "humid partly cloudy" system would not differ much from any other "humid partly cloudy" system. -Some values could be randomized a bit for each individual system, such as the wind direction and strength, so that different systems may have different speeds and directions for their wind (the values for any given system remain constant for its lifespan though). Step 3. Weather system mechanics. A weather system would simply overwrite the wind and weather data of the region within its area of effect. It would also either overwrite or apply a modifier to the temperature. The modifier is preferable, so you don't get a thunder storm near the poles making it 20C and raining in a snowy biome. The visual effect of rain/snow (i.e. which one it is) can simply be based on the temperature. Other values that the weather system can overwrite, if they are included in the weather engine, could include: -Humidity and pressure. These would mostly be important for science parts. -Lightning. Mostly for visual effects. Could have some mechanical effects if a vessel is struck (i.e. disabling controls for a couple seconds unless it strikes a "lightning rod" part, and possibly destroying/permanently disabling any parts with a "vulnerable to shock" tag if they are struck directly, i.e. sensitive electronics). -Gust Values. These effect how frequently/strongly the wind direction will have sudden, randomly generated changes. Said changes would last up to a few seconds before returning to normal, and would not have any positional value. They would simply affect all vessels that are currently being effected by wind, regardless of location (naturally, vessels that are not loaded are not effected by wind). -Icing. I could see ice effects being a hassle to code for an effect that would see fairly limited use, so we could probably just rely on modders for that. Otherwise, some weather systems could simply include a value that indicates what altitude the icing is at, with the altitude varying linearly (to keep things simple) with temperature, and only being present between specific temperatures. Icing could work similarly to the heat system, with it building up while in the icing region and slowly dissipating while out of it. Its effect would be reducing the lift of effected lift surfaces, and reducing the power of control surfaces. This about covers the basics. If you want to make things fancier, you can consider some of the following things as well. Step 4 (optional). System interactions. Each weather system type could have some possible interactions it can have. These interactions would generally work as follows: If the weather system's location (likely its center) either enters a particular planetary biome or goes above/below a certain latitude, then the system undergoes some predetermined change. Examples could include: -The "humid partly cloudy" type weather system, if its center enters a mountain biome, randomly transforms into either a "mountain rainy" type or a "mountain storm" type weather system, and changes its wind, rain, and etc values as fitting. It still remains on the same path, moves at the same speed, and has the same time before despawn remaining. -A "mountain rainy" or "mountain storm" system could transform into a "fair cirrus" type weather system upon entering any biome that is not mountain, if you want to "simulate" rain shadows. -A "hurricane" system could transform into some form of standard storm type system upon its center entering any biome other than shore or ocean. -To prevent sudden, strange changes to appearances, the clouds themselves do not change if there is a loaded vessel in or near the weather system and remain the way they are until the player either goes away, or unloads the vessel by returning to KSC or something. Alternatively, when a system changes, clouds could simply have a gradual change that takes place over 10 or so minutes, rather than being applied immediately like the rest of the changes. Step 5 (optional). Local Effects. Severe weather events like tornadoes, microbursts, thermals, etc. Stuff like microbursts and thermals would be a localized effect where a fairly small area is effected by effectively either a downwards or upwards wind. Tornadoes would be a bit more extreme and would require a definite visual effect. A dust devil would require a visual effect, but could just cause a slight updraft and some constant gusting effects while in it. Static biomes could also potentially have these occasionally occur. For instance, a volcano could occasionally have an "eruption" local event that basically just affects, well, the part that does the eruption. -Much like how weather systems overwrite/modify the biome's default atmospheric values, local effects could have an even higher priority. -Some of these effects could have a chance of spawning when certain weather system types are in certain biomes. Step 6 (optional). Seasons. The easiest way to put these in would probably be to just set some biomes to have some different default values for each quarter of the year (namely temperature, but you could also have some biomes that have a consistent wind in some seasons too). Each biome effected by this would need a value that indicates whether it is "north" or "south," so you could use the same biomes in different hemispheres and have them just be offset from each other. If you really wanted to go nuts with visuals, you could set some of them to even change textures based on the season. -Using this, you don't need to worry about the planet's tilt. Which is probably good, since there aren't really any with that for the sake of simplicity. .

I meant more with regards to the way people like Randal uses the word "kerbal" as an adjective. In his case, he uses it to describe the concept of... well, this. https://what-if.xkcd.com/139/ You cannot argue that it would be quite kerbal to stick a heat shield on a submarine, and drop it into jupiter's atmosphere. The rabbids seem to base their entire "space program" on that sort of style. Mixed of course with a hefty dose of "there is no way that would EVER work in reality." At the very least, they need more struts. .

If anyone has watched that Rabbids Invasion series (hey, its actually better than the games), maybe you've had a similar thought to mine. That the Rabbids have a space program that is even more "kerbal" than the actual Kerbals do. Hell, they may even be more kerbal than those warhammer orks (you know, the ones who somehow build interstellar spacecraft out of wood and scrap metal, and basically just crash them wherever they need raw materials to build surface warfare buildings). Typical rabbid designs appear to use things like modified fire extinguishers in place of rocket nozzles. Instead of a runway, one of their launch systems is basically a curved ramp built of 2-by-4s. Anywho, the rabbits apparently have a fascination with the moon. This is actually the focus of a number of episodes. One of the arguably more successful ones being the following. Ignoring the rather cartoony nature of things (including some toon physics, and some nonsense like that weird asteroid belt), it is remarkable just how, well, KERBAL these rabbids are. It kind of makes me wish there were a a Rabbid Space Program mod. Though I suppose there would be some potential licensing issues there... .

Indeed. And while some games do indeed see less reason for updates after release (they may already have most of their sales after a while), KSP actually has all the more reason to try and keep itself updating. It will be getting itself onto consoles soon. .

As I think about it, number 2 in the list (having a low-power weather sim) might be hard to do too, and either 1 or 3 would be the most reasonable bet for minimizing processing power (since in 1 weather is a bunch of basically invisible moving "biomes" that generate in a random spot, move in a line across the planet's surface, then disappear. While in 3 weather is a pre-determined loop that maybe separates a planet into regions and just assigns a given weather type to each region at a given time in said loop, meaning that the weather isn't actually being simulated, just read). Heck, in 1, each "weather biome" is itself basically a physics-less, um, thing that just "orbits" the planet in a straight line, like a moon, except it is basically in the planet's atmosphere. The hardest major part to get in without major processing power hits would really just be, well, wind. It would basically be adding a new vector to deal with when dealing with all manner of drag calculations. If you can somehow do wind, then gusts is easy as it is just making the wind speed go up and down rapidly for a second or two. Some other concepts like dust storm damage and icing could be a little tricky to do, but technically could be done even without wind (they also aren't absolutely necessary for a weather mod). And really, you may not even NEED to include them in a stock version of weather. Icing would probably work in a similar way to how heating works with parts. Surfaces that produce lift or apply maneuvering forces would get less effective at both lift and manuevering as they get icier. A given "weather biome" would simply specify something like an altitude range (which could even generated semi-randomly upon the system's creation for variety and just remain the same for that system until it disappears), and a strength level for the icing effect. While in that weather system within the specified altitudes, your wings and similar parts would start to ice up, and possibly gain a simple icy graphical effect (similar to how hot parts start to glow). Parts that generate heat could counteract it, and it could slowly wear off automatically after leaving the dangerous altitude range. Rain would be pretty much a purely visual effect. Thunder could be mostly visual, but have a chance of hitting you if you are in the clouds (strikes could disable your controls for a few seconds unless you put a conducting rod part on your craft). Some parts could be flagged to be actually destroyable by lightning strikes. Naturally, mods can (and probably would) be used to make the weather look a lot better if people want it to look good, so the clouds and other weather can be set up to look fairly simplistic and low-res in the stock version. But yeah. The wind itself is really the hard part. Whether or not it is possible to implement wind without a major performance loss is the real question. You can cut some processing power by having wind only affect the currently selected/controlled vessel/kerbal (maybe have a performance option that also enables it for other loaded-in vessels and kerbals). For simplicity sake (i.e. not making it even MORE of a potential nightmare), you could even just worry about horizontal winds only. Though if there isn't much difference between horizontal-only and TECHNICALLY supporting winds from non-horizontal directions, then you could just do it so that you (or modders) can support things like thermals and updrafts/downdrafts.

I am wondering if there is a mod like this already, or if it is even possible. After thinking on the subject a bit, I came to the conclusion that my ideal base construction mod would NOT be something based on any sort of parts themselves. Instead, it would be something that lets you build actual buildings (i.e. the same kind of object that the actual space center's buildings themselves are). Once a building is constructed, it could either be upgraded with funds (if on Kerbin/a populated world), or with some sort of "Parts" or "Supplies" resource (if on NOT-Kerbin/an unpopulated world). At its core, it could simply be a mod that lets you build the Kerbal Space Center the way YOU want it to be layed out. You would start out with a single building that lets you purchase/place another building, in a vaguely sim-city style, where you want said building (in a career mode, the first one you'd get would probably place would be the rocket launchpad, and some of the administrative buildings, which for purposes of balance would all cost 0 for the level 1 version). The starting building itself could be upgraded to increase the number of different buildings you can build. A necessary aspect of the mod would be the launch button in the vehicle designer bringing up a short list of all nearby launchpads and runways (in case you decide to build more than one, such as having two runways facing different directions). Another necessary aspect would be the ability to switch between different space centers, and a part that allows you to build the lowest level version of the building you build all other buildings from (in a sense, using the part places a new space center at that location). So you could build another KSC on the north pole if you wanted or something. Lastly, there would need to be a tag or value for a planet that basically tells the mod whether or not it is a populated planet, so that you can't just construct bases on other planets that work the same way that the KSC does. Either way, once you had this, the next step would be to apply it to other planets. On other worlds, instead of currency, there would presumably be some combination cost of ore (easy to get there), parts/supplies (have to bring with you until you have a building capable of manufacturing it from ore and energy), and in some cases construction time based on energy and how many kerbals are there to work on it. In the event a building is destroyed, it would leave rubble behind that you can select and repair for the appropriate resources, just like the default buildings. If the mod were to just keep itself light, it could be that you can only build structures for things like hangars (buildings that store/unload a nearby vessel until you want it to be spawned again either outside the hangar, or at the base's launchpad), habitation (basically, like the training center except you cannot recruit new astronauts there, only store the ones you have so you can put them into any ships you take out of hangars). If you wanted to go further, you can also have VABs and/or SPHs, which could only use parts that you actually have there, or which can only work if you have some sort of factory building to produce the parts there (the level of which could effectively correspond to what research level of parts can be used there). I could go on listing various things that could be cool, but I've already rambled enough. Are there any mods that let you build actual BUILDINGS? Not just building-like parts, but true, proper buildings? .

So I decided to play around with hyperedit. I may have angered the Mun. Naturally, Minmus decided to join in too. This continued on for some time. Then I accidentally told Kerbin to orbit the Mun. The game didn't like that. Kerbin will not go to space today. On a side note, I ended up making a bunch of things orbit minmus and Mun rather than Kerbin, after seeing that trying to make Jool orbit Kerbin results in me launching from... Jool. Suffice to say, I did not go to space that day either.

Still, it would be nice to get a handful of stock "boat" type pieces.

As far as part-mods go... A mod that adds propeller engines. Or at least a portion of such a mod (specifically, just some of the engines themselves). If possible, including an electric engine.

Its slightly off-topic, but I would like to suggest: -Add more variety to the flavor text for various scientific tools. There are just so many science gathering texts that are identical to each other aside. Heck, all the EVA reports on Kerbin are basically either "you didn't really need a space suit to get here" or "this is a precarious situation." Also, maybe reword some of the texts, like with the air pressure barometer, to indicate they are maybe able to also pick up solar particules or micrometeorites. Because otherwise, there really isn't much reason we should keep getting science for just confirming that yes, the space in every part of the solar system has a vacuum in it (and heck, if nothing else, the 2HOT thermometer can at least pick up some heat being radiated by the ship and planet's surface despite the vacuum). In fact, why not just merge the barometer and thermometer into a single science tool, and replace the one that is no longer a thing with it being some other tool that is more useful in various situations. It relates somewhat to career since gathering of science is a very important aspect of the career modes, and it would be nice if it could be a bit more rewarding.

Honestly, N-body physics isn't like it has too much trouble. They really could implement it, just with some limitations. First being, have only the closest planet be counted when you are close enough to be in the "space near ____" biome instead of "space far above ____." Naturally, if you are in an atmosphere (or otherwise in a situation that switches you to max 4x time warp) it would only look at the closest body too. And you can have an option that simply disables it so that it behaves like it does now. Of course, the N-body stuff would ONLY be applied to things like spacecraft and randomly generated asteroids that are in suitable location to follow the above limitations. It would not be applied to planets, moons, or anything else with a preset orbit and path, and those things would simply continue as they are in their pre-defined orbits.

Lets see: Basic: These are some fairly standard worlds and things we could add to the Kerbin system. 1. Saturn Analogue. Maybe move Elloo out a bit further to make room for this if need be? Has rings. Probably has moons. Is a gas giant with less gravity than Jool. If you want to make it really interesting, give it oxygen in the atmosphere. 2. Planet/moon with low gravity but fairly dense atmosphere. 3. Volcanic planet/moon with fairly high temperature and moderate atmosphere, such that radiators are effectively required while a rocket is running. Any lakes and/or oceans on the planet are lava. Lava is opaque and dense and glowy, and hot enough that most parts in contact with it will overheat within 5 or so seconds. May allow for "boats" to survive if they have sufficient numbers of radiators cooling their floats. 4. Small Moon/asteroid that is shaped like a two-ball snowman (as if two things collided very slowly). Each half is a different color and biome(s). Due to its extremely odd shape, may be a challenge to orbit. The point where the bodies collided may or may not be a nesting ground for the kraken. 5. Planet/moon with thin, no-oxygen atmosphere, and deep, low-density ocean, such that most parts will sink in it. Only a couple very small islands dot the planet. 6. Comet. Highly eccentric, elliptical orbit, dives in towards the sun every now and then. Period of somewhere in the 10-20 year range? 7. Second, more impressive and larger comet. Highly elliptical orbit, but not very eccentric. dives in towards sun every 30-50 years, with first time being about 5 years after default position start? Probably don't need more than 2 comets, unless we add randomly generated comets like we have with asteroids. Beyond: These are ideas that typically would be more at home a bit beyond the Kerbin system, around nearby stars. Naturally, any of the ideas in the basic section could also instead be around in these systems. All stars stationary relative to Kerbol Sun for simplicity. -An option can exist to disable things outside the Kerbol system for sake of performance. 1. The "easy" nearby star. A fair bit less than a light-year away. Maybe somewhere between 10-30 Eeloo distances. It is quite close as far as stars go. Somewhat similar to than Kerbol Sun perhaps, but maybe slightly smaller. 2. A red dwarf star, somewhere around 0.5 and 1 light year away? Small star. 3. A blue giant star, about 4 light years away. 4. Black hole. In-game, just a rather small sphere with a lensing effect applied around it. High gravity, but very small "size." Could have some deformed asteroids and a white dwarf orbiting it. 5. Gas giant planet, orbiting in habitable zone of a star. Maybe the star in number 1? 6. Moon, smaller than Kerbin, but with Kerbin-like atmosphere. Lots of lakes. Biomes are mostly Jungle and Forest, with some plains and occasional mountains. Maybe have it orbit number 5. Would be nice to have a habitable world in one of the other star systems. 7. A "Hoth" Analogue. The planet is icecap, except for within 5-10 degrees of the equator, which contain plains, tundra, and lakes. Could be good for the red dwarf? 8. Small, but fairly dense world without an atmosphere. Lost most of its lighter elements in some cataclysm, and its surface is fairly smooth. Good for the black hole/white dwarf system? 9. Planet that has been hit by a smaller planet recently and is a general mess. One side is completely molten, the other is varying less degrees of volcanic. Has several asteroid-like bodies orbiting at varying eccentricies and distances, some of which are partly molten themselves. This planet and its friends as a whole is something of a reference to one possible way Earth (or Kerbin) looked during the adventure that resulted in it eventually having a moon. 10. THAT planet. You know the one. It thinks its so special due to being the focus of many-a-challenge, but really its not. Its actually quite boring. We just never like going to it because for whatever reason, it is orbiting the star in the opposite direction that everything else is. Truly, a jerk among planets. We hope it eventually gets eaten by a gas giant. That jerk. 11. A planet that is shaped exactly like a kraken. Does not orbit a star. Is just out there somewhere. Lurking. 11 for real. A dead, rogue planet could be somewhat interesting. Covered in ice and continents that are also pretty icy, and is generally quite cold.