DStaal

I'm sure there's a way to work with it, and the new version allows you to have rigid, semi-rigid, and non-rigid connectors, so there's more options. I just thought I should mention it to Angel so he can look at it while he's updating to 1.5 in case there's anything he needs to change - KAS (and KIS, which isn't even out yet for 1.5) is a major part of this mod.

Just a comment to make sure Angel is aware: I noticed that KAS has fully depreciated the older version of KAS, and released the new version for 1.5. I'm unsure if that will affect any of the pipes in this mod.

I can actually see that: You're doing a global/planetary survey, and then spotted a couple of things you wanted a closer look at...

They aren't completely dependent on each other. If you attach the ports and attachment points before launch, all of KAS is still usable. KIS is being worked on, from it's thread. It should be ready for 1.5 soon.

I just want to say the new US2 parts are jaw-droppingly gorgeous.

Pull request to MKS, and that looks like it. I'm a bit behind on my updates for KSP at the moment - since that's merged, I assume the version of MKS for KSP 1.5 should have the compatibility working again.

Also: The EL patches currently shipping with MKS are out of date. There's a PR, but MKS hasn't updated since EL did a major update.

Agreed - with good planning you can do quite a bit. I've gone as far as having multiple RCS configurations for a vessel, with SmartParts switching between them.

ScienceAlert is updated, and would also do what he wants.

Even stock drills and ISRU don't actually work in the background. They just pretend they do, by doing a catch-up when they're loaded into your physics bubble. For Messernacht's issue - unless they've completely re-worked the stock mechanics (Kerbalism does this, that I know of), check how large your batteries are. Catch-up is done in 6-hour chunks, and depending on how things are set up you may need to have enough battery to last out that six hours before the generation fills it again. However, IIRC the NFE reactors also intentionally shut down somewhat at high timewarp because of bugs in the stock heat system, so I'd avoid max timewarp when relying on them for power.

Luckily, the spreadsheet and a video on how to use it are the top link on the page you linked. And @Cooper42 - thanks and good luck to you. I did a fair amount of that (including writing up the above wiki page) a while back - but then everything got rebalanced and I haven't had the time to get back in to it. (Especially since on a 'support existing part' basis, the spreadsheet is backwards: You have to plug in the life support systems values and get the mass/volume of the parts - which are what you already know. If you wanted to really help, a spreadsheet that could start with the mass/volume for common cases would make supporting USI-LS *much* easier.)

Honestly, I feel like that's a mis-feature personally, and auto-remove that config file.

Honestly, I'd likely *prefer* it to show on engines that are not in the current stage - under the same logic that has it currently on non-retractable solar panels. It reduces the amount of thought the player needs to put in to finding the toggle.

Yes there is: Check the manual linked from the first post, it goes in to it fairly well. EL_ModuleRecipe is what you want to be looking at. I'd avoid getting arbitrarily complex however, as all it really means is that your building base needs lots of containers.

I can see usefulness for activate/deactivate current stage. (That is: Don't progress staging, just change the state of the engines.)

Yep, and this can be gamed - if it would run out of EC during the night, you can avoid ever switching to it during the night and it will never run out of EC. But in general: The window is only estimates based on last time the Kerbals were 'seen' by the game. Nothing actually happens until the ship with the Kerbals in it is loaded into the game, by being within range of it. (Or switching to it directly.)

? This mod is for *manual* activation of actions on groups of related parts, *without* having to set up an action group. Regardless of the situation. Are you sure you aren't confusing this thread with one of your other mods?

That's a UI.

Yes and no. Like any other process in KSP, it will only compute on an active, loaded, craft. Also like any other process in KSP, it will - at load time - compute how much it would have done since the last time it was loaded. So you can leave the craft and when you come back it will exist as though it had run the entire time you were gone. Typically that's good enough, but there's the occasional edge-case where it isn't. (And notably: the catch-up is done in 6-hour chunks. You need to have enough of any needed intermediate storage for the entire 6-hour chunk, or things will be modeled as 'shutdown' or tossing the extra out.)

Sounds interesting! May I ask what the UI looks like?

I believe it's true. I also could be mistaken.

I think a better way to think about it (and a slight correction to your statement) is this: A part with logistics capabilities can push any connected resource in suitable containers to Planetary Storage. A part with logistics capabilities staffed with a quartermaster/pilot can pull from Planetary Storage into suitable containers if requested. The parts with logistics capabilities are the logistics centers and the MPUs. (Note that the MPU's don't have a seat - so they can't be staffed, and therefore can only push.) Push to where? To Planetary Storage - see above. If from the fuel depot to the base - no. You can only *pull* using any logistics other than Planetary Storage. So if you have something on the base which uses fuel (or open the local logistics interface and start a pull manually). Note that the automatic pulls require a logistics-enabled tank at both ends - the Kontainers are, but most other fuel tanks are not.

Make sure you close your brackets, of course. But yes, if you just want to change *all* the experiments, that will work. Note this will also affect modded experiments, and stock experiments that already have to be transmitted several times. (I know some modded experiments which need ~10 transmissions before they're no longer worth transmitting - and even then it's often worth bringing them back as well.)

A bit more than twice as many times - you get less science each time you do a transmission, on a decaying multiplier. (Which I don't know how it's calculated. It's quite possible that if you halve the baseValue, you quadruple the amount of times you'll have to repeat it.) But yes, the total amount of science you receive would be set by the scienceCap.

This isn't hard, but it's not a stock slider either. You're going to need to write a Module Manager patch. (Well, you could edit the Squad files directly - but that's not a good idea.) Specifically, you need to change the 'baseValue' of the science experiments you want to edit - and reduce them. As long as the baseValue is less than the scienceCap, it should take more than one data collection to get all the data, I believe. So, for instance (untested): @EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]] { @baseValue = 3; } It's probably also worth looking at this thread, as it's dealing with similar: