undercoveryankee

Exactly. The large-capacity avionics cost you in weight and power, so there's an advantage to be had if you give the payload only enough avionics for its own mass and put the rest on the launch vehicle.

Controls for those debug readouts are in the in-game FAR configuration window (FAR button in space center scene).

1.7 is still in pre-release. You can get pre-release builds from https://github.com/RemoteTechnologiesGroup/RemoteTech/releases , but they have not been tested as thoroughly as 1.6.3 and may contain bees.

MM generates a list of mod names from three sources: All loaded DLLs, regardless of their location under GameData. All direct subfolders of GameData. Any name by which a patch identifies itself in a :FOR[] clause. Once it has assembled the list of mod names, it runs a set of :BEFORE, :FOR, and :AFTER passes for each mod name. Any patch that doesn't specify :FIRST, :FINAL, :BEFORE, :FOR, or :AFTER runs in a pass called :LEGACY between :FIRST and the first :BEFORE. The location of the config file is irrelevant so that config files can be installed anywhere and you can always tell by looking which pass a patch will run in. But a folder called "MyMod" will always generate a set of BEFORE/FOR/AFTER passes for "MyMod", even if none of the config files in that folder run anything in the :FOR[MyMod] pass. So if the list of active mods is "ModuleManager", "Foo", "Bar", "Baz", then the sequence of passes goes like: :FIRST :LEGACY :BEFORE[ModuleManager] :FOR[ModuleManager] :AFTER[ModuleManager] :BEFORE[Foo], :FOR[Foo], :AFTER[Foo] BEFORE/FOR/AFTER[bar] BEFORE/FOR/AFTER[baz] :FINAL If you're writing a patch that needs to run before or after a patch that comes with another mod, the first step is to inspect the patches you need to interact with and make a note of what passes they're running in. If they run in :LEGACY because they don't specify :BEFORE/:FOR/:AFTER anything, then :FIRST runs before :LEGACY and :BEFORE/:FOR/:AFTER anything at all runs after :LEGACY. If the patch you need to come before or after specifies :FOR[something], then you can run in that mod's :BEFORE or :AFTER pass as designed. The only tricky part comes if you need to run before a patch that's already in a :BEFORE pass or after a patch that's already in an :AFTER pass. At that point, you'll need to look at the order that MM is going through mod names in the KSP log and find one of the involved mods whose :BEFORE or :AFTER pass happens at the right time.

Fractal_UK's original KSPI used DepletedFuel for fission waste that can't be reprocessed, and Actinides for waste that can be reprocessed. Does KSPI-E still need to distinguish between different types of spent fuel?

If you edit the WARP_PLUGIN_SETTINGS node (GameData/WarpPlugin/WarpPluginSettings.cfg) and set ThermalMechanicsDisabled to "True" it should do what you want.

For a bug that limits zoom of the map view, I'd look first at mods that touch planets or visuals. On that folder list, that would be Distant Object Enhancement, PlanetShine, and possibly CustomAsteroids. Just in case, get rid of TreeLoader. The last version where it even partially worked was 0.24.2. If the version of KSPI that you're running doesn't play nice with just TechManager, upgrade to one that does. I assume that the only thing under "Nereid" is FinalFrontier (tracks individual kerbals' accomplishments?)

For instance, it will be a lot easier to keep KSPI antimatter tanks costing a small positive number once everyone agrees on the cost of Antimatter.

If you install RealFuels and RF Stockalike engine configs and leave RF set to use realistic masses, the improved performance will shrink your rockets back to about the size that the default economics are expecting.

If RealFuels is present, most engines will have a choice of RF tech levels, and better versions will be available as you enable more tech levels through the tech tree. I could see requiring a minimum level of testing before an engine could be deployed at the highest unlocked tech level, or even giving a very-well-tested engine early access to the next tech level. But the obvious way to do that would require RealFuels to know about TestFlight, and that would have the potential to annoy people who want to use RF without TestFlight. Probably better to keep reliability and performance separate, maybe with some way to turn surplus flight data into science once a part has reached its max reliability.

STAGE_PRIORITY_FLOW is the mode used for stock XenonGas and MonoPropellant. It draws from tanks based on how many decouplers are between them and the root part, so tanks attached to early stages of a staged rocket will generally be used first. For resources that are likely to be found in radial tanks or used by RCS thrusters, STAGE_PRIORITY_FLOW saves on fuel lines or uses of CrossFeedEnabler. There may be some issues with generators, though - I seem to recall Karbonite having some odd issues with drills when the flow mode was set to STAGE_PRIORITY_FLOW.

There are serious reported issues with Fractal_UK's last release (0.13) on KSP 0.90. If you don't have a copy of KSP 0.25 handy, it is recommended to run one of the recently updated community versions of Interstellar. FreeThinker's KSPI Extended seems to be in the best shape at the moment. Every maintainer makes slightly different balance decisions, so there's no "definitive" version right now.

Out of the box, the only way to collect ocean resources is with one of the ISRU modules that can mine. If you're running one of the flavors of Interstellar that uses Water as its water resource, you can use anything from the Karbonite/MKS world to fill the tanks and then KSPI to process it.

The core RealFuels distribution configures tanks and leaves engine support to be handled by your choice of engine pack. See if the engine pack you're using has plans to do a config for the Vernor.

If you can't zoom the map in far enough to click directly on what you want to switch to, http://forum.kerbalspaceprogram.com/threads/89920-0-90-2015-01-17-Haystack-Continued-%28v0-4-0-0%29 allows you to search for things by name and switch to them.

DTS-M1 (rectangular folding dish; 45-degree cone) or KR-7 (small fixed dish; 25-degree cone).

Honestly, I've kind of taken a break from making KSP things. It got to where I felt bad for just playing my career game because there were so many things I'd said I wanted to work on someday. Chances are I'll work on it whenever I want to do a multi-kick departure in a save where I'm using kOS. - - - Updated - - - Good point. I still want to experiment with working backward from a pre-created single-burn node (the idea being that the pre-created node is how you tell the script what the final escape orbit should be). I'll have to look at how real spacecraft compensate for errors during a long mission plan.

People have a sense of the angles that are used for Earth reentry and expect the optimum angle for Kerbin to be similar. It sounds like at stock-Kerbin-scale speeds, the optimum approach is a lot steeper than it is for Earth, so you may have to unlearn some of the information you know that's correct for Earth.

In addition to crew space for six kerbals, your control station needs a probe core that's configured to do it. With out-of-the-box RT, the only probe core that supports remote control is the RC-L01 Remote Guidance Unit (2.5m stack core). If you want to configure another probe core for remote control or change the required number of kerbals, look at how the RC-L01 (internally "probeStackLarge") is configured in Squad_Probes.cfg.

Before we adopt WasteHeat as a standard, has anyone tested how KSPI reacts to other mods generating WasteHeat? There may be other parts of KSPI that every heat source is supposed to participate in, with possible unexpected behavior if you generate heat it isn't accounting for.

If you need more of an in-universe reason, some kind of structural or control issue on the Grey Havens Express could restrict all future traditional tugs to running single (no more double-tugs or triple adapters).

If you need to delete the Squad resource nodes, the MM code would be "!RESOURCE<selectors> { }", where <selectors> represents whatever you need to do to target the RESOURCE nodes you care about. If they all need to go, that would be "!RESOURCE,* { }". Whether that's what you need to do to get FSFuelSwitch working the way you expect is a Firespitter question, not really a ModuleManager question.

The documentation is often buried and sometimes out-of-date. REGOLITH_BIOME_RESOURCE nodes as described in https://dl.dropboxusercontent.com/u/19908938/CopyofRegolithAPI.pdf should work for what you're trying to do.

KW Rocketry is one that has angled RCS. That's the one I use.

I agree that the 2.5m engines are balanced against the pre-0.24 Mainsail and Skipper and could use a bump similar to what the Squad engines got, but since I play stock-size Kerbin with FAR and fly more small rockets than huge ones, I decided to tweak mass and Isp instead of straight thrust increases. I'll find my spreadsheet and ModuleManager patch next time I'm at my KSP computer. I have the VR-9D set up as an intermediate between the Poodle and the Skipper instead of directly competing with the Skipper, similar to how the Vesta VR-1 fits between the 909 "Terrier" and the LV-T45. That also made the VR-9D similar to a cluster of four VR-1s, much like the Poodle currently resembles a cluster of four Terriers. I think I have vac Isp around 370 or 380 with a mass around 2 tons and thrust at 400 kN. The Maverick-V I put between the Mainsail and the Skipper. Thrust I either kept at 1400 kN or dropped to 1200 or 1250, with mass and Isp changes to fit. Just a little more powerful than where you're using the VR-9D (sort of a Mainsail-light). Your 2000-kN Maverick-V is likely to be less useful because it's in a similar space to the stock LFB-KR1x2 and KW Griffon G8D.