jd284

How do I disable the saves created on deployment and launch of the kits? I have a good savegame management so I don't need this and it clutters my quicksave list. Didn't see any options for this in the settings or config files.

How do I express a condition "has ModuleA OR ModuleB OR ModuleC"? I tried various things like @PART[*]:HAS[@MODULE[ModuleA|ModuleB]] or @PART[*]:HAS[@MODULE[ModuleA,ModuleB]] but it only ever got applied if I have a single module name there. Is such a thing supported or do I have to copy my block many times for all possible combinations of modules?

Yes. However, if you have USI-LS the life support is shared between vessels, so you only need one setup for recyclers and habitats and such. But efficiency bonuses are per vessel only.

Yes, they have to be on the vessel. Doesn't have to be engineers though, miners also improve the drill efficiency.

In my opinion, that shouldn't be the job of MKS. There are plenty of mods that add interesting failure modes, and I don't think MKS needs to reinvent that wheel. The main problem I have with adding failure possibility is that it doesn't really work very well with KSP's (non-existent) model of background processing. If a failure happens, and I can't immediately react to have it taken care of, it's a bad design. So basically, failures should not ever happen during catch-up of background processing, only at the end of it. I don't want to come back to a colony after several months only to find that it failed and nobody told me. Nor do I want to visit every colony every day just in case. Personally I like the way machinery works, perhaps it's just a bit too "smooth" though. Maybe making it operate in steps would work better? Instead of linearly scaling throughput with amount of machinery, you could have steps of 25% and each time machinery falls by a quarter, throughput reduces by another 25% step. Like having multiple machines inside, and each time one of them fails.

It's possible that this is a new biome or it just wasn't accessible up to now. I think there was a bug like that although I didn't see it mentioned in the change log. Or maybe it's only accessible at level 2 and I've never noticed it before...

Thanks, I think I fixed it now.

I tried to balance the crew of my various bases to make the kolonization stats grow somewhat equally, but manually counting heads and checking how many crew present increases which stats go tedious very quickly. So I decided to change the kolonization monitor to display how many crew are present that increase each of the three kolonization stats. The coding wasn't too hard so I committed and pushed to a branch on my fork. So far so good. However when I tried to make a pull request from there, it included a dozen other commits and listed some changes to CustomAstronautComplexUI.cs that I didn't make... see here. Is this normal or did I make a mistake? I'm not very good with git, it seems to be completely orthogonal to my way of thinking. So please let me know if I should go ahead with this PR as is or if I need to fix something first, thanks. [edit] If I make a PR against MKS/master instead of MKS/DEVELOP the unexpected CustomAstronautComplexUI.cs changes don't show up. But I believe all PR's should be against DEVELOP?

Very late reply, but I've been thinking about this on and off for a while. First, I don't think either velocity or linear or angular momentum conservation is any more realistic than the others. I find it just as wrong when you move closer to the sun and gain velocity out of nowhere just to conserve angular momentum. The only reasonably realistic way to fix this would be to conserve both energy and momentum. That's possible, of course, but only following the (non-warp) trajectories. That means the warp drive would just boost you along your trajectory at warp speed, but not be able to change the trajectory. I'm not sure if it's worth implementing that mode though. It would be kind of interesting and quite realistics, but probably pretty useless for gameplay, since effectively it does nothing the time-warp button doesn't do already, more or less. (Except that it happens in less game time of course.) So you'd still need to do all the usual delta-v changes using regular drives, plus you've got a super-heavy warp drive to include in those delta-v calculations. I doubt that'll be a very popular option...

Is there any information yet about the requirements to deploy the upcoming new huge base parts? I think Roverdude mentioned that they need high enough Kolonization scores. How high are we talking and which score(s)? Just curious if I need to make a special effort to raise my scores (they're mostly between 150 - 180%).

In my case it took me forever to realize the habs could be reconfigured as greenhouses. Since then I've replaced all the ranger parts. So as far as I'm concerned, you're not missing anything except maybe a description or tooltip tweak on the Tundra Ag modules hinting that the expandable habs should be used as efficiency parts on space stations.

This is possibly a bug in the part config. It's missing the setting "FillAmount = 0.95" that all the other USI reactors have, except for the Duna and Tundra PDUs. Should be easy to fix it with a quick MM patch. This is intended, I believe.

In addition to the other point above, note that if you have a Ranger Sifter (the small one), it can only extract resources with at least 1% average abundance on the planet/moon. To extract the less abundant resources you need the large Tundra sifter. Or mine them directly with a drill, after you've found a good deposit.

Interesting, I like the idea of doing the underground model as IVA to avoid collider and clipping issues. I look forward to that mod getting a release. But I still maintain that MKS is lacking in large scale ground habitation, spamming the ranger habs just looks boring, and the hab rings on the ground is just silly.

Another thing that occured to me regarding habitation, and how there's no large-scale parts for ground bases as opposed to orbital bases that have the hab rings. At some point I wanted to just land a large asteroid and hollow it out for living space, which got me to thinking about alternatives... I believe the idea for most long-term settlements in space would be to burrow into the ground, for protection from radiation as well as meteoroids on planets like Mars with little atmosphere to stop them. So I think it would make sense to designate some Duna-like parts to function as entrance to such burrows. It would only function when landed, and ideally take some time/effort for the needed earth works, but then providing habitation similar to that of the orbital rings. The "landed" check would probably require some code, and would need to robust enough to ignore physics hops on load and such. Possibly it would just be the "expand" action that requires the "landed" check for simplicity. For the earth works, probably requiring a large EC construction cost plus some MatKis and SP like for the rings would already work. What do you think?

So about the Colonization Module (3.75m). If I put in three pairs of kerbals, only one pair seems to breed, and I only got one new crew member after the gestation period. I'd have expected three, or however many females are in the module. Is this intentional? If the module is supposed to be some sort of maternity support module, I think it'd be better if it worked according to the number of females present (as long as there's at least one male on the base?). To make it more interesting, this could also require the presence of a medic, and without a medic maybe only one pair can breed, or even none. (I think pregnancies would be pretty dangerous in space without a medic...)

You don't necessarily have to visit them every X days. Just make sure to visit them before you go to your crew base, at least after any period exceeding the local base storage. That way all the "background" production will catch up and produce sufficient PL stockpiles.

You only need water if you want to build up a large surplus of supplies ahead of your colonists or to resupply visiting ships. Otherwise you just need Mulch + Fertilizer(from Gypsum), which will give you 10% more supplies than your kerbals consume: 10 Supplies -> 10 Mulch + 1 Fertilizer -> 11 Supplies It doesn't "check back". At least, stock doesn't, some other mods like Kerbalism do that at a large cost. What happens in stock instead is that when you visit your vessel again, the production backlog is "played back" in chunks of 6 hours. But there's no stock production when the vessel isn't in physics range, and thus nothing to put in PL until you visit the vessel.

Yes, because you hit a bug in USI-LS and the change back didn't work as a result. No other USI mod changes kerbal professions however.

Sorry to be so blunt, but you're wrong. USI-LS turns kerbals into tourists when they run out of supplies or hab. Looks like you triggered a bug in an older version of it. Anyway, the USI-LS thread has plenty of posts about how to deal with this.

I would like a larger form factor. I sometimes use the drive to maneuver large asteroids into an elliptical Earth orbit (6400 x 200) where they can be aerobraked to my space factory. But the maximum asteroid size is limited by the warp bubble size to about 800t. Keep in mind that currently only one part in a craft can have the warp drive or things will break. So adding nacelles to expand the field would require code changes to add this behavior, basically the actual drive at the center of the bubble would have to scan for nacelles and enlarge its field if it finds them. This would be a nice way to expand an existing ship though.

Like the others said, don't expect any support if you go that way. But you can probably get by with only having USITools installed and copying the parts and assets you want. Without USITools you won't be able to deploy the ring.

The wrench is in KIS actually. KAS is winches and harpoons and such.

OK, 42 at 60% is a good deal, and that makes sense since you only need a single part with a high percentage, for the bulk you just need throughput. The high efficiency recycler obviously would be a specialized part, but for bulk, a low percentage with high number of kerbals supported would be ideal. Basically you'd want to maximize the product of percentage times kerbal count. I haven't looked at the spreadsheet to see if there's an optimal percentage... could be that the "optimum" would be a million 1% recyclers... which would be a bit broken.

Then I guess the RT-500 doesn't follow the guidelines, because that can do 60% for 20 kerbs in 2t... so it's still by far the superior choice to spam it.