DStaal

Just another vote for this. First two are vaguely related, and you could probably keep it as a pack to add other science parts to. But the third isn't related at all, and should be separate.

Thanks. As for CKAN - I don't use it, and I'm reluctant to support anything like that (especially when it's complicated by dependencies like this is) without being able to test it myself. If someone wants to put it on CKAN that's fine with me, but that is not going to be an official release channel.

That is actually amazingly difficult in current versions of KSP, from my experience in trying to design something similar. The problem is the wheels and the collision mechanic don't mix well: A ship never collides with itself, and wheels depress on collision with the ground, depending on the weight they support. That means that there are two states for your rover: driving into the hanger (where the wheels collide with the floor and depress) and attached to the hanger (where they don't collide with the floor and are at full extension). Docking the rover requires a docking port that's at both heights: It needs to be low enough for the rover to come in and attach to it, and high enough that the rover can be released with the wheels fully extended without them clipping through the floor (and blowing everything up). These are mutually exclusive requirements. A rover which is light enough and has strong enough wheels might be able to get around the problem by just ignoring it (the depression of the wheels will be minimal) - but 'light enough' will be entirely gravity-dependent, so a rover that's light enough on Duna might not be light enough Eve. My current career goals require something similar (I don't care if it's a plane or not), and I'm iterating down to a design with a docking port on top, and using KerbalFoundries Anti-grav plates to rise up to re-dock to it, though I haven't quite gotten the design finalized yet. If anyone has managed it recently (I believe the 'ships don't collide with themselves' part was a recent optimization) and can prove me wrong, I'm interested.

Yep, just spamming the experiment doesn't really help - you can only run it a couple of times per biome, after all. Let's leave it off the combined inflatable parts, and I'll have to take a look at the Tundra parts. (The Ranger part is single-use, so no issues. Not sure about the Duna either.) Yep. Efficiency is this pass. It's likely the greenhouses themselves won't get the option (switching modes is problematic on them, because of how they are set up) but the Algae and Greenhouse containers should probably have an efficiency mode.

Ok, had a busy couple of weeks where I didn't get much KSP-related done, but I'm back to work now. Things so far are first pass - no balancing has been done, just trying to make sure concept works. I've got the drills working, I think. (Loading KSP for last test now.) Currently they are as powerful per-bay as the smallest MKS drills - but have three bays instead of just one. Which should be just slightly less powerful overall than the mid-sized MKS drill. What's the thought on MetalOre? It's basically an EL-only resource - we could remove it entirely if we wanted, but that makes the assumption that the MKS recipe file will stay in place. Which it probably will... And if we remove it here, should we be removing/replacing it in other places? Also on the drills: I'm considering dropping needing SpecalizedParts to switch drill-heads. You only need 1 at the moment, but the idea is that since these drills are more specialized than the USI drills they're easier to switch between modes - but only within the modes each drill is designed for. (I also thought about reducing the cost in Specialized Parts or Material Kits - but both are nominal costs, and we had the discussion about 'if it costs less than a container's worth, it really doesn't feel different'.) I also started in on the ISRU, and I'm thinking we may want to split that into two as well - while the list of MKS resources it should process is fairly short, that doesn't count the *fuel* resources it should handle - Which is a lot of processor modes. (LF, Ox, MonoProp, LF+Ox, all the above for Karbonite, and possibly one or two others.) So I'm thinking we may want a 'fuel refinery' and a 'resources refinery', just to keep the swap lists within reason. And did we ever work up a list of parts that should have that science experiment?

That is not exactly true... Water is not used in any of the USI-LS parts - but it is used in other USI parts that have recyclers. (MKS has several, for instance.) I haven't looked at that part recently, but if it's balanced against MKS's parts, (which are also balanced against USI-LS) then having water would be fine - water is used in 'purifiers' which are extremely high-quality recyclers, in the USI lore.

That should be enough. There was a bug a couple versions ago where that would happen, but it was thought fixed. What version are you running? (Note that even if you're out of date, updating to the latest version won't help these Kerbals. The only fix if they get stuck is to edit your save file.)

I'd go with simple - I either tend to have no handholds on a craft or lots and lots, so the less impact each has the better.

It's number 3 for me - after just plain Github, and my own github page.

Or mount them in a blimp... (Not saying for sure that's what he had in mind - but we do have the tools to do it. And I know for 'splashed' there's at least one unique result in there, IIRC.)

Those files are only used as defaults for new game setup - once a game is started, they have no effect. If you want to change the effects in your current game you need to change them in the LS window from the KSC view.

I do know that KEI tries to blacklist experiments that it knows shouldn't be run by it's system. You might want to take up excluding this over there. (I hadn't because I’m mostly ok with it - It'll only run experiments that have Kerbin surface results, which many of the MOLE experiments do. And I don't see the time spent as being any more interesting than roving around, for the limited runs that they have: The experiments would be run to calibrate them in the laboratories at the KSC, which is all that KEI simulates.)

Just as a quick comment: You can probably drop the AntennaRange configs - it was decided that AntennaRange wasn't different enough from the new stock mechanics to update to 1.2. (And I'll have to revisit - a *lot* of my craft depend on the conical dish antenna, as a low-profile, good looking, cheap, non-extendable antenna.)

This is part of the MKS mod. And both the wireless and the 'wired' power couplers work exactly the same way. The only difference is the range. I put 'wired' in quotes because no actual wires are run - it's just description text, and what the mod is modeling that you're doing. (That the Kerbals are running around on their own and wiring in extension cords when you aren't looking.) Short version: If you've got the power distribution to work, it should work with either set of parts. The 'wireless' parts are up to 2km, the 'wired' parts are shorter range. The only other differences are the model used by the parts and the flavor text. (And where they unlock in the tech tree.)

Go ahead. But the new system likely won't help them. (It's automated, and probably has some fixed proportional costs - if you think you can do better manually, go ahead.) If you think you can make money shipping Ore home right now, go ahead.

(Emphasis added.) Wait, what? Where do trade profits come from? (And what's the likelyhood they'll cover the idea I'd like to eventually make a mod on?)

Just to make the comment: Changing the settings effects *future* effects, not present effects. It will never return Kerbals to service (or life) who are currently out of service. It sounds like you probably exceeded their hab or home timer - hard to tell for sure. If you were able to grab the LS window while they were still up there we could likely have told you, I think. But rotating them home is the correct way to get them back.

Both Octosat and Coatl Areospace have small folding relay antennas. I haven't checked the range directly, but they are moderately powerful at least and are small enough to be used as secondary payloads. (Octosat is pretty much my go-to for relays, actually, as they fit the role fairly well:) That's a complete ship with xenon propulsion and RTG power. It's overkill for Minmus - but I didn't see any reason to design something else.

Which is part of why I was thinking an add-hock entry box - support as much as you can, but have a way for the user to adjust for things beyond that.

I'll admit I generally like the concept - and haven't had a chance to compare this implementation with Karbonite's or the upcoming one from NFT yet.

Didn't think you were. And I hear you on docking - those octo-hub docking ports are designated *only* for temporary docking - One set for crewed ships, one for uncrewed. Main purpose of this station is a transfer hub and waypoint - a Kerbal's first and last stop anywhere outside of Kerbin is here. I always liked the 'ball and wheel' hubs - gave a real feel of a part designed to let you go in any direction. (Though I'll admit they were a bit colorful to fit with current stock-alike.)

Agreed. (And that long stick in that picture is intended to be a station core. Not sure what I'll add on, but it's basically just habitation and fuel storage.)

Yep, all gone. Personally, I use mostly NFC Octo-hubs, but I also have some Tundra 2.5M hubs - usually the 'short' version. Somewhat obscured, but you can see both in use here:

Of the two, Community Category Kit is probably easier to work with: It lets you define a category for your part by adding a specifically-formatted tag to the part, no other changes needed. But it is a bit of an abuse to use it this way. (On the other hand - it's included in MKS as a dependency, so it's already available for the target audience.) I'll admit I haven't had much time the last week or so to do much. But if there's something specific you want me to look at, I'm game. (I took a quick look at the CLS configs, without testing in-game. You went for the simplest, which is probably fine. I might think about whether you want to allow surface-attach CLS on all parts or not, but that's a fairly minor issue really.)

The one argument against custom is that I believe that needs a dll to create the category, from what I've seen other mods doing. (Though you could piggyback on Filter Extensions or Community Category Kit, both of which allow categories to be created via config file.)