undercoveryankee

Or just make the config edit to allow discarding scrap metal ( http://forum.kerbalspaceprogram.com/threads/89774-24-2-%28V-16-7%29-ExtraPlanetary-Launchpads%28EPL%29-Karbonite-Adaptation-%289-10-14%29?p=1505483&viewfull=1#post1505483 )

Some of the parts have the ability to turn nodes on and off from their context menu in the VAB. E.g. so an HX module can have either one large node for attaching to a similar-size part or an array of smaller nodes.

The Metal resource is shared with EPL, so EPL's 2.5m container is probably your best bet for Metal.

What FinePrint does is look for anything that has a stock or RT antenna module. If MCE is looking for a specific list of parts, or for parts that have the stock antenna module, you would have to bring that up with the MCE maintainers.

After my attempt to add ChargedParticles to the existing AM reactor succeeded only in discovering an implicit assumption in the plugin that no one would ever try that, I'm taking another look at the AM torch. A Vista/VASIMR-like ability to vary the Isp by varying the ratio of inert hydrogen to reactants should be possible. Atomic Rockets suggests that the hydrogen-rich limit has an Isp of around 5000 s, with the hydrogen-lean limit around 100,000 s. Efficiency of energy transfer from the pions to the hydrogen would likely vary from near the gas-core estimate of 35% at the rich end down to about 10% on the lean end. I'll try to whip up a plugin to handle the variable-Isp setting and hammer the physics into a plausible performance curve.

The BASIC_NTR_PROPELLANT nodes control only thermal engines (either standard thermal nozzles or upgraded thermal turbojets in propellant-using mode). There are separate config files for plasma and ATTILA thrusters, and the Vista kind of does its own thing. Here's the rationale for capping the Isp of thermal rockets: the Isp being proportional to the square root of the operating temperature is based on the physics governing thermal rockets at fission-reactor temperatures. 3000 seconds corresponds to the temperature where the heat is enough to ionize the propellant or destroy a non-magnetic nozzle, meaning the low-temperature equation is no longer realistic above that point. Adding the limit makes the combination of antimatter reactor/generator/plasma thruster more interesting, and it makes the combination of multi-gigawatt reactor and thermal rocket more useful for high-thrust cargo-to-orbit applications. We do lose some of the things we were used to doing with unrestricted thermal rockets. Some of those were unrealistic enough that any direct replacement should come from a softer-science mod and not Interstellar. Some can be adequately covered using other Interstellar engines. For some, there are approaches based on sound theory that the community could model within the spirit of Interstellar.

The theoretical optimum is energy equal (under E=mc^2) to the rest mass of the output antimatter and an equal quantity of matter. 1 unit of antimatter is 10^-9 ton (= 1 milligram) if I've counted the zeros in the config file right. 2 milligrams times c squared comes out to 179.8 gigajoules per unit of antimatter. If you're using ElectricCharge at the Interstellar setting of 1 EC = 1 kilojoule, that's about 179,800,000 EC to 1 AM.

Since the Interstellar tech tree supersets the stock tree, any parts pack that doesn't recommend its own tech tree is safe to add. It's cool to combine MKS/OKS living spaces with Interstellar engines. I did write a few config patches to improve sharing of resource data (see my signature), but all of those tweaks install to their own folder just like an easy mod install. Scott Manley's Interstellar Quest videos include a lot of Interstellar-powered ships with B9 plane parts. Just skip B9's HX-series big-scifi-ship parts or move them to the end of the tree.

Here's my config to give the AM reactor a charged-particle mode. I have the reactor filling its on-board ChargedParticle storage, but for some reason the magnetic nozzle still insists that its max thrust is zero. Anyone have any idea what I'm missing? // Proton/antiproton annihilation produces enough of its output in the form of // charged pions that it should be possible to use antimatter for things that // require ChargedParticles. // This config is estimated based on some numbers reported on the forums. REACTOR_FUEL_MODE { name = AMChargedParticle ReactorType = 32 GUIName = Antimatter (Charged particle) ChargedParticleRatio = 0.4 MeVPerChargedProduct = 0.7144 Aneutronic = True NormalisedReactionRate = 1.0 NormalisedPowerConsumption = 1.0 FUEL { name = Antimatter FuelName = Antimatter UsagePerMW =1.1111111111e-14 Unit = mg } } @PART[AntimatterReactor*] { RESOURCE { name = ChargedParticles amount = 0 maxAmount = #$../RESOURCE[ThermalPower]/maxAmount$ } }

In real life, tritium is extremely expensive. The closest to an "industrial" use it has in the present day, nuclear weapons, doesn't generate enough demand to support large-scale production, and it can't be stockpiled because it decays to helium-3. The cost in the config file is the cost of the part with all resources full. The cost of the ship is reduced by any resources that aren't actually full in the VAB. Since most of the 5 million is tritium, the default setting with only 2 units of tritium in the tank isn't that expensive.

Charged particles from an AM reaction are how the beam-core propulsion mode works. The unstable particles that it produces aren't as convenient to do ChargedParticle things with as the light ions from a fusion reaction (might not be able to run a direct conversion generator), but they should work for ChargedParticle-based propulsion.

The "Charged Particles" resource represents any energy that the reaction initially releases in the form of high-speed charged particles that can be contained and focused magnetically. Certain fission reactor designs (e.g. Interstellar's dusty plasma reactor) produce charged particles representing fission fragments that aren't absorbed in the fuel. The charged particles from fusion modes are whatever charged nuclei are produced, mostly helium-4. M/AM annihilation of baryons (protons and neutrons) produces a zoo of particles. In the long run, everything decays to gamma rays and neutrinos, but along the way you have charged pions and fairly long-lived electron/positron pairs that would count as charged particles.

The upgraded antimatter reactor claims to be "plasma-core" with power output in the hundreds of gigawatts. If you gave them an operating mode that produced that power as charged particles, you could use the existing magnetic nozzle and get similar performance. I think that would be a more "Interstellar" way to model this engine. I'll see what I can work up this weekend.

Not bad. I am starting to think we need a better option for large-scale antimatter collection than stacks of normal-sized collectors; collector towers multiply part counts and bear an awkward resemblance to airhogging.

The only unusual thing about what you did is using KAS to separate the impactor from the ship that would record. The flickering right-click menu indicates that something threw an exception trying to determine the state of those controls. Need a player log to figure out whether it's something in your install or an actual bug in the code. http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 explains where to find the player log on each supported OS.

Even if the license allows a fork without individual permission, I would recommend that if the upstream author asks you to give your fork a different title, you do so whether the license requires it or not. If we can make a habit of giving each other a little extra courtesy in areas where it's hard to write a bright-line legal rule, it becomes an easier decision for authors to put new code under a more community-friendly license.

It's working as designed. A plasma-thruster rocket that size needs a few hundred megawatts to deliver a useful thrust-to-weight ratio. They're really only useful with beamed power until you get the small fusion and antimatter reactors, unless you have the patience of NASA for multi-day engine burns.

It sounds like what you want to do is point at the sun (e.g. so solar panels on all sides of the satellite can get full sun). Sun:Position is a vector from your ship to the sun, which you should be able to convert to something you can LOCK STEERING to.

The TreeLoader mod that used to handle adding the later nodes nodes is broken. The best replacement available is TechManager from http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1.

http://forum.kerbalspaceprogram.com/threads/94876-0-24-2-0-25-Community-Resource-Pack-integration-for-KSPI-0-12-%28ORSX-version%29

TechManager will use most TreeLoader files without modification. The only exception is that TreeLoader implicitly preserved stock nodes that aren't edited or deleted in the file, and TechManager leaves the tree empty except for what's in the file. A tool to add the stock nodes to a config that relied on TreeLoader's implicit behavior might be useful.

My two cents on the methalox engine: The Deinonychus model looks like it's scaled down from the Raptor. It's on a 2.5m plate/tank end, but the engine itself looks like it would fit on a 1.25m base. If I saw it and didn't know what it was, I'd expect Skipper-level thrust. There's not really that much need for a 2.5m engine with more than about 1500 kN outside RSS, so I'm fine with leaving the thrust where it is. Isp is weaker than the real-world counterpart, but balanced fairly well against the engines in KSP 0.23 and below. With the NASA engines and the 0.24 bump of the 2.5m engines, I'd second bringing Isp up to the Raptor's figures. The assigned mass of 3.5 tons is slightly heavier than a Skipper. That's a satisfactory TWR when you're in the stock-size system comparing with stock engines. Upgrading to realistic TWR would go well with RSS, but I don't think an engine that good would be fun outside RSS.

I would expect any empty subtrees to be hidden by default, similar to how the stock 1000-science nodes don't show up until you install parts that use them. We might need a little bit of extra code to enforce the right behavior if an empty node is a prerequisite for an occupied node. The problem with combining different authors' tree bits is that the author of the config has to know where on the screen to put each node. If we can integrate code to automatically lay out nodes based on which ones are visible and how they're connected, then shipping partial trees with the mods that use them starts to make sense. As long as each coordinating modder has to be aware of the locations of other participants' nodes, it seems easier to combine all of the added nodes into a single tree.cfg that everyone who's coordinating can distribute, and let any that end up empty just be hidden.

ISTR seeing TreeLoader trees (e.g. Realistic Progression Lite) that had empty nodes visible as prerequisites for occupied nodes. If that was something TreeLoader did and TechManager doesn't, it could be worth contributing an automatic "prerequisites of occupied nodes are visible" behavior to TechManager.

Only looks and mass. If your payload is wider than the base, then the taller part gives you room for a smoother taper from the base to the full diameter. Or if you want to put batteries or instruments inside a fairing base, the taller one has surface attachments that are easier to get at. If your payload is shaped so you don't need the standoff, the smaller part is lighter for the same diameter.