ArcFurnace

Don't think that's a new problem. Watch the maneuver node pointer- you'll see it moving as the burn nears completion, because you can never be exactly on target. MechJeb will try to follow the pointer, but that tends to be difficult when it's flying all over the place. The problem is amplified if you ship flexes as it turns, since that moves the "control center" and affects the node pointer as well. Also amplified when you're doing things like mid-transfer burns days out from your destination, where tiny differences make a large difference in your arrival. I dealt with it by increasing the tolerance to 0.3 m/s on the Maneuver Planner, which usually lets it complete before spazzing out too badly.

This guide covers quite a few aspects of aircraft/spaceplane design, including landing gear. Dealing with wheelbarrowing on takeoff or landing can definitely be tricky. You really want to have an absolutely level landing field and come down level for best results. Wide-stance landing gear also helps some for landing, gives you more restoring force when you touch down and helps prevent wingtip strikes.

I suspect that's the issue with combined thermal+direct conversion generators causing the "theoretical supply" to be set to an unsustainable level (issue #3 in my most recent post). Try it with only a thermal generator and see if it works better.

Several bug/issue reports from messing around with fusion-powered plasma thrusters. 1. Plasma thrusters have the same power priority as the fusion reactor's input power. Plasma thrusters will take 100% of the produced power at 100% throttle, causing the tokamak power requirements to slowly drain your power reserves. If the priority could be adjusted so plasma thrusters take 100% of the power left after the fusion reactors get their cut, it would be easier to guarantee that things would work continuously (although it can run for quite some time as it is, given the fairly slow drain of the reactors compared to the reserves). 2. Plasma thrusters don't actually seem to respect their rated max power. Image below demonstrates this bug as well as the previous issue (1.25m plasma thruster with rated max power input of 25 GW is consuming over 32 GW, and net power is negative by the total reactor power input requirements). Disregard that. Apparently the figure listed in the tooltip is the maximum power after efficiency is taken into account, so LiquidFuel with an efficiency of 72% has a maximum power consumption of 25/0.72 = 34.7 GW. Was this documented anywhere? It should be. Image still nicely demonstrates issue #1. 3. Thermal generators were altered so they can consume ChargedParticles as if they were ThermalPower. This is nice if you only attach a thermal generator, preventing you from wasting 20% of your D-T fusion reactor's output. However, if you attach both types of generator, the thermal generator will still consume ChargedParticles simulataneously with the direct conversion generator. This effectively causes the reactor's ChargedParticle production to be counted twice in the maximum available power figures. You can, in fact, get that much power, but only for as long as your stockpile of ChargedParticles lasts, which is not very long at all. It also confuses the electrical engines- plasma thrusters at 100% will attempt to draw the maximum available power; since this is unsustainable due to the double-counting, this will cause the thrusters to rapidly drain your power reserves at 100% throttle.

40 GW is indeed a good bit of beamed power. It looks like you have a microwave-electrical reciever on the top of your ship, which will capture the beamed power and turn it into Megajoules. Given that you don't seem to have anything using Megajoules on that ship there, it's pretty much useless during launch, although it might be useful for electrical power once you get it into space. You also have a microwave-thermal reciever on top of that thermal rocket nozzle. That's doing it right. However, where exactly is your geosynchronous power station? Orientation matters for recievers, and the microwave-thermal recievers want their beamed power to be side-on to the reciever, perpendicular to the stack. The microwave-electrical reciever may also be stealing beamed power that ought to be going to the microwave-thermal reciever, due to Fractal's implementation of conservation of energy. Try closing up that microwave-electrical reciever, and adding a few beamed power relays "off to the side" of the launchpad, either on the ground or in geosynchronous orbit. See if that works any better. From what I remember of messing around with the microwave-thermal recievers, ground stations work well right after launch but quickly drop off as you get higher and the angle of incidence increases, so geosynchronous relays set up to be near the horizon when at KSC might be best. If you have the station above KSC and relay(s) off to one side, you should get good power throughout your gravity turn ... I think. @ctbram: Okay, that's just weird. Don't think I've had that happen before. I've had a few unexpected reactor shutdowns, but those were generally while I had the vessel focused, and there was usually a reason once you investigated (weird waste heat fluctuations at high timewarp, or running out of tritium in the reactor because all the bred tritium went into external containers ...). I really can't think of anything besides a bug that would be causing your problems. Uhh ... try deleting and reinstalling KSPI? I have no idea if that would help, but it might. Make sure you get it reinstalled before you load up the game so it doesn't delete your ships for having invalid parts. EDIT: Just loaded the game and switched to my Asteroid Tug with the 3.75m fusion reactor, and it was offline ... well well well. Still not sure what could be causing this.

Often it's easier to get yourself to be slowly gaining speed or slowly losing speed, rather than maintaining a constant speed (which would require perfect balance). What I usually do on final approach is to use more-powerful burns to get down to the desired speed (5-10 m/s), then adjust the throttle until I'm very slowly losing downward speed (i.e. the acceleration from the rocket is just barely more powerful than the acceleration from gravity). Once my speed starts to get very low (say 2 m/s) I nudge the throttle downwards a tiny bit so that I'm now slowly gaining speed. You can keep slowly adjusting your descent speed up and down like this until you touch down; anything below 5 m/s is usually fine, although you might bounce a little. Be ready to use reaction-wheel torque to counter tipping if you're landing on a non-flat surface. This is for the last few hundred meters of your descent; you can get away with substantially faster descent speeds until then so long as your acceleration is decent, so that you can brake quickly once you get near the desired height.

There's a typo in the adjustments to the RCS. It's listed as setting "thrustPower = 2"; it should be "thrusterPower = 2".

Are the UP20/UP30 decouplers meant to be used with RSS shields and parts? They don't seem to fit any of the heatshields provided with DREC (or, indeed, stock parts in general). I tend to just remove them to reduce clutter, since I use stock-scale Kerbin.

Trick I picked up from watching one of Scott Manley's videos: use a girder segment as part of your rocket stack and put the radial sensors on that. Then they'll be far in enough to be protected by the 1.25m heatshield. Example: That one doesn't have magnetometers because it was the reentry module for a Mun/Minmus lander after I'd already gotten the magnetosphere scans from those, but they work just the same.

Ohhhh, that's because the resource isn't available where you have it landed. Some of the resources are only found in certain places. Lithium is only found in ocean water by default and it's pretty dilute, the Water Extractor needs to be either splashed down in an ocean or near a deposit of ice it can bake out of the soil on some planets without liquid water (don't think there's land-bound water on Kerbin right now, although it might be reasonable for there to be some). Alumina is found in the regolith of certain planets/moons, ammonia you can extract from the environment is only in one or a few places iirc, one of them being the oceans of Laythe. Land that refinery on the Mun and you should get better results with the Alumina Miner, for example. EDIT: Full list from checking the resource data files. Ground-extractable water is found on Duna (more nearer the ice caps), Minmus (mostly in the icy flats), the Mun (a few specific craters near the poles that are shaded enough to retain ice), and Vall. Oceans on Kerbin, Eve, and Laythe all also contain water. Ammonia is only found in the oceans of Laythe (and also in the atmosphere of Jool, but you need the atmospheric scoops for that, not a refinery) Lithium is found only in the oceans of Kerbin, Eve, and Laythe in very low concentration. Alumina is found on Ike, the Mun, and Tylo (more concentrated in some spots, but pretty much everywhere has a decent amount). Fractal, is Vall's groundwater resource map supposed to be a 14x13 pixel white square as opposed to the 160x120 grayscale bitmaps used for other resources?

Weird. I assume you checked, and there was tritium in the reactors? DT Vista engines use tritium too, so they have some storage, it could have ended up there. If there is, I'm really not sure what's causing it ... the only things that can cause fusion reactor shutdown are overheat, fuel loss, or power loss, and they supply more than enough power to keep themselves running so it really ought to be one of the first two ... As to your radiator design, you can usually get away with that sort of thing unless you need absurdly long-duration burns; they'll have plenty of time to cool off while idling, and heat radiators can store a huge amount of waste heat as they heat up. In other news, my current career mode save has spawned a Class E asteroid on a collision course with Kerbin. Impact in 15 days. I'm already a good way through the tech tree, so I think I have a chance of stopping it ... wish me luck.

Do you have any extra containers that can contain Tritium? One thing I noticed is that tritium produced by breeding tends to go into containers, rather than into the reactor's own storage. This caused one of my reactors to shutdown during a long coasting period a while ago when the reactor ran out of tritium (even though there was tritium stored in the external tanks). TAC Fuel Balancer can fix this by telling it to "transfer in" to the reactor. I also often see the WasteHeat fluctuating wildly at high timewarp, you might have hit an excessive amount of WasteHeat and had a shutdown (with mine that hasn't been a problem, it doesn't seem to bounce above 75% full or so). I generally try to include a 62.5cm/1.25m fission reactor as a backup anyway to ensure I can always restart a fusion reactor if shenanigans occur.

Yeah, Fractal hasn't worked with the radiation system too much yet I think, some of the levels are really high (try finding the highest dose-rate location in Minmus orbit, it's well over 10 Sv/hr iirc, which would be insanely lethal if it was actually implemented). Right now it's just a placeholder for if/when he wants to implement it properly in the future. He did something similar with the waste heat system, implementing it as a visible-but-nonfunctional stat to get people used to it before implementing actual negative consequences for excessive waste heat, but so far nothing much has happened with radiation.

I've been messing around with integrating TAC Life Support with KSPI's ISRU options. The ModuleManager config in the spoiler below adds a module to the TAC Water Filters that lets you process KSPI LqdWater into drinkable Water, and a module to the Carbon Extractors that lets you transfer Oxidizer into your life-support Oxygen tanks (as well as one that lets you transfer it back out, just in case you need that for some reason...). Conversion numbers are calculated to conserve mass during the conversion process. MODULE { name = TacGenericConverter converterName = ISRU Water Filter // Number of units to convert per day (24 hours) conversionRate = 2160 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = LqdWater, 1.8, ElectricCharge, 20 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Water, 1, false } } @PART[TacWaterPurifierLarge] { MODULE { name = TacGenericConverter converterName = ISRU Water Filter // Number of units to convert per day (24 hours) conversionRate = 2880 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = LqdWater, 1.8, ElectricCharge, 20 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Water, 1, false } } @PART[TacCarbonExtractor] { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer In // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxidizer, 1 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxygen, 11.65, false } MODULE { name = TacGenericConverter converterName = Transfer Oxidizer Out // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxygen, 11.65 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxidizer, 1, false } } @PART[TacCarbonExtractorLarge] { MODULE { name = TacGenericConverter converterName = Transfer Oxidizer In // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxidizer, 1 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxygen, 11.65, false } MODULE { name = TacGenericConverter converterName = Transfer Oxidizer Out // Number of units to convert per day (24 hours) conversionRate = 86400 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = Oxygen, 11.65 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxidizer, 1, false } }@PART[TacWaterPurifier]{ I want to do a greenhouse-style food producer as well, but that one really needs a new part, as well as more thought into what inputs it should use and how fast it should supply food (it's not like with water, where the water is already there and you're just gathering it- you have to actually grow the food).

Where are you getting the electric charge from? 10 MW is 10 Megajoules/second, so you'll need 10,000 ElectricCharge/second to power that. Offhand, I know you can convert ElectricCharge to Megajoules by transmitting it with the microwave power transmission (generally used with low-Kerbol-orbit solar power satellites, where the solar panels are capable of producing thousands of ElectricCharge per second), but I don't think there's any way to convert ElectricCharge to Megajoules on the same vehicle in default KSPI. You said you found a way- how are you doing it? Anything that produces Megajoules will also produce as much ElectricCharge as neccessary (the opposite of what you want).

Alternately, you can just edit the .cfg files directly in Notepad or other text editors. Still need to actually understand what you're doing.

The CO2/WasteWater converters work at 90% efficiency, and their output can be run back through the converter once it's used again. It takes a little bit of math to calculate the total (1 + [sum from n=1 to infinity](0.9n) ), but it winds up being a simple 10x multiplier on how long your Oxygen/Water supplies will last. I believe it only converts as much as it needs to in order to fill up your Oxygen/Water tanks, always at the same efficiency, so having fewer Kerbals than the converter can handle doesn't matter. If you use the 2.5m stack supply containers and converters, 3 Food Containers, 1 Life Support Container, and a CO2 Converter/Water Purifier will provide 6400 Kerbal-days of life support at a mass of 4.7 tons. Additional sets of 3 Food/1 Life Support 2.5m containers will add 6400 Kerbal-days per set at a mass of just over 4 tons each. Each converter can handle 8 Kerbals, so if you have more than 8 you'll need extra converters, at a mass of 0.65 tons per 2.5m converter pair. You can also use the 1.25m containers and converters if you can't fit 2.5m components into your ship, although it's not quite as mass-efficient for the same duration. The 1.25m components will give you 800 Kerbal-days of life support for 1.26 tons of mass in the basic 3 Food/1 Life Support/Converters stack. Extra stacks of 3Food/1LS are 0.71 tons each, extra converter pairs are 0.55 tons each. I have a ship that uses the 2.5m basic stack for long-duration life support (I wanted to put up an ultra-high-endurance drive unit to push orbital science modules, I had a bad experience with Jeb running out of oxygen on the return from Jool earlier in my career mode); it's currently at 5342/6400 Food and 534/640 Oxygen/Water. It's never supported a load of more than one Kerbal at a time.

For KSPI/TACLS integration, there's two ways you could do it. One is to alter KSPI to use TACLS "Water" instead of its default "LqdWater"; Eadrom made a ModuleManager config to do that, although reading the thread it seems like it might not be working properly at the moment. That lets you harvest TACLS Water from the places defined as having water in KSPI (mostly oceans, and some planets/moons with ice deposits) and use the TACLS Water Splitter to produce Oxygen. The other option is to add converters, either as new parts or as additions to the TACLS recyclers. You would need one to convert LqdWater into Water (almost seems reasonable to me, if you assume the KSPI LqdWater is "industrial-grade" water not necessarily safe for drinking without further purification - just add another module to the Water Filter), and a second converter to turn Oxidiser into (life-support) Oxygen (perhaps add this to the Carbon Extractor, it already deals with producing life-support oxygen). Every refinery module in KSPI that can extract LqdWater also has the ability to electrolyse it into LiquidFuel and Oxidiser, so that would let you get Oxygen from LqdWater, similarly to the TACLS Water Splitter. I actually like this second method better, as you only have to add two converter modules instead of redoing KSPI's resource definitions. I might have to try making something myself ... Of course, you still need to deal with food. Neither of these options help you produce food without further support.

Yeah, the only difference between different sizes of plasma thruster is the maximum electrical power they can accept (and thus the maximum thrust they can produce), and their mass. For the thermal rockets, I believe there's some special code that means they work best if attached to the appropriate size of reactor; if you try to attach, say, a 1.25m thermal rocket to the 3.75m reactor because it weighs less than the 3.75m nozzle, you won't get nearly as much thrust as you would if you used the heavier 3.75m nozzle (because the bigger one has more heat exchanger area to handle the higher throughput, or whatever). That was added in because Fractal wanted to make sure there was actually a reason to use the larger, heavier nozzles.

Man, how'd I miss that? Props to Der_Failer for the .cfg, and thanks for the catch. EDIT: Just installed it and checked all the node sizes. It fixes everything except for the ISRU Refinery. That one doesn't have a top node anyway, so you can't stack giant heavy things on top of it.

I love this mod, Fractal. As a token of my appreciation, you get ... bug reports / suggestions! 1. The tooltip for the ATILLA thrusters in the VAB/SPH displays the same kN/MW value for their thrust as the plasma thrusters. It seems to be only the tooltip that is incorrect, they produce and display the correct amount of thrust in flight. The displayed ISP value is correct. 2. Quite a few parts need their nodes resized to take full advantage of the 0.23.5 joint improvements. List in spoiler. Computer Core needs size 3 nodes (is size 2) 62.5cm ATILLA needs size 0 nodes (is size 1) (this is actually a reduction, may be undesirable given the high thrust of this engine for its size) 62.5cm Plasma Thruster needs size 0 nodes (is size 1) (this is actually a reduction, may be undesirable given the high thrust of this engine for its size) 2.5m Plasma Thruster needs size 2 nodes (is size 1) 62.5cm/1.25m/3.75m Thermal Rocket Nozzles need size 0/1/3 nodes (are size 2) 2.5m Thermal Turbojet needs size 2 nodes (is size 1) DT Vista Inertial Fusion Engine needs size 3 nodes (is size 1) 3.5m Antimatter Containment Device needs size 3 nodes (is size 2, should also be renamed 3.75m Antimatter Containment Device for consistency with other parts) 2.5m/3.75m Pure Liquid Fuel Tanks need size 2/3 nodes (are size 1) 2.5m Atmospheric Scoop needs size 2 nodes (is size 1) Antimatter Collector needs size 2 nodes (is size 0) 1.25m/3.75m Antimatter Reactors need size 1/3 nodes (are size 2) 62.5cm/2.5m Inline Radiators need size 0/2 nodes (are size 1) 62.5cm/2.5m/3.75m Electric Generators need size 0/2/3 nodes (are size 1) Antimatter Initiated Reactor needs size 3 nodes (is size 2) 3.75m Fusion Reactor needs size 3 nodes (is size 2) 3.75m "Aegletes 2" Fission Reactor needs size 3 nodes (is size 2) 62.5cm "SAFE-1500" Fission Reactor needs size 0 nodes (is size 1) 3.75m "Akula" Fission Reactor needs size 3 nodes (is size 2) 62.5cm GEKKO Fusion Reactor needs size 0 nodes (is size 1) 2.5m/3.75m Alcubierre Drives need size 2/3 nodes (are size 1) 2.5m Inline Refinery needs size 2 nodes (is size 1) 3.75m Inline Refinery needs size 3 nodes (is size 2) MTER-M/MTER-L Microwave Thermal Recievers needs size 2/3 nodes (are size 1) ISRU Refinery needs a size 3 node on the bottom (is size 2, side node already looks appropriate for the size of the attachment point on the model at size 1) Science Laboratory needs size 2 nodes (is size 1) 3. Antimatter Collectors attached by docking ports don't seem to correctly collect antimatter while the ship is not in focus (they work just fine while it is). Design is Collectors -> Docking Port pair (using Sr. Clamp-O-Trons, if it matters) -> rest of ship, including antimatter tanks. I think this one may have been reported already.

Yeah, for fuel reprocessing you need someone to store the 20% DepletedFuel output of the process (namely one of the radial fission fuel canisters). Looks like that's what you're missing.