undercoveryankee

Doesn't look like you're doing anything wrong. It's the known issue in 0.57 where the lack of a well-defined longitude of ascending node for a zero-inclination target orbit causes the argument of periapsis check to fail. Complete it from the debug menu, and then don't accept contracts for zero-inclination orbits until the next update.

A DP-10 will run without a fairing at those speeds if it's turned with its long axis parallel to the airflow. As for it still blowing off when it's inside a fairing, my hypothesis is that the ends are clipping through the fairing and causing FAR to detect it as unshielded. I've also seen reports that FAR doesn't detect the shape of the fairings right until you force it to recalculate by detaching something from the rocket (e.g. launch clamps). Does the version with the antenna in the fairing still lose the antenna if you add launch clamps?

KSP Interstellar's solar sail can apply acceleration under time warp.

It's not normal. The DP-10 doesn't have aerodynamic limits in RT2, and I can reliably get to orbit with an exposed DP-10. You're not the first to report FAR unexpectedly taking one off, though. Information that would be helpful to diagnose would include: Speed and altitude where you lose the antenna, as accurately as you can. What you think of as "relatively low speeds" may not be what others think of as "relatively low". Pictures of the rocket showing the exact location of the antenna that breaks off. If it's inside a fairing, include pictures both with and without the fairing. Screenshot of the flight log (F3 key) immediately after the antenna breaks off, showing any log entries that mention the antenna.

This sounds like the stock bug that occurs when the ship you're not controlling has an armed Klaw. Try with only one Klaw on the active vessel armed.

Expanding parts are caused by missing modules on a part with three or more resources. Post a log so we can figure out which modules aren't loading. Once we know what's not loading, we'll be a lot closer to figuring out why.

You should be able to do @MODULE[ModuleEnginesFX]:HAS[#attribute[value]] or @MODULE[ModuleEnginesFX],<index> to select a specific one.

The part you were using is still in the 0.12-series releases, but it's been renamed. The following ModuleManager config will make a copy of it under the old name so your existing vessels will load. +PART[DeployablePhasedArray] { @name = phasedArray1 @techRequired = hidden @category = -1 } If you allowed the game to save after a ship failed to load, that ship will be gone from that save file for good. But if you install that config and then load a copy of a save that has your power rover in it, it should work.

First step: What version of KSP and what version of Interstellar? Just to rule out compatibility issues. Second, there are hidden upgrades to the antimatter factory at Particle Accelerators and again at Antimatter Power. Each upgrade increases your efficiency by a factor of 100. If you don't have either, your efficiency is 1/10,000 of what it is in sandbox, which may well round to zero.

The tree.cfg under GameData gets parsed by the game and creates nodes that ModuleManager has no objection to modifying. I just don't think TreeLoader ever looks at the in-memory versions of those nodes after you've MMed them. A plugin that adds nodes to the stock tree based on MMable .cfg files would be a lot simpler than full-on TreeLoader and a better match to Interstellar's needs. Might be an interesting project.

There's one place in Firespitter's FSWingBase module that tests for FAR by name. Snjo may need to update that to also test for NEAR.

I don't see TweakScale exponents for the ElectricEngineController module in Interstellar_TweakScale.cfg. The Interstellar plugin just uses whatever max power is in the .cfg file, so to get max power to scale you'll need to have TweakScale handle it.

I've seen several people, including some text in the mod, refer to "Carnot efficiency" as a property of a generator. That's not quite right. "Carnot efficiency" refers to the efficiency of a Carnot cycle between the reactor temperature and the radiator temperature, which is the physical limit of efficiency that any heat engine can produce between those temperatures. The final efficiency in-game is then the generator's efficiency times the Carnot efficiency, which gets confusing to explain if it looks like the generator's efficiency is being labeled "Carnot efficiency." I'm curious whether you have any designs in mind yet for giving radiators a larger impact on efficiency than the current Carnot-based calculation, because I'm not sure of any simple approach.

There's not really a lot of overlap between KAS's struts and the grab/attach mechanic. With GrabbyStuff for grab/attach, ActiveStruts for strut ends, we can cover most of the single-ship use cases of KAS. It wouldn't be too hard for someone else to do containers with a branch of Hangar, also under a friendly license. It's one of the other beauties of good licensing: it's easier to build the system you need out of pieces built by different people.

TreeLoader does completely override any TechRequired setting on any parts mentioned in tree.cfg, even if TechRequired has been updated with a ModuleManager patch before TreeLoader runs. It's designed for trees that completely replace the stock tree instead of extending it like Interstellar does. If you go into the active tree.cfg in your save and remove any stock parts that are listed in their stock nodes, then other mods that move them around with ModuleManager patches will work again.

Not necessarily. The :FIRST pass is where any patches that don't specify a later pass get applied. You know that a patch in the :FIRST pass will run before any patch that runs :BEFORE, :FOR, or :AFTER a particular mod, and that running :BEFORE a pass guarantees that you'll run before anything :FOR or :AFTER that pass. Best practice for patch authors: don't publish a patch that runs in the :FIRST pass unless you actually need to run before any other mod. The fewer patches are in the :FIRST pass, the less likely the patches that need to be there are to get clobbered.

The one I'd try for VTOL balancing is Throttle Controlled Avionics at http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-(April-6).

Looking at the code on Github, Alumina-to-Aluminium is still active, and Alumina maps are in the Community Resource Pack. You can reapply the old extractor config or use the on-rails extraction module from Karbonite.

I thought "Force Roll" always came with a text entry field near the check box where you could enter the roll angle you wanted, so 180 degrees if you want "heads-down." If I'm wrong and that's only in Smart A.S.S., it would be a good thing to add to other occurrences of "Force Roll".

The 1.4.1 release candidates that I've been running have the same part and module names as the older versions. I don't expect anything save-breaking on the horizon.

The methane and aluminium engines are both cut. so I suspect there wasn't enough reason to keep the tank around just as Yet Another Alternative for thermal rockets.

I think he said the critical sticking point is Infernal Robotics. IR had its general part renaming and adoption of TweakScale partway through 0.23.5, and with the number of pre-switch IR parts he had in flight, keeping 0.23.5 around for that save was easier than trying to convert all of his IR parts.

That's expected behavior for parts that have ModuleCommand and don't have RT2's ModuleSPU. All MKS parts are meant to have built-in probe cores to save on part count, but they need to have ModuleSPU added like any other mod probe core. I shared my ModuleManager patch on the MKS dev thread at http://forum.kerbalspaceprogram.com/threads/79588-0-24-2-USI-Kolonization-Systems-%28MKS-OKS%29-%280-20-6%29-2014-08-26?p=1370273&viewfull=1#post1370273 .

There seems to be almost an even split between people who liked the "Atomic Rockets: the Game" feel of 0.11 and people who prefer the gameplay-oriented stats in 0.12. I've been working on a pack (ModuleManager patches to parts in 0.12 and additional configs using models from 0.11 that don't appear in 0.12) to approximate the old stats while still taking advantage of Community Resource Pack, TweakScale, and the updated plugin in 0.12. If I get to a stage where I'm happy with it, I'll release.

"Run test" comes from a stock module that some mods have added to their parts. TweakScale shouldn't affect it.