Johould

I'm not using FAR, so I would love an update of this whether or not it has FAR support.

It seems to work in 1.7. The flight envelope only gets stuck at 100% if the craft can't lift off with the active first-stage engines.

Could you reconfigure storage in the field? Reconfiguring ("repaint") the ISM storage parts is free (IIRC you may even be able to do it with any kind of crew).

I don't know why. Tourists should recover with resources, and always recover when back on Kerbin. It has happened to me before. If a Kerbal in the Astronaut Center is still a tourist I edited the save file to fix their job. For a Kerbal on Kerbin: In the "STATUS_DATA" record with the right "name" field, change "IsGrouchy" to "IsGrouchy = False" and "LastMeal","LastEC","LastAtHome" all equal to the current time. In the "KERBAL" record with the right "name" field, change "trait" to the right job (which may be recorded in the "STATUS_DATA" at "OldTrait").

It works in 1.7. I tested the smallest rings. It should work the same in 1.6. In the VAB it will always show the habitation time. In flight the ring needs to be expanded and the habitat started to get a lot of habitation time.

Has anyone found a workaround?

Yes. This file makes some station parts useful for life support: StationPartsExpansionRedux/Patches/SSPXR-USILS.cfg Without that patch, USILS would not be broken but none of the SSPXR parts would help give lift support. What is your good language?

The part that's a code bug counting a crew seat as 1 kerbal-month in the detailed part info in the VAB part list, regardless of your per-seat setting. Having 1 base month (and maybe no crew capacity) seems reasonable, I think the part ought to have some base time to compensate for only having a 0.5 multiplier compared to the Observation Cupola's 0.7 multiplier.

I think the stock ISRU and USI catch-up processing just uses your current EC production, so you need to go to bases when the sun is shining on them, but don't need enormous batteries.

The Observation Cupola is a pure 0.7 multiplier. The Viewing Cupola has an 0.5 multiplier, 1 crew seat, and text *claiming* it adds 1 month time, but it actually has 0 base months of time, so you only get the crew capacity, defaulting to 0.25 months / 7.5 days. @RoverDude there's a bug in the "Habitation Option" information shown in the VAB where the displayed months have +1 for each crew capacity on the part, rather than respecting your settings for how much time you have per seat (or just not counting crew capacity separately at all, because you get time from that whether or not you have the habitat running).

For some reason, living space needs to be "turned on" with the "Start Habitat" option in the context menu. A Mk 2 lander and a Hitchhiker will give 2 kerbals 337 days of hab time if that habitat is running, and only 22 days if it's turned off (including the default 15 day grace period). Also note that the Viewing Cupola claims to give 1 kerbal-month of base time in the editor but doesn't actually add any base time at all! Otherwise it would be a nice little part for Minmus missions.

In MKS 1.1.0.0 the Flex-O-Tube is titled "MKS Kerbitrail(tm) FlexOTube". What version of MKS do you have?

That happens for me when the craft can't take off with the engines that are enabled in the first stage. Speaking of engine switching, @Booots, it would be even nicer if the optimal ascent calculation also let you pick the starting conditions, for planning the flight of spaceplanes after switching engines or engine modes. Also, should the new axis settings work to calculate the flight envelope over a wider range of conditions? I'd really like to be able to plot spaceplane performance all the way up to the top of the atmosphere and orbital speed.

@allista Trying to install 2.3.1 from your spacedock link above, I notice that the AT_Utils it includes has a .version file identical to the github release of AT_Utils 1.6.3 from the github release, but other files differ. I install mods manually and try to check that any common dependencies are either identical or one mod includes a newer version, so this was pretty confusing. I got Ground_Construction-2.3.1.zip (md5sum 902aa00ff18f7b373071c0ee424858be) from https://spacedock.info/mod/1123/Ground Construction/download/2.3.1 and AT_Utils-1.6.3.0.zip (md5sum bb0a52a56ef42998e6ea60b5e0b37ada) from https://github.com/allista/AT_Utils/releases/download/v1.6.3/AT_Utils-1.6.3.0.zip diff says Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/000_AT_Utils.dll differ Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/001_AnisotropicPartResizer.dll differ Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/002_MultiAnimators.dll differ Binary files gc2.3.1/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll and at.1.6.3.0/GameData/000_AT_Utils/Plugins/ConfigurableContainers.dll differ Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins/PluginData/000_AT_Utils: config.xml Only in at.1.6.3.0/GameData/000_AT_Utils/Plugins: SubmodelResizer.dll Only in gc2.3.1/GameData/: GroundConstruction The 000_AT_Utils.version files in particular are identical. Here are MD5 checksums of the DLLS in case that's of any use With identical version numbers and the extra SubmodelResizer.dll I assumed the AT_Utils.1.6.3.0.zip was better, and have been playing with it with no problems so far.

If you peek in the save file there's one event giving all the XP (I thought it showed up in-game as "rescued at level 5"). I think the Akademy passes along the XP from an entire flight at once as long as the student is under level 3 (I don't remember anything about skipping flags). My plan for breaking the level limit with a bit more effort is get the teachers to level 5 on their first flight.

Yeah, that's the same thing. Drills switched to ModuleSwappableConverterNew and should work fine, but with any other configurable part it will be a waste to have multiple bays on the same setting until this bug is fixed. The 0.12.0.0 release from https://github.com/UmbraSpaceIndustries/UmbraSpaceIndustries has the bug with multiple converters. Multiple bays stopped helping on parts using ModuleSwappableConverter when commit 800d15d deleted the SetEfficiencyBonus("SwapBay",...) call along with ModuleSwapConverterUpdate.cs, and didn't move the calculation elsewhere.

It's a bug. I have some earlier posts about it. Basically, RoverDude had to rework the code for multiple converters to work with 1.4, and also added a second nicer way to define parts with multiple converters (but it doesn't work if bays can become efficiency parts or recyclers). Along the way the bit of code was lost that added a multiplier for number of running bays to parts in the old style. (In the old style the part has a full converter module definition and the bay settings change which of those are running, and are supposed to add a multipler when multiple bays are on the same setting. So, KSP always sees like 8 converters or whatever, most of which are disabled. In the new style there are only as many converter modules as there are bays, and bay switching actually changes the recipe of the converter, so KSP only sees as many converters as there are bays).

Cool, that's what I thought. For long transfers the worry would be "anti-gaming" it, if the ship has been on a nice sunny transfer orbit for months but happened to be in the shade when you switched to it for a capture burn. I assume your "die" is accurate, but if so I'm curious how you like that difficulty setting. I went with the "Normal" career default of Kerbals just getting "grumpy" because I wanted to leave things easy for myself, but I think it has also made life support failures or poor planning more interesting, by leaving living tourists that need a rescue mission (maybe losing parts to "mutiny" would make things even more interesting).

Hmm, I hadn't thought that much about the difficulties. Now that you mention it, both parts have further complications. "best" might not be clear if different parts were have different subsets of the TCA modules installed. "retain configurations" would be especially tricky if that could include settings for engines across the docking port from the TCA part, maybe a ship is leaving a station and never coming back, or maybe it's an apollo-style lander+command module with the only TCA part in the lander and lots of settings meant for the combined ship. It's hardly a complete answer, but maybe it would make it easier for us players to understand if some settings respected the new stock mechanism for preserving vessel names across docking.

If a ship relies on solar panels, would we need to make sure to switch to it when it is in sun to avoid running out of EC? - In particular, if the Supply supply relies on greenhouses, what does it take to make sure they won't run out of EC during catch-up processing?

Is it possible to give a big ship more TCA modules in flight by launching a ship with more modules enabled and physically attaching it to the other ship by docking or with KAS? It didn't seem to work. Wouldn't it also work with two engines throttled to control pitch and enough reaction wheel torque to control roll? I've seen both axes controlled by thrust or both controlled by wheels, but I don't know if I've mixed it up like that.

What parts on there are even engines? I only see a downward pointing engine on the tail. TCA can't help if there's no way to adjust throttle to balance the engines. Show the TCA panel with the engine settings, in a VAB view with the thrust and CoM markers.

Letting multiple separators overheat is only like 25% faster than one separator at optimum temperature.

There isn't an in-game setting or explicit settings file. I think adding an "EVARange" field to the USI_ModuleRecycleablePart will override the default instance. That menu option is added to all parts by the MM patch MKS/Patches/ScrapParts.cfg, you could edit that or have a second patch run later. Without editing files, the only option for easier disassembly is to bring along the "Demolition Charge", which can destroy just the part it's attached to, or the whole vessel (can be added with KAS/KIS). Using the demolition charge should also give you a choice to "Recycle" the affected parts for MKTs in the same amount as the "disassemble part" option, or "Demolish" for a larger mass of Recyclables.

I don't think so, just the manual refresh button.