Domfluff

Cheers @String Witch, good spot. I'll give that a go.

Shouldn't worry, not stopping research (assuming they have power), ksp doesn't really do background processing, so much as catching up when the ship is in focus. I don't know whether there's a better way to display this when out of focus. Perhaps EC could only be shown for active vessels?

Legs are from UKS - they're "landing stabilisers", and intended to balance the base parts, but they work really well here.

My Mun/Minmus lander. This is pretty much exactly built for the Mun - landing almost empties the bottom tank. On the surface, before science happens.

This is a four kerbal crew, which is pretty much my default for this kind of thing (two scientists for the lab, one engineer for the KAS/KIS base building and setting up surface experiments and one pilot for ascent and descent) The rover is really light (whilst docked at least - the inflatable fuel bag is only used for the ascent, and it adds a few tons to it), so the torque generated is minimal, and the reaction wheels are more than capable of compensating. There was a fair amount of testing for that. It helps a lot that it's more or less on the centre of mass. Hab time is something over 300 days, but the greenhouse (other side of the craft) will generate supplies for more than twice that (since they need to get home). Plan here was to avoid as much upmass as possible, so you're not harvesting supplies on the Duna surface and lifting them into orbit, for example.

Current USI-LS duna transit architecture: Based partly on this: Relevant mods are USI-LS, Malemute rover, SSTU, Near Future construction and inline ballutes. Unmanned surface base hab (not pictured) is a combination of UKS and Planetary Base systems, landed with the help of USI Survivability airbags.

Current career Duna architecture. Made possible with SSTU parts and based on the Deep Space Habitat concept, which should gain a lot when the new SSTU station parts are finished. Assembled in two launches with the help of welding docking ports and the capabilities of the Orion capsule. Main concept here was to minimise launch mass, Duna ascent and descent mass, as well as cost and required technologies at this stage in the tech tree. We're on a budget, people. The plan in total also involves an unmanned surface hab, landed with the assistance of airbags. This is packed with surface experiments and ISRU gear. The transit vehicle will perform deep space/solar experiments in it's 300 day transit, then aerocapture to Duna orbit using a ballute. The pressurised rover/VTOL will land with the assistance of parachutes, and will trundle over to the habitat (widening the margin for landing error), where the crew will finish outfitting the surface base, perform experiments and fine something to do with themselves for 600 days. The rover has an inflatable fuel tank, so the ISRU-fuelled ascent delta-v is significantly greater than the descent delta-v, but is just about sufficient to get into orbit. The unmanned Orion capsule will then rendezvous with the rover, and pootle over to the transit vehicle, where they will dock and transfer experiments to process on the return trip. Vehicle returns to Kerbin, aerocaptures at Kerbin using the re-packed ballute, and the crew return in the Orion capsule. The transit vehicle remains in orbit, and can be manned as a space station (to continue processing the Duna science), or refueled for travel elsewhere. This same architecture should work fine for manned missions to Eve orbit, Gilly and Ike, but may struggle with Dres. Some efficiency is lost here - processing experiments would be more efficient on the surface of Duna, but that would require landing a lab, which increases the size of the payload. The concept here is for a reusable exploration-class ship that can work as a baseline for more advanced missions later - this kind of architecture is not required for Duna, but a scaled up version is probably pretty much mandatory for missions to the outer planets.

Ignoring scaling, I'm going to guess that the rates are based on Gemini missions. Going by one set of numbers, Gemini had a mass budget of 426kg assigned for provisions, which would be 26.3 days in USI-LS terms, with no recycling. Divided by two crew, that's thirteen and a bit days. Longest Gemini mission was 14 days? No idea if that mass is accurate of course, and Kerbal scaling screws with this kind of thing at every level really - it's great to have real ISP and plausible mass values/gravity/transit time, but in doing that you have to squint a little (ignoring Kerbin's density, for example), and it often creates some edge case weirdness

One "kerbalmonth" = 30 days, and bears no relation to either the length of a Kerbal year (426.08 days) nor an actual Kerbal Month (38.60 hours). The resulting figures are relative to Kerbin time scales (6 hours/day, 426.08 days a year) though. The Hitchhiker pod gives a bonus of 12.5 KerbalMonths, in addition to the four KerbalMonths that the four seats grant you.

I was playing around with the idea of a design-for-effect robot arm mod, one that had a model, but didn't physically move anything, just acted as an increase to the mass you can move with KAS/KIS. I was playing around with this on the most basic level - giving the functionality to a copy of a cubic octagonal strut - and had that working fine... but the actual implementation was somewhat lacking. Regardless of the use of the thing, I really didn't like how it felt, if that makes any sense. Animating parts like the above with different attachments (aside from using the Infernal robotics code... at which point you're probably better off just using that mod) isn't possible, as I understand it. Roverdude is going in a different direction with his Konstruction parts - he has forklifts and grabbers which are just animations and colliders (so essentially the actual model is used to bump into things in a controllable manner), as well as non-KAS magnet parts on cranes etc.. They still use his GUI though. These parts are all-in-one though, which means they'd need to be rescaled, or designed specifically for that intended scale. That said, a robot arm would be nice for orbital construction, would give another good reason to have a Shuttle, and would help with getting the welding docking ports together. Far from necessary I suspect, but a nice thing to have. I wouldn't be surprised if it wasn't worth the workload though.

ISS recyclers were intended to be 90%, but in practice I believe they achieve 75% - which is possibly where the 16.2kg comes from, since 1/4 of that is less than the 5kg NASA figure. Let alone that this represents 16.2 kg per six-hour kerbal day. But... that doesn't make a lot of sense to me either, since that 5kg figure is before recycling. You could also make the case that Kerbals should halve that, but that's probably not a great idea. The USI-LS greenhouses are probably overpowered, since they reduce the required mass (as fertilizer) to very low levels. It's notable that Roverdude is doing a large scale USI-LS/UKS rebalance for the 1.2 release, so it's very possible that his numbers will change again. All of the above is configurable of course, but it's probably sensible to work around the standard USI-LS settings. One thing that had become pretty clear to me is that he's been balancing this with the stock game in mind, and doing a reasonably good job of it, at least as far as cis-minmus space is concerned. LKO and the Mun are more than achievable without additional life support, but Minmus requires some extra supplies and possibly recyclers. ** I think I'd be fine with 90% recyclers, at least for the moment. Design for effect, the actual utility is more important here. The real problem I've had in designing plausible vehicles is the problem with hab multipliers, which make little sense to me. The idea is that working space (e.g., labs) give you some available space, hab modules give more more room to move (bonus kerbalmonths) and multipliers are supposed to be parts which give benefits throughout the whole ship. To give a far-future (slightly silly) example, a cinema or pub would give you a bonus throughout, not just for that module. For a less far-future example, I think the toruses are more than reasonable to use as hab modifiers. Crews can rotate through the ship, so having work time spent in-gravity during transit is of great overall benefit to the crew. What values are given here are something quite different though. Thinking in terms of actual game effect, I don't think you should *need* artificial gravity for a Duna mission. It would be nice, and might be a really good idea, but I think you should be able to get by without. This is also a good reason to have torus parts above hab parts on the CTT, so you can slum it in a low tech manner. Duna transit is less than 300 days, so that's a reasonable figure to aim at for a Deep Space Habitat-like vehicle (i.e., ISS Lab module, ISS docking nod, ISS hab/MPLM module + propulsion bus, Orion and MMSEV). Architecture of this manner could keep a transit vehicle in-orbit and land the crew to an unmanned and previously deployed surface hab. Anything beyond Duna should probably require artificial gravity. Checking out the Outer Planets mod, the extremes of the solar system (Neidon and Plock) are something like 23 and 35+ years to transit for a minimum energy transfer one way. Clearly then, a long term space habitat needs to end up with hab time approaching 50-100 years. That might be with a minimum crew (probably 4 or 6, since 2x Scientists, 1x Pilot, 1x Engineer seems sensible as crew minimum in most cases in KSP, but there are arguments for more especially with mission involving ISRU or other base parts. If I recall correctly, UKS does model "unhappiness" in the form of inefficiency for fewer than five kerbals at a Kolony, which may or may not be a consideration). So, just throwing some arbitrary numbers out for the extreme end of things: 30 man torus for a 6 crew long (really long) duration mission would have: (30 + Bonus Kerbal months) * Multiplier / Crew Without bonuses, hab time is 150 days per crew member. Assuming a bonus of 200 kerbal months (one KM per seat means this is +170) and a crew of six, that's: 30 + 170 * Multiplier / 6 Using a Multiplier of 30 and bonus of 200 Kerbalmonths here would allow for the largest torus to support hab time for six crew for about 70 years. That seems reasonable to me as a top-end "permanent" habitat, and is within reason for an interstellar flight (therefore a decent practical endgame limit for KSP). Certainly fine for pootling around the solar system.

I don't know if it's possible to animate a node like that, but it would be cool. One thing re:inflatables - in Roverdude's in-progress UKS stuff, he has some code to make all radially attached parts drop off when the module inflates. It's a nice solution to the clipping problem.

Actually, SSTU-ST-DOS-COM shows up fine when it's launched, and in the right click menu in the VAB parts list, but the part in the VAB isn't showing the resources correctly, which is a bit odd.

Sure, but that doesn't look like what the part config files are trying to do - the different sizes of LAB and HAB module don't all have 3.2 tons set, which presumably means that something isn't working the way it's supposed to (which could indicate further errors)

USI-LS patch for the COS docking hubs: This works fine, and I think I'm happy with the resulting numbers. I've figures for the rest of the parts (aside from the COS-HAB and COS-LAB, since the masses are wrong), but I think I'm running foul of the way you've defined the parts - applying something like the above (with different values) to the SSTU-ST-DOS-COM part, for example, shows supplies and mulch in the right-click menu in the VAB, but not on the actual part. Equally, defining multiples involves some other weirdnesses - some values are shared between parts, etc. I'll upload the patch as written to the Github thread, but it's not really functional at the moment.

You might have spotted this already, but all of the COS modules (ST-COS-HAB and LAB) have the same mass (3.2) - I haven't spotted where the problem is yet.

Recreation of earlier linked design, probably limited to near-earth/kerbin asteroid rendezvous (HAB and LAB parts). Clearly could be used to blitz Gilly's biomes, if the hab time were sufficient. As an aside, part of my interest in things like the above is that I've been pretty convinced recently that this is the ideal way to go about doing science at things (assuming the initial setup isn't too much) - have a lab in-situ, and a lander that can take science from as many biomes as possible and return. That's not usually possible on the surface without ISRU refueling/large scale mining and processing, but is certainly possible in orbit with a tiny lander and large mothership. Something like the above (a little larger) would be great for taking all of Minmus' science and processing in a lab in Minmus orbit, over an extended period. Assuming the use of a Life Support mod, the lack of decent hab options starts to become really apparent.

You say that like you don't think Kerbals would have antimatter snowball fights around the fuel tanks.

Quick Mir for testing. Notable that aside from the Core module, most of the parts of Mir are also some kind of lab. Three Kerbals to a module equates to a 150 day hab time without any bonuses. Longest time Mir went without resupply was 240 days, so there has to be some kind of bonus or multiplier in here. Having one of these modules as a FEM module at a x1 multiplier (which is x2, since every module is x1) would turn that into 300 days without an issue, plus any attached Soyuz, Shuttles, etc. How do multiple labs work on the same vessel in stock right now? They've certainly been changed a couple of times since 1.0. Obviously more labs does mean more science storage, so there's that at least.

Thank you for that, there are some decent ideas there. I'm not entirely sure that I agree that a rotating hab is essential, nor that it's luxury accommodation for some of the crew - using Seveneves as a recent example, the crew of the expanded ISS in the prologue had to spend certain amounts of time under gravity, and their time would be rotated through the station. Clearly, out and out recreational parts are clear candidates for hab multipliers, but I think I'm leaning towards the idea that a torus is a good option as well. Would have to be extremely large to offer a large multiplier, but as it stands, you usually need multipliers for manned deep space missions (you can get away without it for Duna). Spamming cupola's certainly does the job, but it just seems really sensible to me for your deep space missions to require artificial gravity (and since tethers aren't really a thing in KSP, that means Von Braun wheels). Speaking of, eventually I'll finish writing a MM patch for the KIS "fun" parts, applying a multiplier to each. The multipliers are so small that they're not really worth taking (and they don't work from inventory, obviously), but it's a nice way to make basketballs, tacos and beer have a little more in-game meaning.

I think I agree entirely with this (although specific numbers will need some testing out) - it's very possible that artificial gravity is pretty much mandatory for missions to Mars and beyond (certainly a good idea). I'm even fairly happy with treating "multiplier" as "counteracting weightlessness", at least as a shorthand. Therefore the ST-DOS-FEM "entertainment" module could have a low multiplier, since the exercise equipment etc. are dedicated for that purpose.

Quick ISS for testing: Other angle, truss segments removed for clarity: Will update with some further thoughts on the life support front. First thing that came up with regards to the ISS is how there *aren't* any dedicated "hab" parts on the ISS, and that the life support functions are mostly performed by the docking hubs, rather than the modules. Ha, forgot the Cupola module :). Should go under the one (Tranquility) that the BEAM is attached to.

Is there a reason why the rotating UKS hab doesn't come with a multiplier? It seems to me like simulated gravity would come under the umbrella of things which should provide multipliers.

One option for the ST-COS modules might be to treat them as generic, multipurpose modules - they do a little of everything, and therefore supply a small amount of multiplier, additional kerbalmonths and recycling. This would mean that individually they wouldn't be anything special, but if you strapped enough of them together they would sum to something significant.

Brief thoughts on the DOS modules, and USI-LS. Obviously actual figures here are meaningless until the parts are finalised/balanced, but still worth thinking about. ST-DOS-LAB (lab) ST-DOS-STR (storage) ST-DOS-TKS These are probably fine without additional USI-LS configs, since the seating will do the trick. ST-DOS-COM (station core), HAB and FEM would need some thought. COM and HAB will want some bonus to Kerbalmonths, and FEM will provide a multiplier. In Roverdude's notes, these should be derived from the mass. Since much of the point of SSTU is combining parts, it wouldn't be appropriate (or balanced) for the multiplier to be equal to the mass of the entire module - instead this should have a multiplier based on whatever the "payload" mass should be of the module. Probably not more than ton or two for the multiplier (exercise equipment, etc.), but the KM's can be the total mass of the module, more or less. Aside from fiddling with the exact numbers, I think that all works in a fairly sensible fashion. In terms of required space for supplies - a Kerbal eats 16.2 supplies a day, so a 90 day mission consumes 1458 supplies, which means that a two person crew noms through about 3000, or about 3 tons. Since that's more-or-less within Progress capabilities, that makes sense to me as a baseline. I'd be tempted to not include any recyclers in the DOS parts at all (and certainly no processors), but that's also worth thinking about. * ST-HAB-A through D are relatively simple to sort, since they'll provide a bonus to Kerbalmonths relative to their mass (whatever their mass ends up being). The ST-COS-xxx modules are a little harder to grok right now, since they are currently a lot more generic than the DOS modules, and don't easily split into multipliers/non-multipliers. You can make a really good argument that the rotating torus parts (ST-HAB-E through H) will grant multiplicative bonuses, but again deciding how much they should have is awkward here.