DStaal

Um, that's *not* the correct places. You should never have a Gamedata inside a Gamedata. You need: Gamedata -> WildBlueIndustries -> 000WildBlueTools and MOLE.

And Gravity Turn is integrated with MechJeb, so if you have both it creates a maneuver node to circularize (once it leaves the atmosphere) and has MechJeb execute it.

Yes and no - If they are both applied to the same fuel tank, then weird things will happen. But there's nothing in particular bad that happens if they are in the same game.

RD did have the concept of needing certain numbers of Kerbals for full production in earlier versions of UKS - but it was confusing and hard to realize what was going on, so it got dropped. As for the Geology bonus - on a new world, it will always start at 100%. And it will always increase over time, as long as you have Kerbals anywhere on/around the planet. So basically: It's going to be a moving target. Either pick a minimum that you need, or a maximum that you want to be able to handle, and work with those numbers.

When you get a chance, the one that needs to be looked at is the Algae container. I just wrote up the start of a config for it: I kept the current mode for the moment (we may want to drop to just Ore w/o Mulch as an input), and added in a 'Wet' mode at 0.05 Ore, 0.01 Water to 0.001 Fert and 0.0075 Mulch. So it's a bit faster at generating fertilizer, at the cost of water and more ore. Most of the water gets turned into mulch, but there are some losses. (There's also a Soylent Green mode in there, but that's easy: He's got that written up with quick replacements, and the Algae container is about the same mass and volume as his 2.5m converter, so I just duped it.)

Ok, I decided to try out the spreadsheet on something simple: The cupola. A multiplier of 1.75 for 2 Kerbals gets me a mass of 1.85 and a volume of 7.250, with an EC of 0.875 - The part's mass is 1.75, and that volume doesn't sound completely wrong... (I didn't look to closely at the volume yet, but width should be 2.5, assuming a length of 2m and a height of 1.5m, we have a volume of 7.5. I'm estimating here, but those should be close...)

I thought I remembered that someone worked out the math and that was only sort-of true: You still get the effects, just they get re-valued if it's off some ideal crew value. But either way, yeah, that could work. As someone who occasionally hits his head on low-hanging doorways: I don't think headroom would affect that much in these designs. There's plenty of headroom in the walkway (so you wouldn't feel cramped), and enough that the Kerbals don't have to think about it when standing up at the outer edges (where you might notice it), so the end feel would be that 'there's enough space.' I think for most of the KPBS parts floor space is probably a better measure - the exception being the Central Hub, where volume accounts for the fact that it's more than one story tall. (Which would be why in general volume would be better: Most rocket parts tend to be built with multiple levels to take advantage of length, where each level will be minimum height inside. KPBS instead sets uses length for a larger single-story floorplan.) And I'll admit what I'm doing is listening to your results, then throwing ideas for alternate configs at you to run the numbers on. I may work on a comparison table as well at some point, but I want to try writing up a couple of these to see how they work. That was one of our initial thoughts, wasn't it: That KPBS parts are lighter and easier to deploy, likely at the cost of durability. If we're still seeing that, as a part of this pack (not in the config for Nils277) we should probably look at adding in machinery use to balance in.

Just to clarify any misunderstandings: KPBS isn't my mod. This is my mod: It's designed to work with KPBS, and reuses/rebalances some of the parts. That said, it's received quite a bit of support from Nils277 (who is the creator of KPBS) and part of the plan is to push back to him an updated patchset for USI-LS. (Which this would be a part of.) That sounds really useful. And yeah, that was basically the plan - to add a Soylent mode to the algae container. (I may also do a hellfire container based on the current fuel cell, and a Soylent Starter based on the current Xenon container. Just to have a full set.) As I said: I'm focusing on USI-LS, since that's what my mod touches, but if it's that simple I may make a full set for Nils277. (Depending on how much work I feel like doing when I get to that part.)

In the process of working on my KPBS/MKS integration pack, I'm thinking of adding support for Soylent to one of the KPBS parts. Any thoughts/guidelines? (KPBS already has an 'algae container' - the thought is to use USI's mode-switching behavior to allow using that part as a Soylent array, in either red or green mode.)

At the moment, I believe the only thing with just those would be the Central Hub's water purifier, which is a high-end recycler for USI-LS.

Even then, if the user can say that 'I have specifically tested these old mods in KSP version X and attest that they work', I can see value in allowing the mod pack to support more recent KSP versions than the individual mods are rated for - especially for some parts packs, where the author may not bother to update if the pack still works. The presumption should be that it *doesn't* work unless the packer has verified it, but making the assumption of a good repacker who is actually adding value and doing their homework, having a mod pack that supports newer versions of KSP than the mods they repack would seem to be not uncommon, given the way mods work in KSP.

I actually find myself disagreeing with this one. One of the best uses for modpacks in KSP would be to bundle up a couple of old (abandoned) parts packs that allow redistribution but not modification with some patches that bring the parts into compatibility with current versions of KSP. (So the part mod is bundled unmodified, satisfying it's license, and the new mod which is a set of patches against that mod.) Then the mod pack would be supporting a version of KSP newer that the original mods that it includes.

Because I recently released a first beta, and the question did come up, and I would want people to know about this here in case they ask questions: I and a few others have been working on a KPBS/MKS integration pack. Pathfinder had KPBS integration. In working on the pack, we realized that making a KPBS/MKS/Pathfinder pack was going to be horrible. So, as a known compatibility issue: The KPBStoMKS integration pack intentionally disables (most) Pathfinder/KPBS integration. This only affects people who run all three of: KPBS, MKS, and Pathfinder. If you run those three mods together, you now have two options for the behavior of the KPBS parts: You can install the KPBStoMKS pack and get MKS behavior, or you can leave it off and keep Pathfinder behavior. This is intended to promote user choice: As the KPBStoMKS pack is a separate mod, it can be downloaded and installed separately from any of the other mods, allowing the user to choose to use it or Pathfinder depending on which they install.

On the 'license expresses permission' issue: I think this is actually part of a much larger issue (beyond KSP in scope) - 'legal' and 'right' are not synonyms. Europe is a bit better on this with the concept of 'moral rights' over a work, but in general I figure a license is 'this is the most I can stand' - you have the legal ability to do these things. However, I expect most people to be decent human beings, and respect that it's my work and something that therefore reflects on me, and using it in a way that annoys me or reflects badly on me is likely to liquid me off. So, my mod-in-progress above is licensed MIT, because the legal limit for me is to make sure I'm credited for my work. But if you want to be a part of the community and not a douchebag, asking for permission or at least being very grateful and nice (and clear) about who's put in what work, and what you are adding in (and actually adding something of your own in...) is always helpful. I can of course change the license and treat everyone as if they are douchebags by default. I really don't want to do that, because in my experience douchebags are the exception and not the rule, and can usually be dealt with in other manners - including social pressure. (And quite often by appealing to the admins when their actions inevitably call for it.)

I'll admit I'm partly just playing with GitHub's tools, to see what they can do. Also you can take a look at this: https://github.com/DanStaal/KPBStoMKS/projects/1 I agree on your thoughts on floor-space. It almost makes me think we should add a small base hab multiplier to all crewable KPBS parts - they're a bit nicer to live in than normal 'space cans'. How would those numbers work with the MK1, if we added in a 0.2 multiplier or so? Then the hab on it's own isn't all that much better than the mini hab - but you start putting together a KPBS base and pretty soon you have a much nicer base than if you were just stringing together mini-hab 'tents'. On the size of the MK2 - it starts out the same size as the MK1, and then unfolds basically half it's width in two directions, right? Wouldn't that basically double it's volume? Now, there's a bit of a slope to that (and there's some extra space at the ends), but call it 75% and you get a volume of 18.73. 60% gets you 17.12. Those sound like better numbers to me. I should really get into the spreadsheet on my own at some point again... Again, what about multiplier without hab direct? Especially for the greenhouse, I don't think it should have hab time on it's own: It's not a place where Kerbals live. For this one we probably need a comparison table between this and the various greenhouse/supply generation facilities in USI-LS and MKS. (And the small greenhouse and algae containers.) Then we can start to get a better feel for how they compare against each other.

I'm for it. However, anyone who's thinking about using it should be aware of the fact that this pack disables Pathfinder integration - this has the potential to break bases. (I had two bases disappear around the time I put that in - though I'm not sure if that was the cause, as they took several non-KPBS vessels with them.) In theory it shouldn't affect any ships/bases currently in flight, but it's worth being aware of. (I've also barely touched the Ground Construction integration I threw in at the last minute. I mostly just saw that it kept getting asked for in your thread, and decided to throw it in. Notably I'm not sure if I did enough to get the Workshop to appear without EL also being installed.) When I'm a bit more sure of things I'll probably start an actual release thread as well, but that will likely wait until USI-LS support is done. (Stage 2.)

I've set up some better tracking for the USI-LS stuff on GitHub: https://github.com/DanStaal/KPBStoMKS/milestone/3

Which isn't impossible with Kolonization and production bonuses...

Nice. Since this is alpha, what are the chances something will blow up entirely if I install this into my career save?

The lighting up Kerbin from space is not a new thing. I've seen it with the occasional part for as long as I've been playing KSP.

That should work. Easiest way for a single file is to hit the 'RAW' button, and then use 'Save Page' in your browser.

That fan housing amuses me.

I believe MKS-Lite used to do this. But kinda the point of MKS is managing the production chain. (OSE Workshop - which also uses MaterialKits - may have something.)

And, for those looking at things: The Life-Support working branch has been updated be based off of the 0.9.5 beta, and I've pulled in KPBS's USI-LS patch for reworking.

Ok, since I can now type for moderate periods... Stage 1 Release 0.9.5 beta: New version for MKS 0.50+. New features include: Fully functional Kontainers (The old tanks are depreciated) Ground Construction support Construction Ports in KPBS form-factors Power distribution parts that fit in KPBS racks. Logistics Rebalance Weight Transfer for the KPBS racks and containers. Probably more I’ve forgotten. As I'm not quite up to play-testing at the moment and I'd rather wait until I'm able to use my arm a bit better (and we have USI-LS support) before calling this a non-beta release, but: Stage 1.