undercoveryankee

One of the purposes that Interstellar serves well is to demonstrate that there is no "magic bullet" that will make long-range space travel as routine as flying airplanes between continents. If a few busy-work mechanics or usually-not-useful options help to present a better idea of what technologies have been written about and what the challenges are, I don't mind that much. Part of the fun for me is the thought that if we ever manage to do this for real, this is what it might look like. There's only so much you can improve the gameplay without losing some of that.

The Sethlans/Akula series are lighter than fully fueled green reactors. When I'm trying to use unupgraded fission reactors on thermal rockets, the lighter weight helps with maneuverability and TWR. Feature request: allow FNNozzleController to search for an FNReactor module on the same part. The LV-N feels a little cheaty alongside the similar-tech fissions, and I'd still like to be able to convert it to Interstellar's modules.

Easy to do with any small, flat part. When the nodes are so close together, it will let you snap to the wrong one. At which point FAR thinks both the capsule and the heat shield are trailing because both parts' leading nodes are connected, and you end up with a "Rod from God"-level ballistic coefficient. If you weren't running DRE, you could probably generate the same unrealistically-low drag by clipping one of KW Rocketry's slimline decouplers into the capsule the same way.

You can probably calculate the EC required to transmit full power. All of the power draws are handled in the FixedUpdate event, which, per some discussion on the Interstellar thread, is called every 0.02 s. Because you might not know whether the panels or the transmitter get the event first in each frame, having 2 frames worth of capacity is probably safer than 1. So here's the design process: Figure out your panels' output at your target orbit. Interstellar's VAB Thermal Helper display will help. Keep in mind the conversion factor, 1 EC/s = 1 KW. Multiply that wattage by 2 frames, or 0.04 s. E.g. 1 GW (1,000,000 EC/s) * 0.04 s = 40,000 EC. Anything over half that will probably work. The full two-frame amount will help to prevent surprises on vessel load. If you need to add EC capacity to ships already in flight, modding the transmitter part is a graceful solution. If you're still in the VAB and would like to be able to share .craft files with people using unmodified Interstellar, you might prefer to install enough batteries to reach the capacity you calculated.

KSP has an issue where if a part has both top/bottom and side nodes, the part designer has to choose one or the other to attach to the parent. The ISRU has to be attached to the parent through its side node, and then other parts can be attached to it through the top or bottom if necessary.

I assume that you have a heat shield and you're entering shield-first. Check the FAR isShielded flag on the heat shield (in its context menu; you may have to enable it from FAR's toolbar button in the Space Center if you're running FAR 0.13.2 or higher). If it's "True", FAR has determined that the shield is inside a fairing or cargo bay and isn't producing drag. When I had a craft where this happened, I solved it by adding a 6S service compartment between the heat shield and the fairing base. If that's not it, we'll need more information. What versions of KSP, FAR, DRE, and ModuleManager are installed?

There's some discussion on the trajectory optimization tool thread to the effect that a full grand tour has too many constraints to globally optimize. We might be able to break it down into a few tractable pieces, though. For instance, Duna and Dres are small and won't change your trajectory drastically. If you can find an Eve->Jool->Eeloo or Kerbin->Jool->Eeloo window that passes close to Duna and Dres, the delta-v to enter their SoIs and still get the Jool assist will be manageable. If you want to add inner planets, you look for a Kerbin->Eve->Moho->[Eve and/or/Kerbin] that reaches the last flyby close to the time for the near outer-planets tour above. - - - Updated - - - http://forum.kerbalspaceprogram.com/threads/36476-WIN-KSP-Trajectory-Optimization-Tool-v0-12-1-Mission-Architect-Release!

Here is somebody else's list of interplanetary windows for the first ten Earth years, in case you need to see a lot of windows at once.

The expanding containers have the advantage of being more compact when empty than a fixed-size container of the same capacity should be. That makes it easier to ship empty containers up from Kerbin if you're using FAR. If you're launching full containers from Kerbin, you should probably be using fixed-size containers. For vehicles constructed in vacuum, I think the expanding containers have more capacity per part than the fixed-size containers in the EPL package, so I use them if there's clearance and I can find somewhere else to put radial parts.

MINAS started out as "Minmus INterplanetary Assembly Station." Then I decided to build a prototype in LKO before I ship one out to Minmus, so it's "Modular INterplanetary Assembly Station." The kerbals haven't spotted the Lord of the Rings reference yet.

Look at mission reports by Geschosskopf for the greatest collection of these I've ever seen.

Where does 0.04 seconds come from? Is it hard-coded, or does it depend on your max physics delta?

The @PART line isn't in proper ModuleManager syntax. I think you want: @PART[*]:HAS[MODULE[ModuleCommand],!MODULE[GoodspeedPump]] {

The .cfg files for the original Alcubierre put it in Experimental Science, and then TreeLoader moves it into one of the custom nodes. That may be for historical reasons, or for the benefit of people who would rather not run the Interstellar tech tree. The example .cfg's that ship with zzz's model copy all of the non-model-specific values from the original Alcubierre exactly, so the zzz folding Alcubierre also starts out in Experimental Science. But since the zzz part isn't official, it's not included in tree.cfg and it never gets moved. You can edit the .cfg's for the folding Alcubierre to reference one of the Interstellar nodes, or you can add it to tree.cfg in your save folder and let TreeLoader move it.

FAR added "service compartment" to the list of recognized keywords at some point prior to FAR 0.12.5.2. Once FAR started accepting "service compartment", these parts dropped the other keywords from their titles.

The key words ("fairing", "cargo bay", and a few others are recognized) should appear in the title of the part. The complete list of recognized keywords appears in GameData/FerramAerospaceResearch/FARPartClassification.cfg. You can edit this if you need to recognize a title that isn't already in it.

Whether a mod compiled against 0.23.5 runs on 0.23 depends on what it interacts with. If it touches parts of the game that didn't really change between versions, you may be able to get away with it. The last FAR that was compiled against 0.23 was FAR 0.12.5.2. Even if you can't run versions that were compiled for 0.23.5, you can at least update that far. RealChute has been compiled against 0.23.5 since RealChute 1.04. Seems to be one of the lucky ones.

The only reason to transfer EC between batteries is if you're about to undock and you want to make sure one side's batteries are full before undocking. I.e. if your space station has solar panels and your small tug drone relies on battery in place of onboard power generation. If that's something you'd do a lot, putting the pump module on batteries could save you some time.

Unloaded vessels neither produce nor consume resources, so when you switch back you will have exactly what you had when you unloaded. Same amount of stored EC, same amount of fuel. A good realistic-RTG plugin would do what TAC Life Support does: Keep track of the last time the vessel was loaded and, on subsequent load, subtract the fuel that would have been used if the unload hadn't intervened.

"Kh" with the capital K is Kerbal-hours, not kilo-hours. If your math is right otherwise, 36 Kerbal-hours divided by 10 kerbals at a productivity factor of 5 would be 0.72 hours, or about an orbit and a half if you're building in LKO. That sounds about right to me.

Yes. The code for thermal turbojets in FNNozzleController checks for precoolers. Physically, a thermal turbojet would still have a compressor before the heat exchanger so the air going through the heat exchanger is at a speed and pressure where the heat exchanger is effective. Same as a chemical-fueled jet, with the same need for precoolers. (You may need a few more intakes before you get your aircraft fast enough to notice, but the code is there.)

A realistic RTG would require a plugin to handle the decrease in available power as fuel decays and to calculate the amount of fuel used while the vessel was inactive. If anyone knows of a stable realistic-RTG plugin, I would run it. An RTG that: can be switched off and stop using fuel, produces constant power until it dies completely, and gets lighter as it runs if you let Blutonium have mass doesn't strike me as enough of an advantage over the stock RTG to be included.

A standalone RTG or fuel cell has the advantage that you can shut the big reactor down when you don't need it for propulsion. Good for saving nuclear fuel if the reactor's "idle" setting is more power than you'll ever need for anything else in your life. If it's something like a fission-powered plane or LKO-to-Minmus shuttle that never gets enough time between burns to shut down, being able to mount a small thermoelectric generator radially to the reactor could end up being the smart and realistic look. The current module for electrical generators in the Interstellar plugin searches the part's nodes for a connected reactor using similar code to what the precoolers use to search for intakes. We know that this code running on the parent part doesn't search radially attached children, but I'll need to test whether the module running on a radially attached child searches the parent. If it works, I'll do some research into the performance of thermoelectric generators and publish a proof-of-concept part.

What would be the purpose for marking the location of the ship you were just controlling? Are you suggesting that the science yield for repeat impacts should scale with the geographical distribution of the impacts the way that multiple sensors scale with coverage? Or are you planning to go look at the surviving debris and a marker would help to distinguish that impactor's debris from other debris?

I think 0.4.6 was the last version compiled against 0.23.0. If you're having issues with 0.4.7 on KSP 0.23, you might try rolling back to check whether the problem is version-related.