Archgeek

Oh heck, you're quite right. I just figured some crazed identity was being used to make tangent a shortcut of some sort, did the math with the given numbers in my head and figured it seemed about right (.3% is close enough to fool my estimation circuits, that for sure). At least I was right about the 85°, in spite of it not mattering really.

Nope, the idea is that we want to see the whole hemisphere at once with our little 10° field o' view by varying our semi-major axis - or the length of that centreline. We want that right angle right where it is, so we can use trig. Also, the other angle will always be 85°, because triangles gotta add up to 180. Don't rely on the graphic too much -- that half FoV angle's well over 5° ('looks around 12 to me), and the lines are very not to scale. Also, you'll find the degree of penetration is amusingly proportional to the thickness of lines, as the line o' sight is kind of centred in the line describing the planet surface, instead of attop it.

Shouldn't it measure centripetal force, then?

Hehe, sort of. More like 3.6 gigs or so, mostly due to the old AGP aperture (graphics card protocol from before PCIe) and some other IO stuff windows liked to map to high RAM. Though the limit's more for a 32b OS -- a 32b application on a 64b OS can gleefully use all 4 gigs, as the MMIO stuff is way the heck up on $FFFFFFFFFFFFFFFF and down a bit, instead of $FFFFFFFF down to nearly $8FFFFFFF. Unless of course some reflection of the limitation has been written into the application itself for some reason instead of just letting the OS handle memory relocation like usual. Not that any of that matters hugely for me, because while I may be quietly running the game on exactly 4 gigs, my win7 box is indeed 64b -- the mobo's just from nearly a decade ago and only supports 2 gig ram sticks, and 2 of the 4 slots do not work due to suspected cracked traces from a startling amount of flex the board underwent on its first mounting when the RAM sticks were pushed in. In defense of not wanting to fire up steam for games, though, I will note that sometimes the steam webhelper process will get a pretty nasty memory leak, and it likes to run two of itself for some reason, so I've usually got steam not hanging out in the tray. Not that that matters much for KSP, which I keep multiple folders for so as to have clean and modded versions running around.

*Quietly runs the game on a win7 box with exactly 4 gigs* Admittedly, I do have to close browsers and/or restart a rogue servicehost (300+ megs, really?) to stop my box going swap-crazy on me.

Isn't that usually a tiny little RCS tug, especially if there are RCS ports on the modules being assembled?

Things like the tilt-wing concept are entirely doable (Hazardish's needs moar engines and fuel, though), and neat, but inherently wasteful if you've got wings, a runway, and don't need a high-precision landing. Why hurl dv straight at the ground when you could let your wings do the work while you pick up the first bit of your orbital velocity on your nice expensive runway? You didn't leave it at level 1 as a rover training ground, did you?

Oooh, is that written in LabView? I've dealt with LabView in college and some...thing about how that interface is structured just kinda screeches LabView, at a frequency that's kinda hurting my mind's ear.

...Can you imagine the complete madness of trying to operate the VAB on a touchscreen? Various gestures like pinching and turning would help, a lot, but I'd be driven to insanity trying to use such a thing. The VAB already controls best on a 3d mouse with a keyboard, and most of us already make do with just a normal mouse and keyboard. Trying to do precision placement and rotation on a touchscreen sounds like a pretty doomed endeavour.

Nah, I'm sure that one intends to disect it, isolate the mechanism, and try and stabilize to capitalize on the effect. Krakendrives are big research.

That reads like an ad underwritten by Big Cetacean.

Perhaps they were brunk. or drored.

3.12 gigs in the main steam install, and 54.4 gigs in the swarm of (pre)release/gameplay backups I've been collecting since .235 So a comparatively reasonable 57.52 gigs all told. Probably because most of those folders are either unmodded or have some subset of HotRockets, KER, the old Enhanced Navball, and KAC. One day they'll probably start having KAS and KCT, but with only 4 gigs of system RAM to work with, that's not yet. 'Keeps my disk consumption down at least.

Oh, indeed. Those little tanks are just great -- beautiful droptanks for LV-N systems designed to use droptanks, amusing fuel density, and drained of fuel, the lightest structural part per unit length that isn't the cubic octag. Great for the panel-mounting spine on ion ships or solar arrays on stations, with a nicer look than girders or I-beams, too.

'Just me using variables again. I meant the stock FL-800, 400, 200, and co. 1.25m fuel tanks. Edit: well, well, I'd forgotten there was a 'T' in those. I meant the stock FL-T(8|4|2|1(00)) tanks. ----------------------------------------------------------------------------------------------------------------- Yup, hence the tomfoolery with attaching Oscar-B stacks around your first FL-2/4/8(00) or so. Also of interest, research into insane delta-v shenanigans in stock with the ion engine led to math that indicated that optimal staging for a given amount of fuel (assuming constant mass ratio in the tankage) is found when each stage brings the same delta-v to the party, up to the point where the decouplers become too much (for xenon this doesn't even come up, due to the heavy tanks, but for the Oscar-B, things could be different and rocket tanks are about the same, with the tiny decoupler weighing in at less than half a single empty tank). So depending on how that shakes out, your stages could go 1 tank, 1 again, 2, 3, 3 again, 4, 5, 6, 8, 10, 13, 16... until you wind up with enough fuel that you may as well use a bigger tank instead of several long Oscar-B stacks (20 Oscar-Bs is exactly as much fuel as the FL-T800, the largest 1.25m tank). (If decoupler mass is too close to tank dry mass, you'd just have more tanks in the top stage and on down.) The mass ratio gets worse at this point, so that point's slightly higher than one would think. Of course, that's if you're not switching tankage earlier to reduce noodlage or for part count. You'd technically still be better off dv-wise to stick with the tiny tanks all the way, but no one's going to do that, for obvious practical reasons. Edit mk2: Well, nevermind that then -- it turns out every rocket tank has the same mass ratio of 9, even the toroidal one. The tiny tanks just get you better resolution in trying match stage dv, plus the smaller decoupler if you're matching node sizes. The main thing to abuse is that it lets you put side stacks of tiny droptanks around a 1.25m upper core, increasing fuel density per unit ship length.

I've also never used ISRU. I've got my ISRU test rig from 1.0 launch day still en route to minmus, having intended to join in on the community's attempts to figure out how it worked, but things got in the way and I never actually got it where it was going.

Those jetpacks should work great on the Mun. Heck, they just barely work even on Duna. Is he carrying a KAS wrench or something?

HEHE, yeah, with infinite fuel alone you can get pretty fast: This thing from my old 1.1 thermal testing series burned for 40+ minutes, canceling solar orbit twice (there was a major slowdown bug involving a dreadstorm of log spam when you were on a solar escape trajectory, so I turned it around and let it just cancel its orbit again).

TL;DR: upper stages -- abuse Oscar-B tanks for droptankage, around an FL-N core. For engines, abuse Terriers, Ants if you can handle the lower TWR. Toss a Poodle in if you're really heavy, to take advantage of that best-non-nuclear-in-game Isp, but as mass goes up be prepared to augment it with sparks, terriers, more poodles, as needed. If you've got the tech, Rhino works great when you're heavy enough for a couple of poodles. For complete insanity, abuse ants and oscar-Bs, pushed by Terriers and FL-Ns coated in oscar-B droptanks, all pushed by a poodle with a short rockmax tank stack coated in FL-N droptanks coated in Oscar-B subtanks, pushed by a Rhino using a kerbodyne tank stack coated in more FL-N droptanks (but sans the oscar-B's at this point, as the ratio of decoupler mass tankage ratio improvment from staging gets sub-optimal here, also part count). lower stages -- depending on tech, a skipper and a couple of thuds make a poor kerb's mainsail, and a couple of thuds on a bare 2.5m tank make for a poor kerb's skipper. And of course, SRB's make any staged lifter cheaper and more fun. The best trick to maximize dv for this kinda probe, though, is stage-lock (alt+L) -- to prevent km/s being lost to the void due to a rogue keystroke.

Alt+L sounds like a good friend for you. The key-combo toggles the "stage-lock" state, making craft ignore the spacebar and turning the staging light pink until unlocked again. I use this constantly to prevent disasters.

Did...did they fix embeded imgur albums?! Is that what those 502 errors were about?

I like how the one on the right kinda looks like a squid.

Yup, even those famously re-usable SRBs got utterly worked over by the salty ocean water they splashed down in. The things even managed to suffer enough electrolytic corrosion that some design shenanigans took place to reduce it.

Nah, theory might be better in this case. My experiments (that at all succeeded) have been fairly limited, one or two full small ore tanks or less payload, that 1291 number was a single kickback under a hammer under a fairing with mini decoupler, two small ore tanks, a hex and a z-100 on top. 'Biggest problem was trying to fly the crazy things -- such a rocket no longer turns for love or money once the booster's anywhere near burnout -- most likely my ascent profile is insanely sub-optimal. A PAM's an SRB upper stage, intended for vacuum use, usually boosting a payload up to an intended orbit or out of the SOI, like the STAR-48 motor used for New Horizons. For some reason they keep packing a bit under 1km/s delta-v with arbitrary dense payloads I've selected, and are of course very cheap (seperatron PAM's arguably the cheapest way to circularize small probes if the resulting orbital parameters don't matter much).

I did a few tests with SRBs and hyper-dense payloads (small, full or mostly full ore cans) in 1.25m fairings. 'Found that the lame ol' Thumper is actually very convenient about its mass/drag profile during an ascent from an initial tilt on a launch clamp, and can just about make it out of the atmosphere in a normal gravity turn. The Kickback is of course more capable, but a lot less stable, needing a few fins in back, which required greatly reducing the pad tilt to halt lawndarting. It was also a lot angrier, blowing up said fins almost invariably when trying to pick up horizonatal velocity. Best result was 6.6 tonnes to a very low orbit for 1291/tonne using a Hammer for a Payload Assist Module, 'found that said 7.2t payload was about as much as one can get away with on a single kickback, as the turn gets too aggressive, nearly blowing up the fairing. A similar design using a Spark instead of a PAM did more poorly, failing to make orbit due to losing too much speed to the atmosphere after MECO, or not get enough horizontal kick out of the booster and running out of gas in the 990m/s upper stage and just not getting the periapsis up.