danfarnsy

If you're still wondering about this, here's an example: https://imgur.com/6BkfJ8L I used Throttle Controlled Avionics to keep the thrust balanced.

I tried to change the config files for the Frisbee, so that it generates full heat (360 MW) at all lengths and adds increasing amounts of radiator capacity, instead of reducing heat output with increased length. I didn't do very well with adding SystemHeatRadiator to the B9PS subtypes (similar to how Heat Control radiators are patched by System Heat). B9PS gave me a lot of errors upon game load. Is there a problem with adding SystemHeatRadiator to a part that already has SystemHeatEngine? Or am I just doing something dumb? I was trying to do this because I'd like to have the radiator mass curve adjust more smoothly with throttle cap. A Frisbee capped at 90% throttle should only put out 324 MW of heat, while a 102m Frisbee should be able to reject 336 MW on its own, only needing extra radiators for the last 24 MW up to full throttle at 360 MW. Instead, the 102m Frisbee still requires 21.6 MW of heat rejection from extra radiators at 90% throttle. This gets weird, where a 20m engine with thrust capped at 10% throttle still requires about 10 tons of extra radiator mass, about 50 tons total. A 20m engine capped at 30% throttle ends up being almost 70 tons with enough radiators. 55m engine at 50% throttle cap with radiators weighs almost as much as 110m engine. Example for what I tried with one of the subtypes:

A few pics of a station. Dual axis arrays are handled by BG servo on an orbit-long timer.

In the shadow of Laythe, this turned out great:

Yes. The CryoTanks included in this mod have a patch for the stock ore converters to make methane and hydrogen.

Yes, that worked out. A few lessons learned for He3 scooping: Hydrolox boosters (Etna or Fuji) have much better thrust to weight, require no radiators, and have infinite fuel below 188 km. You only need maybe 80-150 m/s to circularize at 350 km after leaving atmosphere, so you can keep your wet weight down. Fusion aerospike eats a lot of He3 on the way down and up. Mk3 doesn't properly handle largest containers. Maybe you can shield it with fairing, but using the Mk4 mod makes it easy. The trip from low Jool orbit takes a while, so if you don't want to make lots of trips, a big plane is probably worth it (5x-ish the payload, 3x the weight, and 1x the flight time). Drag at target altitude (below 106 km) is no joke, especially if your speed drops near Mach 1 (900 m/s). Fusion aerospike or "Project Eeloo" engine on closed-cycle can do the job if you get leveled out and climb slowly, but hydrolox did much better. This drag is also why I didn't get any trips to work with deployable heat shield. My Mk4 scoop powered by an Etna had 30 m/s^2 acceleration, and drag peaked at about 27 m/s^2 even with a low angle of attack. Stick the pilot in a pod in the cargo bay. You don't have to put harvester scoop on the front, but you only need one. Front is a great place for the scoop without trying to use the Mk3 or Mk4 cockpits. This was fun.

Stock Visual Enhancements, Scatterer, and TUFX with this profile. I was going for less cinematic and more of the crisp high-brightness photos you see from NASA EVAs.

You quoted me as well when you said this. I wasn't looking for a change to the mod; I was looking to see if somebody had examples I could follow because I haven't figured it out yet.

Big caps and a couple of MX-1s can power a Cyclotron VASIMR ... for a little while I kind of like how the radiators match Sarnus

New Garnet MX-1 has a very high power to weight ratio compared to 2.5m and 3.75m reactors, dry mass even lighter than MX-0. Models look great.

Like I said Just go ahead and play it. All the space resources stuff is extra.

They can be launched, but some of them get very expensive. A filled 3.75m round container of He-3 is almost 2 million space bucks. There are harvester parts (exospheric and atmospheric) that allow you to collect some of the fuels, as well as telescopes and detectors to help you find where they are. Space Dust has a nice visualization of it in map view. There's a bit of a resource refining chain for fission fuels, I think some of it dependent on what other mods you have installed. Getting fission fuels from ISRU is not dependent on Space Dust or atmospheric resources. Also, the best sources of He-3, like the Mun and, I think, parts of Dres?, are not Space Dust resources.

The patch for MKS also patches for Ground Construction (which is now Global Construction) and will add a material kits requirement if you have that installed. The total mass to orbit is similar to that without MKS or GC, though, since the patch lowers undeployed mass by 60%. edit: That is to say, if you didn't have the material kits requirement, that centrifuge would weigh 2.5x on the launch pad. So it would still be too hard.

Anybody have a working He-3 scoop example for Jool? 110 km altitude is tough to get. Either my scoop (the only part exposed out of the heat shield) explodes, or I slow down so much I can't get the momentum back again (even with the fusion aerospike), and keeping control authority is hard. I'm wondering if, once loaded with scooped fuel, it's too heavy? Earlier version: Latest version: Edit to add view from front, scoop protruding through heat shield:

Did you know ablator can be refurbished with the Vulcan refinery? I've made a massive refinery at 2,000 km Kerbin orbit complete with pitifully slow antimatter collection. My idea was going to be shipping ore and uraninite (USI mods) and helium-3 there. I've used it a lot less than I planned. Reusability with the lower and middle techs has felt odd since I've made ships obsolete after one or two missions. I'll still use them, though. They're fun! Dirac is expensive, for sure. In "bang for buck" it doesn't hold up. But I have a design for a small passenger ship, with USI life support, at 27 tons (could be made lighter) with 30k dV, which is enough for short-duration transfers between planets. Small weight, small profile for launching into space in the first place. That's not bad. So I'm not disagreeing about where Fresnel wins. I'm just saying Dirac has a different place than competing with the Fresnel.

Welcome to the forums! Looks like you put a good bit of work into compiling this. A few thoughts: The Casaba's dry mass is misleading, because it has ablator pre-loaded. Its actual dry mass is 15 tons, once you burn up the 17 tons of ablator. Since it also has less heat output than the Verne, you can save a bit of radiator mass, too. Dirac allows you to make a lighter craft and a smaller profile. Asimov is indeed pretty awesome with afterburning. No afterburning allows a craft with much smaller power requirements (since you don't have to cool cryotanks), but I haven't used it that way.

From the maneuver readout in KER, there's a section with "burn time" and "time to node burn," which gives the start time precisely. I've got a screen shot here (in which you can also see that MechJeb and stock readouts are lost):

Hah, of course it's not intended. But a workaround lets you work around it in case, you know, you want an ugly solution that exists instead of a nice solution that doesn't (yet). Nertea's modding schedule seems, uh, retired. Emeritus? Modder Emeritus. In flight, you can add a new stage number and move your main engine to it, then activate the engine by action group, so this KER fix can work okay. I wasn't saying "you're out of luck if your engine is sharing a stage with a lander," but just "make sure it isn't sharing a stage so you get accurate burn times."

FWIW, Kerbal Engineer still calculates and displays this correctly, so long as you don't have other inactive engines on the same stage number (like you might with an attached lander, etc.). It's a workaround, at least.

@NerteaReluctantly, I think you should go with my patch. I know I'm coming in like a wrecking ball after ProgorMatic did a lot of work. I wish I'd seen his earlier posts. I fully agree with this: I've only updated the existing patch to add new parts, kept functions separate, consistently with what they were before, and still do not touch dry masses. I use MKS, but I prefer to have this patch merely enable SSPXR to play with it in a reasonable way, rather than have the presence of MKS override the character of SSPXR parts. There is also already an MKS patch which modifies extensible/inflatables to use material kits, still leaving total deployment mass unchanged. Altogether, the lighter footprint of the old patch is preferable. It's true that the balance for the old patch isn't self-consistent, and I haven't fixed that balance. I'm open to a balance pass and changing the performance of individual parts, but without changing dry masses, crew capacities, or roles of the parts . Again, @ProgorMatic, I'm sorry for not having this conversation more than two weeks ago.

Supposed to be 240 kN

Whoa, okay, so now I have reviewed @ProgorMatic's patch. This is a huge departure and overhaul from what was previously here, adjusting part masses to simple integer tons, adding recyclers to habs, flattening habs categories into the same 1-ton, 2-ton hab, and 4-ton options across the variety. I'm not saying that's wrong, but it is aggressive in how it touches everything. It will definitely change ships in flight that are using the previously existing patch, which I left untouched, only adjusting the new parts to be similar to the old parts. I think we ought to get feedback from other users as to what they want. Do you want a patch that wholly brings SSPXR up to the way MKS habs operate? Or do you want an extension of the previous patch that leaves the old things in place and only brings new parts in line with them? I'd prefer my option, but I'm just a creature of habit. ProgorMatic's patch is definitely streamlined and easy for planning missions. There are aspects of it I like. Overall, I'm uncomfortable with it. Sorry to change my answer to you so quickly, but I didn't realize you were essentially providing an entirely new patch instead of a simple update to accommodate the new parts. But I'm just one voice in the crowd. Can others please reply and say what you'd prefer? Maybe test them both out? Edit: Also just want to add an apology to ProgorMatic for not seeing that you'd posted a week before I did that you were looking at adding a USILS patch. Whatever concerns I have with it, it would have been more productive to discuss them back when you were very clear about how you were planning to overhaul things.

@ProgorMatic I didn't realize you were working on a patch. It seems like you're putting more thought into it than I did, so I'll defer to your patch. (edit, see reply further down the thread) However, I think you should still add something for Tholos (copy and modify my entry, if you like), since it's sensible that it adds some habitation multiplier like any cupola module. A ship with a dome is easier to live in than one without, right? I haven't reviewed your patch (edit, now have reviewed, see further in the thread), but one thing I tried to keep in mind is that the 5m parts may have significantly more volume than their 3.75m counterparts, often 4x as much, but rarely are they more than about 50% more mass. So, my guideline was to keep in mind relative performance per mass and crew capacity, and give a slight edge to the 5m part. But then I just made up a number that sounded okay that fit those boundaries. If you're already keeping performance per mass in mind, that's great, and I have nothing more to add. As for the PAS-G 'G4RD3N', @Arrowmaster it is three times heavier than the similar part, USILS_Greenhouse_MiniCupola, from USILS and about double the output. So it is less overpowered than what USI-LS includes to boot. Like I said, the numbers for most things were already inconsistent, so I was mostly looking at existing similar things and going from there. Abandon consistency, all ye who enter here. Edit: Crap, no, I did miss a decimal place! I just updated my pull request, if you want to keep playing with it. That cupola is now more sensible.

I know you were addressing this to @JadeOfMaar for what he was doing for TACLS, but I realized my intent wasn't clear either. I've made a pull request now.

In the CTT patch for WOLF, there's a typo where @PART[WOLF_Transporter]:NEEDS[CommunityTechTree] { @TechRequired = advlogistics } should be advLogistics, as it's case sensitive. I've been losing my mind trying to figure out why the transporter computer won't show up in my game, finally found it.