DStaal

Not really - except that there are mentions that it's a fairly major change to a lot of mechanics. If you really want both - and don't want to use the MKS resource chain for EL - there is a 'MKS_EL.cfg' file that has all the resource chain stuff, and if you just edit that file you can remove that change. Though really that complicates your bases as you need yet another drill, processor, and set of storage units. (I will note that I know there are a couple of other mods that have small recipes built into them - USI's version of Orion, for example. But MKS is the only wholesale replacement I know of.)

Note that the bug was removing some of the necessary parts of EL - the resource chain replacement is likely to stay in place. (Though maintained by others besides RoverDude.)

I'd go with 3 - Though you might want to discuss with @RoverDude and @Booots, because they use Karborundum as well in their mods, and the 'hard to get' is part of the balance. Another option would be to work with Neartea, and switch to something like his Antimatter (possibly combined with something...) instead. Or just define your own resource that can be refined out of Karbonite. (Or whatever.)

In those - if I remember correctly - they are the number of crew who would get the full hab time. If you put in less crew, you get more hab time than that, if you put in more crew then you get more hab time. It's a bit less meaningful there.

That was a bug in one version of MKS I believe - MKS is actually phasing out support for EL: RoverDude doesn't use it, and is switching to Ground Construction as more fitting his vision. (There will still be some user-supplied patches in MKS.) Either way, removing and reinstalling MKS from the current version should fix it - assuming he's not having some other problem.

(I will admit I haven't tested attaching things much - I'm just going on my impression of the process, and knowing that 'things attached to balanced things' is a bit of a beyond the original design of the feature...) That likely depends on what you have loaded. With the balancing, you can be sure the CoM is right, because it's where it was designed to be. Without it, it's up to you to get it right. I should note this is all second or third-hand info: I've played with the load balancing feature of MKS (which this appropriates - it's the reason for the USI-Tools dependency), but only a bit and I haven't done much testing of it.

Depends on what you're doing - only some parts can be balanced, they should not try to include each other when doing that. Most likely you want both: The spar will balance the Kontainers you attach to it, and the main hull will balance the various modules you install in it's bays. What you don't particularly want is parts attached to those modules or Kontainers.

What it should be doing is making each supported part that's directly attached to the balancing part physicless - meaning that it's weight gets added directly to the balancing part, instead of being off on it's own. That means that you can have tanks of varied resources and not have your COM move, because the tanks are all computed as if their mass was part of the truss. The basic purpose is that it should allow the freighter to fly straight, without having to micro-manage the levels of resources in all the cargo bays. It does have limitations in that what it does is convert attached parts to being physicsless, those parts shouldn't really have parts attached to them - as the physics gets wonky at that point.

Just to mention: If you want a slightly simpler approach than USI, you should take a look at the WBI suite of mods, most notably Pathfinder: It does a lot of the same resource transfer, construction, and setup mechanics as USI, but with it's own flavor. Most of the parts could actually be built using OSE Workshops and inflated using Equipment created locally, if you want. (Although there are some larger solid parts, particularly the new Bison parts in the Heisenburg mod.) It includes some integration to allow KPBS to work with it as well. (KPBS has some integration with USI-LS, but none with MKS at the moment - although I'm working on a mod pack for that.)

Asteroid mining is a completely separate process. The fact that they can only mine ore on a planet is irrelevant: On an asteroid, they get the local resources.

A drill with the correct module to extract resources from asteroids - since it's a different module than the normal drill module. The stock drills have it, I'm not sure what else might off the top of my head. I know you can check in the VAB in the right-click part description - it'll list 'Asteroid Harvester' or something like that.

I believe asteroid drills work much like Dirt extraction - they get all the resources of the asteroid, regardless of what they would get under normal planetary use.

Oh, definitely more parts is more load, and simpler parts is less load - but the question is whether replacing *some* of the parts with nearly identical parts that are simpler helps or not. You aren't reducing the part count, and you're increasing the model count (so it can't reuse processing paths as much) - while reducing the overall complexity of the ship. So how the physics and graphics engines handle things is going to make a big difference. (Does it create a single super-model that gets rendered? Does it reference each part's model separately? What optimizations have been done to parallelize things? Does it need to keep models in video ram? Etc...)

For mix-and-match like that, probably the easier way to handle things is to just have two sets of parts - which could be done fairly easily. (I'd have one set be just an MM clone of the other with the new models, myself.) However - I'm not sure if it would help in the situation you describe. Assuming KSP/Unity is moderately optimized, it's probably only loading one copy of every model being used in the current scene, and then just applying it where needed. So it depends a bit on where the bottlenecks are in the render on whether that would reduce overall model complexity (improving performance) or increase number of models in the scene (reducing performance).

Drills work differently on asteroids - you need a drill rated for asteroids, and then it will gather all materials on the asteroid, IIRC. That drill isn't rated for an asteroid.

Trixy heard that there might be some assembly work over at the new building site, so she offered to drive over the first load of Enriched Uranium and do a bit of set-up: (Note the KIS container of base parts in the background.) She also left a toolbox full of tools for further setup - although she had to apologize for not being able to finish setup, since there were only so many Material Kits available locally, and she isn't trained to get them from planetary storage. The Workshop she managed to get done by breaking down the parts of the lander frame for the base parts. Our actual build crew first set up our new transfer base in high Minmus orbit, before moving into a lander designed to get to and from the Minmus surface: (They landed at night, so no pictures there yet.) The Minmus landing pod is remarkably controllable - our standard autopilot managed to get it within 2m of the landing target, when we usually consider it good to get within 500m.

This isn't actually a question for this mod - EL allows mod-makers to define recipies, which get used by any launchpad that uses EL. In the MKS folder, there is a file called 'MKS_EL.cfg'. Remove it to remove this - and all other support for EL in MKS. (If you want to just delete the recipes out of it, you'll still have support for building via EL using MKS parts.)

I believe it's basically just an EVA hatch. None of the inflatable modules can be attached besides their one attachment point, as inflation isn't really well handled in KSP. (WBI works around this - but has other issues with inflatables.)

Solid rockets do not throttle - that includes to zero, I believe... Try reducing the amount of solid fuel they store slightly, so they burn out quicker. (I'll admit I rarely work with the solid rocket landertrons - the ships I want landertrons on tend to have engines already.)

Nope. It's specifically excluded. I'm not sure about depleted uranium off the top of my head, and that is also in those containers.

On the other hand, the settings are there for you to adjust the challenge to whatever you believe is appropriate and reasonable if you wish to, and I can see his point - it's a minor change, and if it feels right to him there's no reason not to make it. He'll still have to deal with both Supplies and Habitation on longer missions.

First off, try taking them out for a walk - just put them in a part, launch, EVA(?), and recover. Often that's enough to reset them. Otherwise - if things are working, there should be a field in the savefile with their old occupation. Presumably however if that doesn't reset them then things aren't working...

Actually, try here: https://youtu.be/hBwFFm9j_64?t=14m13s (Starting at 14:13.) Freighter MedBay module is one example, another being 16:07, the Passenger Cabin.

I wasn't even talking about those. I meant the larger ones - most were fine, but there were a couple with obvious gaps.

A quick note: I noticed while watching the review that some of the utility modules didn't line up with their space correctly, leaving a bit of space at the top. (Besides the ones Kobbatos mis-oriented and attached wrong.)