DStaal

As a side-note: I've merged the 'life-support' feature branch back to dev - the remaining tweaks aren't life-support specific, and things are mostly looking good. The to-do list before the next release: Settle the deployment costs. Merge the USI-LS specific tweaks back upstream to KPBS. Update the Readme and Changelog. I think that's about it. Of course double-checking everything is a good idea.

Which is part of why I'm all over the place on how much it needs to be: Is it stowed in the part itself? Part of it? Would it be secure? Etc. (I'm not sure I trust the IVA of the undeployed pod though.) Even if it there's space, I'm not sure it's *appropriate* space - in that it may not be secure enough to handle the stresses of launch, etc. You can actually go down to IKEA and buy all their installation/assembly parts separately. I've even had some items from them where they're in a separate box. But note that IKEA is obviously an over-simplification, and the question is how IKEA-like this actually is. Also note that there are several parts in this pack that make shipping them easier: Both the Kontainers and the Workbench will hold MaterialKits, meaning an integrated packaging is quite possible - but I'm not sold on it being the *default.* (Actually, my mental model has you needing to deploy these from Workbenches - which conveniently allow you to EVA and hold MaterialKits.) Let's take your early Mun landers for an example: If they have several thousand for dark side transits, would 400-500 of it meant that you couldn't deploy until you were in the sun? And would not being able to access the hab or greenhouse until sunrise have been an issue? That's enough to have to think about, without over-doing it, I think. Yes, if you have generation it's pretty trivial - but then it should be. (And of course note that you can well have two/three of these in a base...) For a Biologist - not without writing our own plugin. Basically, if an ability doesn't exist in Stock, KPBS, or USI, we don't have it. Which is also partly on the EVA issue - We can make it deploy without cost and without EVA, but that also means it doesn't need a Kerbal. I *do* think it should take a Kerbal to deploy. So to require a Kerbal, that Kerbal needs to be EVA, because that's what the tools we have support. (And really, even a Ranger inflatable should be deployed from the inside. I mean the Biglow module on the ISS was inflated by astronauts checking connections and opening valves, and that's basically a first prototype.) Oh: And on the 'form over function' comment: We've just spent quite a bit of effort to make sure these parts aren't form over function, and are in fact just as functional as USI parts. This is possible - but could well be annoying, and remember that there are *three different* parts we're talking about here, not just the greenhouse(s). If the Greenhouses require Water, that should be in *addition* to whatever the 'standard' costs are to deploy a KPBS part - which is shared by the MK2 Hab and the Science Lab. And note that that then means you need to have a container for that resource as well - which if you *only* need to deploy can be annoying.

My guess from the deployment animation is that it's gaskets, and they are primarily designed for pressure from the inside: They're thicker near the end of where they deploy, so the obvious is to wedge themselves in against something. For high-pressure worlds, you would reinforce that junction with something mechanical, to hold positive pressure. But that's just a guess. (Probably you deploy to a gasket and then seal the joint with something stronger, actually. Which gets us back to: How much stuff do they need to deploy it?)

My option #3, split up the current configs into separate parts instead of trying to swap them: Agroponics + Hab Cultivator (Substrate) + Hab Cultivator (Dirt) + Hab Possible future Organics. Your proposal: Agroponics + Hab Switchable Greenhouse agroponics dirt farming substrate farming pure hab greenhouse efficiency part Possible Future Organics So your proposal means one less part, and five new configs. (Not counting the config for Organics, as that's future.) I'm assuming here that the farming modules would need to be rebalanced by the lack of hab inclusion. (Otherwise the switchable agroponics makes no sense as the dedicated agroponics+hab part will be better.) I don't think the Ranger inflatables should be considered as guidelines here - they specifically use the mass of the MaterialKits to balance the weight reduction of the inflatable. So you send the same mass sending an inflatable as you would sending an equivalent Duna module, for instance. The advantage is the size and that you can re-use some of your mass from things like decent stages to do it. KPBS doesn't do that: It sends the full mass of the part up as one piece, and you deploy it. So they aren't really comparable. I'm against adding SpecializedParts to any of them - mostly because it's just annoying. It's another container, and then it *has* to be in a container - you can't reclaim it from parts. It would mean you can't use an end-rack for deployment resources, and need to basically fill an inline rack. KPBS has to be really good at this: They fold up a *telescope* into it, after all. IKEA is actually a decent comparison: If this was an Ikea kit, I think the deployment resources would be the 'parts bag' - all the pegs, screws, etc that you need to assemble things. How much do you think that would be? Let's not think in MaterialKits units for a moment: How big a bag would it be? One liter? Ten? Think in terms of Ziplock sandwich bags - they're about a liter each.

I believe it's a CLS option.

Maybe - but the description on most parts is flavor only: No real info. (Not all parts, but most - including the stock parts.) The info blocks are where you get details.

Two quick notes to start: RoverDude created a great balance spreadsheet for production values/mass/volume/etc. - there's a link earlier in this thread. We've been working off of it heavily. Secondly, the deployment costs aren't just for the Greenhouse - the MK2 Hab and the Science Lab also deploy. Unless there's a specific reason to have them different, I think all the modules should have the same cost. I do get your point on not really needing them as well. I've been back and forth on that; my thought is that there's a small amount of equipment to secure things in place - it's not really intended to be retracted and re-deployed, so you put in a few bolts and screws to hold things together and get a bit stronger structure. You might also want to put in some furniture, but that's a more open question. I'm figuring that EC will probably be the main cost - running your tools, powering whatever actually pushes the sides out, etc. (Vs. inflatables which use air for most of that.) Which still leaves me with a fairly random EC cost, even with nothing else. My thought was to have just enough MaterialKits for the bolts and screws - but how much that is (and if that's zero) I still am all over the place on. If it's more than one and less than about 200 you can do it with one container or Workbench. (Less than 100 you can do two modules per container.) I'd say that anything between 1 and 100 is really the same, gameplay-wise, as you won't ship in less than that. (Though less than ~50 or so you can almost rely on not needing to ship any - as long as you have storage space for it.) More than 100 and you need one container per deployable module - more than 200 and you start needing to actually think about amounts. I don't think it should need more than 100. I'm not sure it needs more than 50. One or two just seems petty, though it makes sense to me.

The #3 suggestion was to split the currently suggested modes - Agriponics and the two Cultivators, all with hab - into three parts. You're suggesting keeping the basic agriponics with hab, and creating four new configs in a new part. I'm comparing the two ideas as a whole: Keeping the current configs, but just splitting them out, vs. coming up with new configs on a separate part. New configs, split out, would be strictly worse than either idea. But what amounts should they be? RoverDude uses MaterialKits here to balance mass - but we're pretty balanced mass-wise already. I can throw random numbers in that feel sorta-right, but I don't really have any reasoning behind them.

I assume outside of MKS a farmer is essentially a Tourist.

Sorry, meant to reply to this yesterday and got sidetracked... That actually only reduces the part count by 1 - and I'm not sure that two greenhouses are less confusing than three. (In fact, two may be *more* confusing - you can miss-spot and not realize you're seeing two, while three you tend to catch a bit better.) It's an interesting idea, and I like at least parts of it, but I'm not sure it's advantage to user comprehension, and it would mean coming up with four more balanced configs - while the current uses the configs we already have. So it's a *good* idea, I'm just not sold on it being a *better* idea, and it's more work. Assuming we stick with 'each mode is a separate part', the only thing I think that needs actual attention at the moment is resource cost for deploying modules. My current setup is 25 MaterialKits and 400 EC - with the thought that most of it is moving things around, and then bolting stuff into place. Playtesting made me realize that having two resources was annoying, and that the ability to collect MaterialKits from descent stages means they should be preferred. (I even floated the idea of adding some minor storage of MaterialKits to the Merkat engines, so that you'd be able to deploy without using containers - lots of racks can be annoying with CLS.)

What we really need is a plugin that alters the module info readout in the VAB... (And then for it to be rolled into stock.)

I'll admit I never put that together with that function. Which partly proves my point, though not entirely. I will still maintain that not seeing it in the VAB means it's very hard for the users to make balance decisions - whether that extra mass or cost is worth it.

It's not about the one stock part using one value. It's about there being no interface for the player to *read* that value. The fact that the value can change will surprise users - and will only be apparent once science labs have been deployed, and then they are as likely to think it's a bug with the modded part than that it's intentional. If there were a better interface to see that it existed, I would have no trouble with using it. But it's completely hidden from the player.

Root part. If you want to have a base stretching across two biomes, use logistics.

KPBS has a couple of recyclers - though a thorough re-balance of it's USI-LS support is in the works. The final version should have a couple more recyclers, as well as adjusted hab-times and multipliers across the board.

I believe in-orbit actually counts as well - but at a lower rate.

You do need a scientist in the lab.

Note that if you have a science lab on board you can do that from the lab.

I just wanted to chime in and argue against using scienceMultiplier as balance in any way. It has a very important problem, that means in effect it should never be varied from stock in my opinion: It's completely non-discoverable in-game. Nothing in the game even hints that it even *can* change. So changing it is just pulling pranks on the player, because they don't know you've done anything. Change the processing rate, change how much science it can hold, but the multiplier should be treated as a black box that the player can't account for.

If you do include reserve batteries, please make sure they are optional. They are why I don't use Ampyear.

I suspect it'll depend heavily on how the mods are coded - whether they hard-code text into the plugin or if they can tie in to KSP's new localization system. You'll probably have decent luck if you go to the mod authors and offer to help. If you show them there's an audience and that there is someone willing to do the hard work of doing the translation, they might be receptive to making a translation possible - and a part of the mod. They might want to wait until they see the release version of KSP come out before they start working on it though.

I think the real answer to that question depends on what you think KSP is about: If it's about *flying/piloting* spaceships and exploring, then yes it's cheating. It'll do quite a bit of the flying for you. If it's about designing and executing space missions and running a space program, then it's not: it just automates some of the more routine and and mundane parts of the mission execution. So the answer depends on what you think KSP is.

(I didn't want to get into the weeds of 'well, except for...' )

There's a revived version that works in 1.2: Slightly different approach to the same problem: FTL Drive is a jump-drive, ESLD Beacons are warp-gates. They behave vary similarly, but who has to pay for the jump is different.

I just want to say: I'm impressed with the amount of effort you've put into this.