ArcFurnace

That sounds like what I heard as well, and checking the PlanetResourceData folder shows no map for water on Eeloo, so it looks like this is correct. That actually sounds like a workable idea. In the real world, the US originally produced tritium in specialized heavy-water reactors (although it also never produced more than 225 kg in total ...). Later on it switched to lithium-containing control rods in a more standard fission power plant, basically equivalent to having tritium breeding enabled on one of the already-present KSPI reactors. The specialized tritium-production reactor could also be given an exemption from the power-control code that automatically throttles down reactors to the minimum necessary for the current power requirements, to ensure it would always breed at the maximum rate. The one problem is that doing this in the real world is incredibly expensive, which can't really be represented well in-game at the moment. “Typical tritium production capacity from fission reactors specially designed for tritium production is only a few kg per year, and at the prohibitive cost of about $200 million dollars per kg." - Yikes! (Another source gives an estimated price for deliberate production of $100k/gram, or $100m/kg; even buying from current stocks in Canada is $30k/gram) Alternately, once 0.24 comes out with budgets and such, Fractal could make tritium tweakable in the VAB, but extremely expensive.

I like the KW Rocketry mod tanks, with a mass ratio of 10 (propellant fraction 90%).

I decided to check this out. It appears that they do claim the ability to use things hosted on CurseForge ... but the rights for them to do so go away if you take it down, so you're not giving up any rights permanently. This also makes me suspect that they wouldn't bother trying to do that sort of thing, given that their rights to do so could be terminated at any time with no warning. Relevant paragraph, with extra-relevant bit bolded: By submitting, posting or displaying User Submissions on, to, or through Curse Websites (or its successors and affiliates), you grant Curse, Inc. a worldwide, non-exclusive, transferrable, royalty-free right to use, reproduce, distribute, display, perform, make derivative works of (except with regard to Submitted Projects), transmit or otherwise utilize such User Submissions on Curse Websites (or its successors and affiliates). In addition to the foregoing, you grant Curse the right to syndicate User Submissions and use User Submissions in connection with any service offered by Curse, Inc. With regard to User Submissions known as “add-onsâ€Â, "maps", "mods", or other types of Projects submitted through CurseForge.com or sites powered by CurseForge (“Submitted Projectsâ€Â), the aforementioned rights granted by you terminate once you remove or delete such Submitted Projects from Curse Websites. You also acknowledge that Curse, Inc. may retain, but not display, distribute, or perform, server copies of Submitted Projects that have been removed or deleted. You acknowledge that the rights granted to Curse to User Submissions other than Submitted Projects are perpetual. In addition you acknowledge and grant users of the Curse Websites a non-exclusive license to access your User Submissions through the Curse Websites (or its successors and affiliates) and to use such User Submissions as applicable by their respective licenses. Note that the Kerbal mod site is CurseForge, so all mods submitted to it falls under the bolded clause.

As you found out, stock parachutes are automatically cut loose as soon as you touch the ground, but the RealChute Parachute Systems mod rewrites things so that you have proper drag chutes, among other things. They might come in handy.

Exactly what do you mean by that? Squad has explicitly partnered with Curse for mod hosting, it doesn't get more official than that. Are you saying that you don't believe that Curse should be recognized as the new official mod hosting platform? Version 2.4 was hosted on Spaceport, and has not been uploaded elsewhere yet by the mod author. The version 3.0 RC2 (which I personally like quite a lot better than 2.4), which is linked from the first post (right at the top), was hosted on Dropbox by the author when originally posted some time ago and is still available.

It doesn't, no. The atmospheric scoops generate actual resources that are put into tanks; there's no tank for Nitrogen, so they can't collect it anyway. The Haber Process just won't run unless the refinery is currently in a nitrogen-containing atmosphere.

You need a tank that can store liquid fuel and oxidizer, of course. Since those resources both have STACK_PRIORITY_FLOW, they need to be in the same stack as the refinery, or else connected by fuel lines (running towards the refinery, I believe, since producing resources is implemented as "consuming" a negative amount of resources).

What was your periapsis before you began aerobraking? If you lower your orbit until it intercepts the ground, it may not look steep, but it's actually steep enough to seriously stress your heat shield, if not overload it to the point of failure. I find an initial periapsis of between 25 and 30 km will guarantee single-pass capture without overloading your heat shield (using default DRE settings). That way you do most of your braking in the thinner upper atmosphere. In that picture you posted, you're moving at 1800 m/s at less than 8 km altitude; that's definitely way too fast to be that low. Note that this means that suborbital flights can actually be more dangerous than returning from orbit, since by definition your periapsis won't be very high.

I believe it's the latter, the quantities are effectively unlimited.

They're the same for everyone, if you look in the WarpPlugin/PlanetResourceData file you'll see the .png grayscale maps used to generate land-based resources. I believe Fractal handcrafted them to match up to surface features (e.g. ice on Minmus is found in the flats), and prevent things like deposits underwater on Kerbin where you can't get at them.

Just in case anyone was wondering about possible conflicts, I just downloaded this from Curse, and can confirm that it works fine with 0.23.5 and RPM. The instruments get overwritten properly by the RPM instruments automatically with no adjustments.

Try this thread: http://forum.kerbalspaceprogram.com/threads/69993-Science-Lab-Module-migration-problem Relevant bit:

In the "spaceport going offline today" thread in The Daily Kerbal, they said they've backed everything up. Rowsdower seemed to be implying that mod authors could get a copy of their mod if they realized they hadn't backed it up themselves, but I'm not sure about members of the public ... could be bad if the author is MIA for whatever reason.

Was testing this out, found a variety of weirdnesses with the DRE config- a few parts missing configs, a few configs present but referencing incorrect part names, and some extra } characters that were disabling most of the wing heatshield configs. Config below that seems to function as intended: @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2_1m_Adapter]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2Fuselage_L]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2Fuselage_Short_L]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2Cockpit_Standard]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2CrewCabin]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2Fuselage_LFO]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2Fuselage_Short_LFO]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2CargoBayL]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2CargoBayS]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[scramAirIntake]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 // forward reflective = 0.3 // 30% of heat is ignored at correct angle } } @PART[IntakeRadialLong]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 // forward reflective = 0.3 // 30% of heat is ignored at correct angle } } @PART[mk2Cockpit_Inline]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2DockingPort]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2DroneCore]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[mk2_1m_Bicoupler]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 1 // underside of fuselage reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[wingConnector4]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[deltaWingX]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[deltaWing_small]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[elevon1]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[elevon2]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[elevon3]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[wingStrake]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[structuralWing1]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[structuralWing2]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[wingConnector2]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[wingConnector3]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[structuralWing3]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } } @PART[wingConnector1]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // omnidirectional reflective = 0.25 // 25% of heat is ignored at correct angle } }@PART[mk2_1m_AdapterLong]:FOR[SpaceplanePlus]:NEEDS[DeadlyReentry]{ (public domain)

Yes, causation is more the other way around- the evaporating shield mass carries away lots of heat, cooling the shield off. You get more ablation at lower altitudes because the atmosphere's thicker.

You don't seem to have the extra tech tree nodes you should, in addition to the missing arrows. Did you get asked if you wanted to use the Interstellar tech tree by TreeLoader when you started up your save after installing Interstellar?

I believe that was the whole reason the update's been delayed a bit, they decided that putting reputation/money/budget in without proper contracts was silly, so they're spending some more time to get it done right.

Looks like you're probably getting flexing at that small decoupler/docking port joint. Decouplers and docking ports have always been notoriously wobbly. You obviously know that, since you've put some struts across the joint. Try adding more struts, say from the wide bottom of that 3.75m-2.5m adapter to the top of the station module, and see if that works any better.

Ah, class C, yeah, that's probably a lot more forgiving, especially if you're not trying to be super precise. Interestingly, even within a class (I focused on class E asteroids for my collection) there's very substantial mass variance. The very first Class E the game threw at me (on a collision course with Kerbin, no less- sure gave that career save's tech progression a kick in the pants when I rushed to get to technology powerful enough to stop it) was ~800 tons, which seemed big at the time, but the biggest was ~3200 tons or so, and most were rather more than 800; that first one was actually unusually small. Those are all Class E's. The one named Apophis was the one I mentioned earlier as the first one I caught off a collision course (one of the others was also spawned on a collision course ... makes me wonder if there's a reason the Kerbals are so space-program obsessed). I should really get around to renaming the rest of those and getting more-accurate mass values one of these days. Circular equatorial orbits at intervals of 1000km, because I had plasma engines and felt like making it a challenge.

A few warnings about using multicouplers for multiple claw points (I tried the same thing)- (1) with multiple claws, when you get them all attached you'll be perpendicular to the asteroid surface, which is not necessarily oriented through the center of mass, and you won't be able to rotate around the joint to fix it like you can with a single claw, and (2) when I tried using a multicoupler-claw attachment point it seemed to be a spectacular Kraken lure. Pretty much guaranteed the bug where you start bending when you go into timewarp, until you bend too far and the ship bursts into an expanding cloud of debris. If we start talking non-stock, the plasma engines from KSPI are great for shifting hefty chunks of rock. You'd think the DT Vista engines would be awesome, but I tried that, and there's a few ... problems ... Oops. A variety of tips from my experience moving heavy asteroids (class E): Use a single claw, puller-style Set up the node you want to use, get yourself pointing in that direction, then line up with the asteroid's center of mass and dock (if you were already clawed to the asteroid, it may be worth undocking and redocking rather than trying to rotate a stupid-huge asteroid and then get it stopped again) - this one's not always necessary but can be helpful Strong RCS and plenty of monopropellant to fuel it will help keep your ship pointed in the right direction Unlock the claw's pivot while thrusting so it's like you're dangling the heavy asteroid off a rope, so it will always swing back into line - make sure you have enough RCS to keep yourself pointed in the right direction before trying this, though, or it'll still swing you around MechJeb makes long-duration burns oh so much easier to deal with, if you're into that kind of thing

Reactors are upgraded by unlocking the appropriate tech tree node. You get the upgraded tokamaks (2.5m and 3.75m fusion reactors) when you unlock the Advanced Fusion Power node with the DT Vista and 0.625/1.25m fusion reactors. The different sizes of plasma thruster differ only in mass and maximum electrical power input. The 0.625m one has a max of 3,125 MW, the 1.25m one 25,000 MW, and the 2.5m one 200,000 MW (and remember that's after efficiency losses!). Feeding a 1.25m plasma thruster 20,000 MW (20 GW) will get you exactly the same thrust and ISP as feeding a 2.5m plasma thruster 20 GW. It's really very difficult to get enough power production that you need to use the 2.5m plasma thruster without a death-ray-intensity microwave power beam. Plasma thrusters will sense how much electrical power your ship is capable of generating and adjust the throttle accordingly. 100% throttle is the plasma thruster consuming all available power on the ship. If you only have enough power generation to produce 15 kN of thrust at most, then 100% throttle will produce 15 kN of thrust. Increase your power generation and your maximum thrust will increase accordingly. As of right now, solar panels will only produce ElectricCharge, which cannot be turned into MegaJoules on the same vessel and thus cannot directly power a plasma thruster. You can use solar panels to power a microwave power transmission antenna, however, which will generate MegaJoules on the receiving ship. Remember that 1000 EC = 1 MJ; you need quite a lot of solar power flow for this to be useful. Lots of panels and low solar orbit is recommended for solar power stations.

I would like to say that the multi-adapter is super nifty. I used it as a 3.75m to 6x1.25m stack coupler to produce this monster of an orbital survey vehicle (6 targets, high and low orbit- did a full sweep of the Jool system in one mission) (if you're wondering about the crown-of-thorns, well, in testing we had some issues with the return module tipping over if the landing surface wasn't flat and smashing up the science modules, so I stuck a bunch of lander legs on top of the lander can as extendable roll-bars, which actually worked fairly well) Keep up the good work.

You need to pump a LOT of power into plasma thrusters to get good thrust. Antimatter reactors are obviously more than capable of supplying such. Upgraded 3.75m fusion reactors are another good bet; my plasma-thruster based asteroid tug uses 5 of those to max out the power usage of 4 1.25m plasma thrusters, and it can take off from Kerbin under its own power using Argon propellant in drop-tanks, even with the hefty load of LiquidFuel for orbital maneuvering and Monopropellant for holding the craft straight when the asteroid starts trying to swing you around (and the substantial mass of the reactors themselves). With anything smaller and less high-tech, the power-to-weight ratio starts dropping pretty quickly, and that's what you need for high thrust-to-weight ratio with plasma thrusters, since their thrust is directly determined by the power delivered. At maximum throttle, the argon thrusters on my tug produce 2045 kN of thrust each, but that's at a power consumption of 32.9 GW* each. Alternately, you can start spamming power transmitters and use microwave transmission to run your plasma thrusters, which takes away a lot of the TWR issues. You just have to deal with line-of-sight issues instead. *Note: the "max power" of the 1.25m plasma thrusters is 25 GW, but that's after efficiency is taken into account, so it uses even more than that, depending on the efficiency of your fuel (argon is 76%, so 25 GW / 0.76 = 32.9 GW).

All the life-support resources from TAC-LS have ALL_VESSEL flow, so they can be taken from everywhere on the ship- is that what's happening, you're seeing the amount of resources in every capsule go down? The rate at which they're being consumed should be proportional to the number of kerbals actually on board the ship, however. The TAC-LS life support information window just tells you how long the resources you currently have in stock will last with the current crew. It doesn't really take into account anything that generates more of said resources (solar panels for electricity, recyclers such as the greenhouse for other resources). What should happen is that if you're using the recycling greenhouse, the amount of resources onboard should decrease at a dramatically lower rate than the actual rate shown in the window, due to extra resources being generated by the recycler. As an example, say you have the 90% efficient recycling greenhouse and the life support window says you have 20 days of life support in stock. If you wait 10 days, the life support window should say you now have 19 days of life support in stock, because additional resources were put back in by the recycler. It's a little confusing, but if you know how efficient the recycler is it's easy enough to calculate your actual life support time remaining (if the recycler is running, multiply by 1/(1-e), where e is the efficiency of the recycler- in the example given, e would be 0.9, so you multiply by 10x).

You can make your own folder, and then put that folder into the main B9 folder. I did something similar to put my own greenhouse parts under the ThunderAerospace tag (the parts are in their own folder, inside the main ThunderAerospace folder, and are therefore read by PartCatalog as belonging to ThunderAerospace). That will keep them obviously separate in your files while still letting the autotag do the work for you, instead of having to manually edit all your parts into the desired tag (which is the other option). I'm having a few problems of my own with the Small Mods auto-generated top-level tag. The first is that it doesn't seem to properly link to the Small Mods icon by default (it just has the "unknown icon" image instead), although you can use Edit Icon to give it the correct one. The second is that MechJeb2 refuses to be sorted into the Small Mods category, despite having exactly two parts (rather less than my set maximum of 7 parts). EDIT: Adjusting the maximum number of parts in a "small mod" to 10 caused MechJeb2 to be added to the Small Mods category. Don't ask me why this worked when 7 didn't. My first question still stands. DOUBLE EDIT: Moving the SmallMods_On and SmallMods_Off .png files from Icons/Mods to Icons fixed the issue with Small Mods not finding the correct icon automatically. Fairly minor, but you might want to fix that for the next release, Necro.