DStaal

FTT.

I'd add in Planetary Base Systems, and if you don't mind a bit of science: DMagic (and Universal Storage while you're at it). I'd also add REKT, for some fairly specialized-use parts. Take a careful look through the Umbra Space Industries catalog - MKS, USI-LS, and Konstruction add gameplay mechanics, but the rest are mostly parts. (Orion is borderline - and the warp drive mod as well. The latter is a major leap, while the former is realistic, but slightly different than anything in stock.) I'd recommend Sounding Rockets and the Surviablity pack - both are just parts, filling different uses than stock. SpaceY and SpaceY Expanded are nice to launch the huge ships you'll want to have to stick all these parts on. I could probably go on, but those are the ones that stand out.

A apoapsis of the homeworld + apoapsis of the target body should be 'maximum theoretical distance' right? (Well, moons make the calculation a bit more complex. But if you just take the parent body if it's not the sun, you should be good, right?)

Try: grep -r ':FOR\[TacLife' GameData I've seen some badly written patches that say things like ':FOR[TacLifeSupport|USI-LS]' - which is just non-sensical, but people try it...

(And of course there are those of us who don't care if it's in two places - it's not like it's an error, after all.)

?!?!??! I was under the impression that EU has *always* been explicitly blacklisted. I think RoverDude will have to comment here.

Well, it can't go into PL either. So you won't waste any.

And to add to RoverDude's response: No, you can't pull EU out of PL when you perform maintenance. Or any other time for that matter: EU is specifically excluded from PL. (As has been mentioned recently...)

The RT-500 is one of the recyclers - there's also the more powerful (but more situation-dependent) RT-5000, and MKS has a variety of them in various sizes. What it does is directly reduce supply usage (at the cost of EC): So for the 500, instead of using 10.8 Supplies per day, your Kerbal will use 10.8*(1-0.6) = 4.32 Supplies per day. Note that the 500 can only efficiently recycle the output of one Kerbal - any Kerbals in excess of that (assuming you have only the one recycler) will use the full 10.8 Supplies. So, for short trips, you're better off carrying more supplies: The 500 weighs the same as 600 liters of supplies, so if you need less than that, it's not saving you anything. However, let's say you're on a 60-day trip: you need 648 supplies with no recyclers. With a 500, you need 259.2. That's nearly half a ton of supplies you no longer have to carry. On a 100-day trip you save three quarters of a ton. 200-day trip you save a ton and a half. Etc. And this is per-Kerbal, with the least powerful recycler. This works in synergy with a greenhouse: If you have recyclers you don't need to produce as many supplies, so you don't need as much capacity from your greenhouse - or you need fewer, which means you'll also need less Fertilizer, etc. Now, so far we've been talking about one recycler - they do combine, but they do it in a bit of an odd way: If all of your recyclers are the same, you just add up their Kerbal capacity and you're done. However, if you have one that's more efficient, then that sets the max total recycling percentage for your whole ship - and you can use more smaller ones to get that percentage. So if we were to have an imaginary RT-700 that recycles for 1 Kerbal at 80%, with a crew of two you could use one 700 and two 500s to recycle for *everyone* at 80%. (And still have some capacity left over, I think.) This is why purifiers are nice, but situational: They can do up to 90% recycling, using water as an input - but *one* purifier means that's now the max for your whole base. Really good when you have *lots* of Kerbals and access to water, not so useful for smaller crews or when you need to ship water in.

I was thinking that it was more going to be an exospheric collector than an interplanetary collector: You set it up in low orbit to catch escaping atmosphere. (Vs. the atmospheric scoop, which you use in mid/high atmosphere.) Basically, you mine an area of space that has an extremely high particle density, so you don't need high velocity to collect an appreciable number of particles. (You should in theory still get appropriate drag, but there are some corresponding ways to mitigate that which you can use in planetary orbit, and KSP doesn't model that type of drag anyway.)

I'd say the appropriate ones are: Recycler, Greenhouse, and then debate on exactly what the part is and how it works between Purifier and Hab Multiplier. Purifiers are a bit of a specialty part: They should be heavy, take a heavy resource, and work best in combination with multiple recyclers. Hab Multiplers are things like cupolas; things which make the ship nicer to live in. They aren't that powerful on small ships, but quickly make large ships much more habitable. Purifiers tend to excel on large planetary bases (where you have access to water), while hab multipliers tend to be a bit more widely used - anytime you want to go over 3-4 months of habitation time, multipliers start being very useful. But the two basic parts you always want access to are a recycler and a greenhouse. Even a trip to Minmus and back may find a recycler worth the weight, and an extended stay of over a month or so starts to mean greenhouses are useful. I'm not sure Replacement Parts do much of anything at the moment - Wear was confusing, so RoverDude is rethinking the mechanic. (And even when it was there, it wasn't a visible resource - basically, you'd include it if the part is supposed to wear out over time. While it's full of Replacement Parts, it'll work at 100% efficiency, but it will use them up slowly...) In fact, they've *never* done anything in straight USI-LS, at least not out of the box. They were enabled by MKS - which brings up the point that there's a lot of overlap between the two mods. You might consider having storage for Machinery, MaterialKits, and SpecializedParts - all of those are MKS, but the first handles a wear-like mechanic for industrial parts, and the latter two are useful for a lot of things in MKS - including switching converters between modes, where they are configured to do that.

USI-LS uses the following types of parts: Recycler Purifier (90% recycler with a water input) Greenhouse (MKS adds two extra types of greenhouses, with different inputs.) Habitation Habitation Multiplier Both habitation and habitation multiplier parts should at least in theory be accessible by a Kerbal. (A hab multiplier can get away with 'they can poke their head in when they want on occasion'.) And of course for a modular system it's always nice to have storage for Supplies, Mulch, Fertilizer, and/or a combination of all three.

Anyone tried field-assembling an Akita? I can mostly do it, but it's like there's no mesh target area for the right-side forward wheel's attachment point: I can't target the Akita Core near enough to the attachment point to get the wheel to lock in. (I can target it behind the seat and see the attachment point - but if I try to mouse over the attachment point I'll be targeting the seat, or the ground, or the other wheel, or basically anything else but the core.)

(DAMN THIS FORUM SOFTWARE!!!!!!) Ok, here's a suggestion for balancing the MK-1 habitat, with a 2.5m Tundra for comparison: Part PartName Mass Seats CrewAffect Months Multiplier EC/s Machinery Machinery/s Tundra Kerbitat Tundra_Kerbitat250 7.65 2 4 18.5 0 0.4625 0 0 MK1 Habitat KKAOSS_Habitat_MK1_g 1.7 3 3 10 0 0.45 550 0.004 If I've got the math right, that should run out of machinery at the same time as you run out of habitation, for a full module. Comments? Suggestions? Should I use this same basic formula for the rest? (If I can remember what it was...)

I play with both - and at various times will use resource requirements or not, depending on a long list of things. (What I mostly do is have a 'general setting' for the save, but I'll change it on a spot basis if for some reason I don't feel like it should apply right then - usually when something's changed templates behind my back or a part gained access to the template system when I wasn't expecting it to.) I do tend to treat it the same as Merkov though: That WBI and USI are different companies, and have different resources that they need for things. I had forgotten there even was a converter between MaterialKits and Equipment.

So, looking through other LS parts. What do people think of these as a fluids-Kontainer and a long-range power transmitter?

(I've done that with pretty large ships on Minmus...)

Standard catch-up mechanics. KSP doesn't actually run the drill (or anything else) in the background - it just pretends it does. It does it in quick batches once you focus on the vessel. PL only gets pushed to when the vessels currently in physics range have excess material. Basically, you need to visit all your bases every once in a while.

Now I've just got to do my part. And hope my MM magic is as good as I think it is. But yes, beautiful.

TauPhraim mentioned that it can be stored in local Kontainers and sent to PL from there - but it has to actually be Kontainers, not some part that has a use for Machinery. I haven't tested that, but I believe I remember RoverDude saying he wanted to do something like that.

Working as intended. If Machinery auto-pushed, bad things would happen as converters/etc. suddenly wouldn't work correctly.

Currently: Tanks for MaterialKits and SpecalizedParts, and a couple of 'workbenches' that operate as MKS workshops. Also, logistics are put in on all the tanks and a couple of other parts - although it's balanced around the version of logistics in the last 'UKS' release of MKS, which operated slightly differently than current logistics. Most of the added parts are planned to be removed/depreciated/scaled back for the next release. I started this thread for planning and input; in general this pack is in development and not ready for users at this time - though it shouldn't break your game if you install it. (I won't make more promises than that.)

It is not needed. The goal is to make them work together better than they do - at the moment KPBS has some (outdated) USI-LS patches, but no other integration with MKS. Which meas you can build bases just fine with KPBS, no problem - but if you want to do any of the MKS resource-chain stuff (or even just the logistics), you need to have MKS parts. The goal with this is to change that - so you'll be able to make/use MaterialKits, ColonySupplies, etc, where applicable, using the KPBS-style parts, instead of having to hook up a Tundra or Duna part. Note that it is in a very incomplete state at the moment. When I did my original version of these patches KPBS didn't have any integration with EL either, so I threw that in. That's no longer the case; the current version of KPBS has built-in support and parts for EL.

As a quick recommendation: It's generally a good idea *not* to switch to the Kerbal being rescued until you have a rescue craft in place when using USI-LS. Life support tracking won't kick in until you get within 2000m of the Kerbal (or the vessel they are in) for the first time and they load into physics - so you can take your time getting to them as long as you've never loaded them into physics.

It's the center of the vessel, not the center of the survey module - I can't tell if there are connections on the other side of Pioneer module, but if there are, it's definitely going to be to far away. Even without, you're pretty close to 10m from the center of that ship: I'm assuming the Kontainer at the top is full of MaterialKits, which will bring the CoM up, and I can't tell if there's anything above that. Put a Pilot in the Pioneer module. That'll probably fix it. Even putting that Kerbal you have on EVA in the Pioneer module might fix it.