Archgeek

Yes. The whole system will be a dificulty option applied either explicitly, or on starting a new save. It's also got some sub-options under that. Upshot, no existing saves will have the system activated until you tell them to.

They do, which is why the probe's main body just has the two. The next six on that plate are there to keep TWR from getting below .02, as are the 14 on the lower stages. They don't stick around though -- the only point they really make up considerable fraction of the thing's mass is the last few stages, the very last of which still pulls a solid 9km/s. Plus, their very presence, to my utter surprise, proved to only cost a few km/s for the same amount of fuel. What's more the curve (which can only be followed so closely) is roughly quadratic. The thing goes from single 700 tanks to 12 5220s per stage. And what even is meant by aspargus here? Xenon tanks drain from the outside stages in based on the count of decouplers between them and the root. Mass-optimally, you'd have a long goldfish-poop train of droptanks.

Hmm, that reply might've been a bit rambling and seemed somewhat defensive. This thread does a better job of explaining things: Significant investigation wound up concluding that best mass efficiency for stage distribution was equal stages (if all of 'em have the same Isp). It's a little more complex than that but the xenon droptank problem turns out to be a rather convenient special case. 9km/s stages were sub-optimal due to lack of resolution resulting in a lot of fudging, piling on the mass too quickly(also, I think I miscounted the engines which may've thrown things far out of whack), while the smallest possible in stock turns out sub-optimal due to part count (which was in part due to needing to stretch a stage a lot to have room for the panels for its engines). 4.5km/s seems to be working out nicely, but I'll see when I get a chance to finish it up.

Well, that answers that. Thanks!

Hehe, you'd be surprised. Decouplers make surprisingly little difference for xenon tanks, as one is lighter than a dry tank by quite a bit...you gain more from dropping a tank that you lose from having a decoupler. It turns out this craziness works out best when each droptank stage has as close to the same mass ratio as possible. This design is kinda the extremis of that -- just one little tank (dv is directly proportional to mass ratio, so I'll use that) at around 1500m/s, followed by gradually increasing tankage staying as close to the curve as possible. I'm guessing they aren't visible enough, but two engines are actually at the top under that z4k -- this thing's a puller with a few extra stageable engines to give token consideration to TWR (keep it going below .02, pretty much) That plate's got 6, and there are 14 more towards the bottom. A single engine would have an insane burn time 190.2 hours, it looks like. Even if using a lot less decouplers and engines cut the fuel needed in half, one engine would still take 95.1 hours burn time, which is a bit much. Also, in practice much of the initial stage time would be periapsis kicks around kerbin, then a transfer to Jool for a sun-slingshot, followed by a hard, long, interstellar transfer burn around the sun. Plenty of insolation everywhere but Jool, there.

Might I inquire just what that strange new "Page" button that has replaced the imgur button in the upper right does? All I can see is a horizontal black line. 'Not sure what it actually does. Is any elucidation available regarding it? I note it allows the cursor to position under the bottom-most line, but it jumps back up to attop as soon as one begins typing.

Welp, I've completed the design of the b variant -- 62 stages wouning up with a little over 1km/s extra, ~85 tonnes lighter, but for 208 more parts. KER is still being buggy about having ion engines drop away, so it's dv numbers are plenty off. The design does, however, assume false things about the fuel flow, and so probably only really has around 88km/s like the 'a' variant. As you can see, starting with the smallest tank I could resulted in a very long, noodly top section, and the stages under the plate were compact enough that I had to intentionally stretch the crap out of stage 49 so it'd have room for all the panels to power those 14 extra engines. This piece of insanity isn't worth a .craft file. I'll try again with c-variant that aims for something between 1.5 and 9 km/s/stage, and attempts to take advantage of the strange flow behaviour that actually exists.

Another weekend, another monstrosity: In spite of what KER is saying, that's actually a design 101.8km/s in 62 stages, for only 162.6 tonnes. Granted, since my pairwise staging doesn't actually work as designed because [STAGE_PRIORITY]'s decoupler-counting ways, it's probably more like 84-88km/s. Unfortunately, 648 parts is a little much. I have to disagree with the Engineer's report, though...this thing'd be super noodly in practice.

That bit of debris with the reaction wheel and mono tanks just gave me an idea for much flatter orbital construction micro tug! Less mass-efficient than a 10 unit tank, inline battery, reaction wheel and probe core, but cooler-looking and better for service bays.

Same way as the standalone, really. You just derp into your save folder and hit up the VAB or SPH folder. You'll find the game folders under (probably Program Files(x86) on windows)\steamapps\common\Kerbal Space Program.

Indeed, they tend to desperately dump heat into whatever they're attached to, and they make good passive radiators when they get really hot, dumping a good chunk of their own heat into space, but if you burn a couple into tanks that are mostly empty, the whole craft will get glowing hot in a couple of minutes.

To get the whole craft really hot, run a few nukes without any radiators. Infinite fuel can help here.

Rods from the Clods?

Okay, that might not make a whole lot of sense, so here's a trivial example with a 5 ton payload/panels/engines: payload: 5t S0 S1 wet mass payload + 5200(wet)-700(fuel)+stack decoupler) 700(wet)*6 + 700(fuel) + mini decoupler*6 + S0 mass ratio wet mass/(wet mass - .52+.07) wet mass/(wet mass - .07*7) 5.9375-.07 + .05/(wet mass - .52+.07) = 5.9175/5.4675 = 1.0823 .88 + 5.9375/(wet mass - .07*7) = 6.8175/6.3275 = 1.0774 dv ln(1.0823)*41202 = 3259m/s ln(1.0774)*41202 = 3073m/s I just noticed that the gain in structural coefficient suffered by S0 from the theft of some of its fuel comes with a loss of it enjoyed by S1...I don't suppose they balance out entirely, considering the later stage would feel an increase more accutely than a lower one.

Easy-mode solution if you've got a spare docking port on the miner: send a special radiator module on an express, non honhman transfer, lift the miner back into a low orbit when it gets there, dock 'em, then head back down and mine away. If the miner's not got the gas to get back down, send some fuel with the radiators -- you'll only need to wait to refine enough to get up to where the mission rescue package can meet up and dock.

Project Helios. I have repeatedly designed several modular payloads (Daedalus and Icarus dangerously-near solar probes, with Icarus designed for a destructive plunge intended to try for atmospheric analysis, Pioneer 1kerb capsule return system, and eventually a full 3-kerb boat anchor pod into a circular near-sun orbit), the entire XenonTempest series of modular ionic transfer vehicles, plus plans to build something smaller for those little probes. Yet, I've never really sent anything down there, except for the first test of XT Mk1 for some reason, though due to a misreading it didn't wind up that close -- 613km above the surface.

Even starting from LKO, 10k won't get you into a 610km circular orbit around Kerbol. That costs 13.7km/s. Well, on a direct trajectory anyway. Doing a Jool bi-elliptic might work out. 10k might get you an impact, though. It's just another 10 klicks down.

Sorry for resurrecting this thread, but I've encountered another wrinkle to the problem that I was actually unaware of. Thanks to the discussion here, I've actually ginned up a pretty serviceable solution: However, in practice, I have to make geometric concessions to prevent or reduce oscillation -- and so've taken to using the rockomax adapter plate 2 and some cubic octagonal struts to make one stack into seven, six staged pairwise, 1 central core, to reduce decouplers per stage, as seven would get annoying. Unfortunately, [STAGE_PRIORITY_FLOW] does not work the way I thought it did. Rather than drain the tanks in the highest-numbered stage, it drains every tank in the group with the highest number of decouplers between them and the root part: So, if I want to stage pairwise, I could either do something dumb and stack extra decouplers to force the order I want, or I could do something weird, and split a stage's fuel such that some of it is in the next stage's tanks, effectively sticking the upper stage with some of the lower stage's dry mass...except I can't do that either, as it drains every individual tank with the same decoupler number at the same rate. This means that stages with the same type of tank will empty at the same time, preventing their treatment as separate stages. The one bit of control I can get is that a stage with smaller tanks will drain before a stage with bigger tanks, such that for 700 unit xenon tanks around a core of 5200 unit tanks, every big tank will still have 4500 units in it when the outer tanks are staged, effectively turning the first .07 tonnes in each into a part of the outer stage, and dumping some of the outer stage's dry mass on the inner stage. The question is, what does this shenanigan do the optimum mass ratio? I'm guessing since this increases the inner stages' structural coefficient, that the answer is no longer "match them as closely as possible".

'You miss the part where they're also dealing with a mountain of technical debt? That's well-known for frustrating efforts of this sort.

I'm convinced that the fuel tanks are painted with a mixture containing hydrogen peroxide and C4. It's the only way to explain how angrily the xenon tanks explode, considering they should be largely pressurized bladders of noble gas.

'Pretty sure 'e means guessing how long it'll take his computer to run a 90-minute burn so as to return to the device near to burn (or stage) completion.

Watching fuel tanks drain? Normal and radial? Okay, I smell two problems in execution here. 1: Crazy long burns like this pretty much demand you use Kerbal Alarm Clock -- just set alarms to pause the game at around each staging event, leave it running for an hour or however long the stage takes to burn out, come back, stage, check/correct vector if needed, repeat until near manuever completion, where you'll want alarms more frequently. I like to do the last few minutes manually myself. 2: You're not trying for Hohnman transfer, are you? When burning extra gas to cut time, you're likely to catch your target sooner than you otherwise would. So, instead of chasing it around with a node, you aim for an early intercept, set a node that goes ripping past it, missing entirely, then set a braking node for slowing down, that actually makes the intercept happen. For bonus points, try to hit objects in the target system with your spent stages during turnaround manuvers.

Drat, so observed behaviour is in fact intended? 'Guess I'll have to redesign. Thanks for the clarification!

Sounds about right. STACK_PRIORITY_SEARCH is standard rocket flow, NO_FLOW is obvious, STAGE_PRIORITY_FLOW is for mono and xenon, and ALL_VESSEL is how mono and xenon used to work. I forget what jet fuel does these days, but I'm more interested in the intended behaviour of STAGE_PRIORITY_FLOW and whether or not the displayed behaviour is correct.

Crapper poopers! I seem to've mis-apprehended the way [STAGE_PRIORITY] fuel flow works, so my design has less dv than I thought. It turns out xenon drains from all non-empty tanks the furthest number of decouplers out from the root part that it can, regardless of defined stage order. Either I've got a bug report to make, or I'll need to redesign the silly things. Headway's being made with KER's dv calculations, so upon removing the dropped engines and replacing them with equivalent ore tanks, the numbers here should be accurate: