DStaal

Do you have any notes on 'randomly'? A common one I notice in my own games is 'shuts off on physics load', as ships are spawed a bit higher above the surface - so the drills didn't actually touch the ground. Another common issue (also at physics load) is a temporary overheat - KSP's heating modeling is fairly - erm, let's go with 'simplistic' - at high physics warp, which is often applied during physics load. Likely an install issue. Can we see a screenshot of your GameData and UmbraSpaceIndustries folders?

Also note that 1.4.1 is out in less than a week...

That's basically expected behavior. A new version of KSP typically breaks all mods that aren't just parts. If you're running a modded install, expect to wait a week or two for all your favorite mods to get updates.

Try the part left column, three down.

DMagic experiments can require electricity - but they don't change the stock experiments. Near Future Electrical has an optional patch that gets RTGs to decay over time - but I don't know anything that does the same with solar panels.

Honestly, I wouldn't bother. Most other mod makers seem to be waiting for 1.4.1 which is already announced as coming out in less than a week. (With the Making History expansion.)

It's also possible that is part of a depreciation scheme - and that Squad will remove the parts and models entirely at a later date. (Whereas if they did it now no one would be able to upgrade a save which used that part.)

Pilot is needed for pull - not for push. (You need a Kerbal to get stuff out of logistics - but you can put in without.)

You may also want to look at Scrapyard and the mods that support it - it's designed to give you the idea that you have the parts you've recovered on-hand, and can use them in a new ship. It's a support mod, doing little itself, but it mods that support it can do things with those parts like reduce time to build a new ship, or change the part reliability depending on the number of flights it's been on.

+1 to this, but I also wanted to mention that having a small Akita rover that can carry these around - and has a KAS port to dock in to the various platforms - can make this type of thing simpler. Another option for parts is the SK-62 Supply Kontainer (also carryable) - which fits nicely on an Akita bed. You could build it to carry two, and do everything in one trip.

Off the top of my head, Heisenberg and Buffalo/Pathfinder, both from WBI. I think I have some others, but those are the ones I can think of off the top of my head.

I tend to mostly use monoprop, as there are a good selection of thrusters and they work. Certain ships will get other thrusters - LF/O may get used for extra control on a boost stage, or on a large tanker that otherwise would have no need for monoprop, for instance. (And I've been known to use Xenon on a small probe that used that as it's main propulsion, just to keep from having to add extra tanks.) I've got a few mods that add lots of other fuels for various purposes, but I tend to avoid their engines and thrusters unless there's a *very* specific niche for them. The one other worth mentioning is that I've got a few that use CompressedAir, or a similar 'free' resource in an atmosphere. For craft that aren't meant to leave the atmosphere, they're worth it.

I stand by my two-pass solution. First pass, patch to apply a dummy module, second pass filter by AND NOT (which HAS allows - it's in one of the examples). First pass may require multiple patches, one per module you'd want in the OR statement. (Sorry, I didn't have much time for my previous post.) Of course, all passes can be in a single patch file - and probably should be, to make sure they're ordered correctly.

I'd go with two-pass: One patch applies a dummy module (Z) on B or C, the second applies on A not Z. If you want to be clean, then do a third afterwards that removes Z.

This is somewhat incomplete, and doesn't apply here. The incomplete is that there is an important third condition that often gets overlooked: A config with a ':FOR[ModName]' will also trigger the mod. The reason it doesn't apply here is that Pathfinder includes a Pathfinder .dll file, so that will trigger it, despite the fact that it's a couple of levels deep. So, no need to change. (And in fact, if changed to 'WildBlueIndustries' the patch might trigger when Pathfinder isn't present, as that's not the only mod that uses that folder.)

Note that the two main mods that have used EU in the past - MKS and NFE - both have methods for Engineers on EVA to transfer EU. It's not supposed to be *easily* transferable, but having someone move things around by hand is normally understood to be possible. So, CRP's stance is that you can't just pump it around the ship - you might consider matching them and having a function in WildBlueTools that allows Engineers to transfer EU - or include a patch that says as long as neither NFE or MKS is installed it should be transferable. (I suspect I could write the latter...)

Two options. First, trim the list: Or, use a different, scrollable (and sortable, and searchable) menu to find them:

Sounds like you should be close enough. Probably next is if you could post a link to log files of you trying.

I'm not sure you could make these parts smaller without having the Kerbals have to crawl through them...

I know you have to be pretty close to start the link - you could try getting your Kerbal closer to the tube. (Other than that, I don't see anything wrong. You shouldn't even need the screwdriver at this point.)

An extremely common error in writing MM patches is to write ':FOR[ModName]' instead of ':NEEDS[ModName]' - if some other mod you have installed has that error and specifies TAC-LS as the mod, it would cause this behavior.

I would suspect the extremely common MM error of some other mod writing ':FOR[TacLifeSupport]' when they mean ':NEEDS[TacLifeSupport]'. That will also count as 'installed' for ModuleManager, and trigger any 'NEEDS' patches. Only way I know of to check is to look at the config files from all your mods and looking for the FOR line. This can be done from shell in one command on either Linux or Mac, but I don't know if there's an easy way on Windows. Actually, I just looked at that patch - and it has ':FOR[TacLifeSupport]' *itself*. So it's triggering itself. If I was on my main computer, I'd be submitting an PR for a bugfix right now...

tsaven has given Nils a PR with new USI-LS patches, so that would be the rebalance mentioned - it's purely in this mod's configs.

I'm pretty sure MKS does that on it's own...

Yes. There's even a set of patches (that can be configured using Patchmanager) to integrate EL to various levels.