undercoveryankee

That looks right. One small radiator (or two if your center of mass so requires) will be enough for just about anything that runs reasonable numbers of solar panels at reasonable distances from the sun.

Actually, I've been watching the development of those mods with interest. I think it's possible to design the list of possible failures and their circumstances so almost all failures are "interesting" – i.e. it's possible to salvage the mission or the crew with creativity and good design. Random failures definitely need to be a mod and not part of the stock game, because if your first response to a failure is to hit "revert flight" there's no reason for the possibility to cross your radar. But some people like to play the kind of game that throws randomized challenges at you and you try to overcome them, and I don't see why it would be "bad gameplay" to implement that kind of system within the framework of KSP just because it produces a different style of game than stock KSP.

Look at the ModuleManager definitions in RemoteTech_Squad_Probes.cfg. Add the same modules to any other probe cores that are supposed to be unmanned.

The radial isn't as overpowered as the inline 48-7S. A trick you see a lot is to put several inline 48-7S on the same tank by hanging the off-center ones on cubic octagonal struts.

Fractal has said that the next version of Interstellar will convert EC to Megajoules when the EC bar is full. (Scott Manley thought his solar power satellites should be able to power their own plasma thrusters. If Scott Manley wishes for something on air, it's probably worth doing.) Until then, I've wondered whether anything would break horribly if you configured a KethaneConverter to generate Megajoules.

Solar panels generate waste heat equal to half their power production (1 EC/sec = 1 KW ==> 500 W waste heat). For reactors, waste heat is whatever power is generated and not converted to some other form of energy. I.e. if the reactor is driving a generator that's 20% efficient, the other 80% of the power you generate ends up as waste heat. Since generator efficiency depends on radiator temperature, and radiator temperature depends on the amount of waste heat generated, the math ends up a little over my head. Microwave receivers are 85% efficient, so 15% of what you receive ends up as waste heat. Microwave thermal receivers work like a reactor: anything that isn't consumed by a thermal rocket or converted to electricity by a generator ends up as waste heat. As far as I can tell, nothing in Interstellar generates waste heat unless it generates power. Instead of trying to calculate the total waste heat generated, I normally just use the thermal helper window in the VAB. (On Interstellar 0.10.3, press "I" in the VAB; on 0.11, it's a Toolbar button. If it's not showing, you may have to "Configure visible buttons".)

Smarter Gimbal is a module from the Exsurgent Engineering plugin, which RFTS applies to a lot of its engine configurations. It makes engines gimbal in roll, but it doesn't give you individual control of that axis. Quickest fix I can think of: How does the rocket fly if you allow the fins to deflect in pitch and yaw? That would at least give SAS more control authority to counter-balance the incorrect gimbaling. Someone on the RFTS thread might have more ideas. A centerline engine with pitch/yaw gimbal is pretty common in historical rockets, and you can't be the first to try to apply roll input to one.

In other words, the refinery wants to draw nitrogen from the atmosphere at the time of use. Similar to how you have to be splashed to centrifuge deuterium; you don't have the option to put water in tanks, carry it somewhere more solid, and then centrifuge it. If Fractal had added nitrogen as a storable resource, that would require new tanks, figuring out its performance as thermal-rocket or plasma propellant, and various other things that would make the update feel incomplete if they weren't done. Having the refinery access the atmosphere directly for now seems like as good a place to limit the scope of the last update as any.

The provided config files give the collapsible parts the same internal name as the original warp drive parts. A name conflict can cause the game to display a different model in flight than you saw in the VAB, so you'll want to give them unique names if you want to keep the original version as well. If you change the names, then they're no longer referenced in tree.cfg, so they show up in Experimental Electrics even if you're using the Interstellar tech tree. You may also want to change their TechRequired if this matters to you.

Look first at any other mod that produces, stores, or uses RocketParts. Extraplanetary Launchpads defines the RocketParts resource with a higher density than OCR. If the small SpareParts module weighs 10 tons, then you're using EL's density. In my game, I deleted OCR's plugin because I liked EL better. I kept the tanks because packing 10 tons of payload into the size of a small fuel tank makes FAR very happy. So for me, it's one of the few exploits I'm willing to use. If the density is the only problem, then the small warehouse should start with 2000 rocket parts and weigh 7 tons. If you have something else I don't have that causes it to start with its full capacity of 60,000 rocket parts, then the fully loaded warehouse comes out at 152 tons. If you want the parts to weigh what they would in pure OCR, then you can either remove any competing definitions of RocketParts or edit the capacity of the modules down to suit the density you're using.

KethaneConverter and TACGenericConverter do basically this. The only reason the plugin would need to have a complete list of possible conversions would be to enforce rules on which conversions could be operating at the same time as which others.

The precooler code should produce zero added heating if all of your intakes are precooled. I do see one potential gotcha, though. Are your intakes open or closed when you apply throttle?

When you're landing on a body with an atmosphere (Duna or Laythe), it's nice to be able to get upper atmosphere, lower atmosphere, and landed with one landing. That's why I put three full sets of experiments on my Duna lander even though I also have a lab in orbit.

http://forum.kerbalspaceprogram.com/threads/43839-0-23-KSP-Interstellar-%28Thermal-Helper-Solar-Sail-Impactors-Fusion%29-Version-0-10-3?p=685428&viewfull=1#post685428 Added to https://github.com/FractalUK/KSPInterstellar/wiki/Alcubierre-Drive so it doesn't get buried.

Imagine we have an ideal doubly-locked system. Then something comes along and perturbs it to increase the orbital distance slightly, so they are farther out than synchronous. Tidal forces will push the distance further out, as discussed, while at the same time slowing down the bodies' rotation. The final equilibrium will be synchronous again, but with the slower rotation rate the synchronous orbit will be farther out.

I'm all for making the planets we have more interesting. Add terrain hazards that you need to map from orbit in-game before you try to land near them. Procedurally generate non-repeating terrain textures. Add objects on the ground that you can interact with while you're landed. Using procedural generation to do all of that is cool. But if you start procedurally choosing planets' sizes and orbits, then you'll need a set of constraints to make sure you're generating a system that's stable and fun. Make sure one body's SOI never extends into somebody else's atmosphere or surface. Make sure that the amount of science within any given delta-v budget of Kerbin stays about the same so you can use the same tech tree with any solar system you generate. And even if you could reliably generate a solar system with an interesting distribution of places to go, you lose the benefit of a lot of community knowledge. You can't publish a delta-v map. You can't publish a list of launch windows. You can't publish a transfer calculator that doesn't need access to the save file. In a solar system with procedurally placed planets, I'd have two choices: Plan missions by trial and error, or learn all of the math that goes into those tools. Neither one strikes me as fun. I would probably experiment, but I would primarily play a solar system that everybody had, where there was published information available. That's why I think procedurally placed planets will always be too much of a niche option to be an effective use of Squad's resources. But I stand by the other thing I said: Do it in a mod and prove me wrong.

That's a lot of code for Squad to maintain for only some players to use. Could probably be done as a mod, though.

I've heard of Kerbin->Eve->outer planets working. Duna->Eve->Jool might be workable if the asset you're moving is already in Duna orbit. Duna->Kerbin->Eve->Jool or Duna->Kerbin->Eve->Kerbin->Jool might also be valid over a couple of orbits. But coming out from Kerbin to Duna and then turning around to go to Eve is not a useful assist.

There are some Creators Edition planets out there that have non-unique FlightGlobals indexes and break FAR. Could that affect DRE at all?

Tavert's optimal-engine charts show that 6 km/s single-stage with 1.3 G TWR is possible. Best engine choices for 6 km/s in vacuum would be 48-7S cluster or NASA KR-2L, depending on payload size. The aerospikes are decent if you expect to burn most of your delta-v in low atmosphere on Kerbin or Laythe, but for a multi-mission lander, vacuum performance is more important. Unfortunately, 6 km/s is close enough to the theoretical limit that your vehicle may end up a lot bigger than what you've been working with.

What the node marker shows you is the difference between your current velocity and your original target velocity. If the burn is a few hundred meters per second, then a fraction of a degree of pointing error can leave you with a difference of several meters per second at right angles to the original burn. Another source of error in executing a node is if your center of mass is off-axis. MJ has to apply some pitch or yaw input to keep you on the target orientation, and your engines gimbal and accelerate you to the side of where you're pointing. If you're executing a node by hand and you see the marker go flying out to the side, you cut your engines and either decide that you're close enough or line up carefully with the marker before you burn again. Mechjeb tries to keep the engines on at minimum thrust through much larger orientation corrections than I would if I were hand-flying. If you have a high thrust-to-weight ratio and a vehicle that's slow to turn, you can end up basically "orbiting" your target velocity. Solutions: Decrease TWR and/or increase pitch and yaw authority. Put your "control from" part near the engines and the center of mass to reduce flex so the calculated velocity is stable. Consider locking gimbal on engines if you have enough other sources of control authority. Be prepared to abort execution of a node if you're no longer getting improvement.

When the last update hit, the forums and Reddit were inundated with questions about the new features. The more I know about the update before it hits, the better I'll be able to understand and explain it when it comes out.

I assume that DRE doesn't try to calculate G tolerance based on orientation because nothing else requires part authors to define which direction the kerbals are facing inside a part. You can use the same part facing different directions on the rocket and imagine that the seats are internally set up differently, but the code would have no way to know what you were thinking. So the g-tolerance code has to be a compromise: better than you would be able to do in a bad orientation, but not necessarily what you could take in the optimal orientation. I can think of a couple of considerations that I would take into account if I were designing DRE: Gameplay-relevant: Both success and failure should be possible at Kerbin-scale speeds and altitudes. Consistent with the stock interface: Squad put a red arc on the acceleration scale on the navball, and the actual behavior should be consistent with the instrument. I think stock DRE is fairly good at meeting those goals. I definitely wouldn't call NathanKell a cynic.

What he said was that it was ~9.3 He per real-time second while running at high time warp. In fact, I don't see code in the telescope module to consume helium at all. It's the boil-off code in the cryostat module that depletes helium. If I'm reading the code right, the rate of helium depletion is proportional to the number of cryostats, so you should use the smallest number of cryostats that will let you stack-attach all of the telescopes. And be sure to power your cryostats. It's a fairly substantial power demand, for a fairly substantial benefit in helium usage.

A few posts back, it was mentioned that the smaller fusions are laser-inertial-confinement and the larger ones are tokamak designs. The different scaling curve is most likely due to the different operating principles.