undercoveryankee

ModuleManager tip: At least with MM2, you can do "%name = value" to add if it's not there, replace if it is. Not really important if you're changing one part and you can look at its original file, but really nice for a wildcard rule that might hit some with the value and some without. Edit: Thought I was on the Interstellar thread here. Don't worry about the new feature while you're trying to troubleshoot.

If you set PhysicsSignificance=0 in every part config that mentions PhysicsSignificance, the only real consequences will be mass, flex, and possibly overall game performance if you're calculating physics on a lot of formerly-physicsless parts. (Some complex constructions of cubic octagonal struts may turn out to be more stable if you keep the cubes physicsless, but I haven't tested that.) A few parts, such as landing gear, are dynamically set to physicsless without mentioning it in their .cfg files. I haven't heard of any good way to change those.

That's deep in stuff that's managed by the Kethane plugin. You might get an answer on that thread.

If you're running things like life support or RT2 that add power draws to everything you put in orbit, you may want to move RTGs earlier in the tech tree so you're less likely to get flight-capable fission reactors before you get RTGs, and/or find a mod that gives you chemical fuel cells before you get anything nuclear.

It would be a good mechanic to have available for folks who are doing realistic-type tech trees.

I don't see something like this (basically, IIUC, having to complete a mission goal in addition to spending science points to gain access to a tech node) making it into stock for several releases past 0.24. It might be fun to prototype as a mod, but also a boatload of work. You'd basically have to write a whole new tech tree to put the parts where you always have a logical connection between the mission goal and the parts it gives you access to. For some parts you would want to add "prototype" versions with reduced capabilities and then gain full function in a later node.

Mission Controller Extended and Kerbal Construction Time give you credit for recovering any stage that's despawned in the atmosphere with enough parachutes that it would land safely if you were following it. If I start building reusable, I'll do something similar even if I'm not running the mods that keep score. One or two test flights where I focus on the booster to make sure it comes down, then give myself credit for a reusable booster even if it despawns.

The PhysicsSignificance flag is counterintuitive. PhysicsSignificance=0 means the part acts as a normal physics object with mass, drag, etc. PhysicsSignificance=1 tells the game to disregard the part's mass and drag in flight. In 0.23, there weren't many physicsless parts. I know plane landing gear, ladders, and cubic octagonal struts, but those are the main ones you'd encounter. 0.23.5 makes more parts physicsless, including radial batteries, small science experiments, RCS blocks, OX-STAT solar panels, and probably lights. The new decoupler being physicsless out of the box was possibly an oversight since the smaller decouplers didn't change. By making it physicsful, your ships will be a tiny bit heavier in flight and possibly experience a little more flex at this decoupler's joints. That's the worst case I can think of.

When I started adding Interstellar seismometers to my Mun descent stages, I started deorbiting my ascent stages to provide impacts. Never got any science with an ascent stage because all of the stages had the same name, but a couple of times I was so excited to see whether it would work that I forgot to transfer any of the stored science to the command module.

In stock, the part that Interstellar uses as a precooler is called "Radial engine body," and it's just an aesthetic variant on a structural fuselage. Interstellar renames it and adds a module that works with the changes to the engines. The ModuleManager config with the changes is in Interstellar's folder. The 200km apoapsis on airbreathing engines was probably the bug in FAR 0.12.5.2 that made those engines overpowered at high airspeed. The precooler code has no effect on how an engine's thrust varies with speed or altitude; it only governs whether you get Interstellar-applied heating in addition to stock heating.

Interstellar adds a module to turbojet, RAPIER, and B9 SABRE engines that adds additional heating to the engine at high airspeeds if you have intakes without precoolers. If you have a precooler behind every intake, only stock sources of heating will apply. If you have coolers on some intakes and not others, you will get extra heating as a function of the percentage of intakes that aren't precooled. The code doesn't care about the number of engines, only whether every intake is cooled.

My first station started out as a rough Skylab/Salyut equivalent, mainly intended to test transposition, docking, and extraction before I started doing Apollo-style Mun landings. Then I needed to start putting Extraplanetary Launchpads stuff in orbit, so I just stuck modules on wherever they would fit. Ended up with a bunch of docking ports that I can't use because they're too close together. I'm building a second generation of space stations now, and this time I started with a list of capabilities I want to have, so I can plan where I'm going to put everything.

If I'm warping longer than a trip to Minmus without something going on, I feel like somebody in Kongress is going to start asking questions about the lack of progress. So while my manned Duna expedition and unmanned Moho orbiter wait for their midcourse corrections, I'm replacing my original space station with a better-planned one, planning to ship a second station out to Minmus to support low-gravity mining operations, and doing some experimental flights toward replacing my Orion-style crew taxis with a reusable space plane.

What worked for EL 4.0 was to set the state to Building, then scroll down to the BuiltStuff node and change the remaining RocketParts cost from 0 to 5. The 5 RocketParts was to keep the build from finishing while KJR was still "stabilizing physics load" in case finishing the build the instant the station loaded would cause more shenanigans.

Looks like setting state = Complete would do the right thing in EL 4.1, with the "Finalize build" button in the GUI. In EL 4.0, setting state = Complete gets me a "Release" button but doesn't actually spawn any parts.

The next version after 4.0.3 was compiled against 0.23.5. Could be other issues with trying to use it on 0.23. I'm also not sure that updating the mod will do anything to unwedge a pad that's already in an unexpected state. I'll try to find a backup save where the pad was in "building" state and roll it back to 99% complete. If it works, I'll report what I did in case it helps anyone else.

This message is normal. MMI_Kethane.dll is intentionally a 0-byte file, and the actual code has been moved to Kethane.dll. As long as Kethane.dll loads successfully, you will have full functionality. If the message in your logs gets annoying, you can safely delete MMI_Kethane.dll. See http://forum.kerbalspaceprogram.com/threads/23979-Kethane-Pack-0-8-5-Find-it-mine-it-burn-it%21-0-23-5-%28ARM%29-compatibility-update?p=901989&viewfull=1#post901989

Or if they're spinning in the right direction?

That's a symptom of the unrealistically powerful reaction wheels that all of your cockpits have. More realistic to just nerf the reaction wheels across the board than to try to hack together special behavior in atmosphere.

"Just count the decouplers" is an excellent example of the programming maxim of "Try the simplest thing that could possibly work."

In my 0.23 career, I'm using EL 4.0.3. I started a build from a pad on a space station in orbit, then switched to a nearby ship. The active ship waited a few hours of game time for a transfer window, during which it drifted in and out of loading range of the station a couple of times. Each time the station with the pad loaded, RemoteTech2 stopped warp and MechJeb immediately returned to warp. While I was flying the other ship outside loading range of the pad, I hard-killed KSP and reloaded from the last autosave to revert a mistake I had forgotten to quicksave before. When I switched back to the station to check how much progress I had made, the build hasn't spawned, there's no build progress bar, and there's no option to start a new build. In my save file, the pad is in state "dewarping." I'm guessing that something in the sequence of when the pad was loaded and unloaded caused it to be saved in "dewarping", and loading a vessel with a pad that was saved in "dewarping" doesn't restart the finish-the-build sequence. Any advice on the best way to fix the save, and any advice on what not to do next time?

In 0.23.5, they gave monopropellant and xenon a new flow mode called StagePriorityFlow that tries to use tanks in earlier (higher-numbered) stages first. Since parts keep their stage numbers when docked, you might have docked two components that had xenon tanks in different stages.

On my outer-planets probe design, I have one GX-128 (huge unfoldable) targeting Kerbin, and then two Communotron 88-88s each targeting one of my relay satellites. By dedicating an antenna to each relay, I have continuous connection from anywhere above Kerbin's atmosphere out to the maximum range of the 88-88s. By the time those go out of range, the cone on the GX-128 should be wide enough to cover both relays.

There's a config tweak to allow EVAs to recover the data. You can apply it with ModuleManager. Search this thread for "dataIsCollectable".

As I understand, stock KSP already handles the temperature of every part for the purpose of tracking engine-generated heat. DRE just adds airspeed as an additional heating source and gives you some tools to cope with it. RAPIERs exploding as soon as you try to go air-breathing could be Interstellar's precooler code if that's installed. It's also the symptom of the old bug where DRE didn't fully handle ModuleEnginesFX engines, but that was reported fixed in DRE 4.5.