Zeiss Ikon

You sound like me three weeks ago. I deleted a save after I managed to strand all three of my sandbox pilots in Munar orbit, one in EVA, one in a Mk. 1 Command Pod with dry RCS tanks, and one in the Mk. 1-2 rescue ship without enough fuel left to get back to Kerbin. Prescription: multiple LKO rendezvous and docking practice flights before returning to Mun and beyond... Only took me a few tries to get to where I was able to dock an orange-tank transfer stage to a slowly tumbling, uncontrolled lander. Hint: learn to fly the navball on docking, and use cap-lock to reduce RCS translation authority when you get close.

I have Kubuntu 16.04.1 installed (alternate boot), but don't use it because so much of what I like in 14.04 is missing from 16.04; I can't make it look the way i want. I am running the 4.4 series kernel, which seems to be significantly faster than the "stock" 3.13 series. I'm not likely to change to Mint, and unless my visuals get updated (unlikely, because of changes from KDE 4 to KDE 5) I'll probably ride 14.04 until it drops. HOWEVER, I'm not completely opposed to logging out, changing interface (to XFCE, for instance), and logging back in before playing if KDE 4 is a probable source of my issues. I should clarify that I haven't measured FPS and, based on the explanation linked above, what I'm seeing probably isn't low frame rate, but rather the inability to keep up with physics in real time. I don't see screen stuttering unless I try to launch a 100+ parts vessels immediately after assembling it in VAB, and might not notice as long as actual frame rate stays above about 15 fps; what I do see is nearly constant "yellow clock" whenever I have a vessel that exceeds 50-60 parts, and intermittently when maneuvering smaller vessels with RCS. And this is with no mods; I don't plan to install MechJeb, but I'm sure I will want Kerbal Engineer and likely will want FAR (others I might want, like TAC Life Support, and various parts packs, shouldn't be big performance drains). I will try diddling with the physics slider before I commit to spending $300 or so upgrading my MB/CPU/RAM (and I'm still not really convinced that a 3.5 GHz dual core will even match my 2.7 GHz quad core for anything other than single-core-intensive tasks like KSP, which makes it a very uncertain tradeoff since most of my computer's use is NOT in KSP).

Laythe should have the same effect that keeps the subsurface oceans liquid in Callisto, Europa, and Enceladus -- because its orbit is elliptical, the change in tidal bulge as the distance to the primary changes each orbit kind of "kneads" the interior. Won't do much to the surface oceans, but it adds heat to the interior. In fact, on Io, it adds enough to melt sulfur to run all those volcanoes...

Yep, but then the nose cone hangs right around the vessel until I maneuver, and invariably gets bumped and kicked off course. Mostly I can dump the fairing and nose cone while still subortital, that one that went past Mun was an early flight, while I was still figuring this stuff out. I thought I could dump everything onto Mun and not have it float around the Kerbolar system -- but no, it's not that easy.

Last night, Val and Elyris continued their journey to Minmus. We left our heroes in a long elliptical phasing orbit. After two periapsis passes (consuming some fifty days) they were able to make a small burn to a Minmus encounter, at which another small burn (tens of m/s) arranged capture. The initial orbit was highly elliptical with a multi-day period, so at first Minmus periapsis they initiated another burn to lower apoapsis, winding up in a nearly circular orbit just below 15 km, with the mission timer standing at around +90 days. Val decoupled the lander, and was dismayed to find the tanks weren't full; apparently cross coupling had been left on and the transfer stage main engine had been drawing a small percentage of its fuel from the lander's tanks. Fortunately, Minmus requires very little dV, both to land and to regain orbit. Having determined there was plenty of fuel remaining, Val executed her deorbit burn and entered a steep descent toward a flat-bottomed depression in the moon's surface. A little jockeying with RCS on the way down (carefully, as RCS burns ascent fuel in this lander) ensured the landing was on flat ground, and with a minimum of over-braking, Val set the lander down on Minmus. The usual surface activities ensued -- plant the flag, take a regolith sample, write up a crew report -- and then it was time to get back into the lander to return to Minmus orbit. After a little difficulty finding the crew hatch to reboard the command pod (Val blamed the light, but Elyris said on back channel that it was probably just jitters; she'd had a similar reaction when she was first -- alone! -- on Mun), Val was ready to launch from Minmus. A little confusion with staging controls was cleared up, and the decoupler kicked the ascent module several meters up even before Val started the engines. Having learned her lesson from Elyris's Mun mission report, Val tipped over and boosted east almost immediately. Turns out, on Minmus that isn't the way; terrain is huge without gravity to flatten it; she had to react quickly and boost upward (far too much) to avoid collision with a hillside. Once clear of the slope, she found she was already on an escape trajectory and had to burn back before establishing her orbit, but again, the tiny size and mass of Minmus simplified things, and she was able to set up a phasing orbit leading to successful rendezvous and docking with Elyris in the transfer stage.

Wasn't Alan the one who (historically) opened the hatch too soon after landing and sank his Mercury capsule? Glad to see your Alan didn't make that mistake... Last night saw the first successful test launch of Selene 1 Mod. 3a, an upgrade of Selene 1 that grew out of the near-fistfight in the design review meeting previously referenced (this design was advanced as "staging is better than just adding more boosters"). As one might expect, performance was less spectacular than the model with strap-on boosters pumping fuel into the core, and liftoff more sedate than the previous Selene 1 Mod. 3 due to the mass of the second stage engine, but the (so far) standard upper stage stack was handily delivered to orbit with approximately 85% fuel remaining in the transfer tanks, and debris (stages, fairing, nose cone) left in immediately suborbital trajectory. Val and Elyris were in rotation, Val in the lander and Elyris piloting the transfer stage; their mission, barring difficulties getting to orbit, was to plant the first flag on Minmus. Elyris has previously walked on Mun, and Val has done a Munar flyby, but both commented on the difficulty of setting up a Minmus encounter. "That little ***** has a teeny little gravity well, and it's hard to hit at this distance" was Val's quotable. Of course, it didn't help that, due to a failure of mission planning, Mun was directly in the way for any sensible transfer to Minmus. Solution: wait in parking orbit before burning for Minmus. The time was spent with binoculars, watching transfer stages from two previous missions finish deorbiting (one with a spectacular mid-air explosion leaving only a shower of lightweight debris to impact at low velocity, the other less brilliantly as the tank and adapter survived the meltdown of the Rhino engine, stabilized base first, and impacted on land at near sonic speed). Once the light show was over, and Mun had moved along, came the orbit planning session that led to Val's comment. In the end, a burn was made to extend apoapsis to between the orbits of Mun and Minmus, then another burn at apoapsis to plane match and set up a phasing orbit (technique learned from rendezvous practice in LKO). Now, it's a matter of waiting for an encounter close enough to make a correction that will permit a capture. Elyris accused Val of failing to bring a deck of cards because she'd beaten her so badly at gin on their last mission together, but the real deal is that, with the ship still in launch configuration (far less flexible stack, to kept as long as possible), they don't even have the docking hatch to reach through -- so they were reduced to playing Twenty Questions over the intercom. Fortunately, there's lots of fuel cell power, with the SAS shut down during the long orbits. Getting home after the landing will be easier -- Kerbin's a nice fat target, and there's no need to hoard dV for capture or stress over plane changes -- the atmosphere does a fine job of slowing down a command pod, if you don't mind sitting under a radiant heater for a few minutes, and inclination really makes little difference in reentry, as long as you can avoid reentering retrograde as Elyris did after her rescue from Munar orbit.

This morning, with a half hour to spare on a half-day off work (due to illness overnight), I got time to "review" the staging setup on Selene 1 Mod 3a, the no-boosters version of my Mun/Minmus vessel. I say "review" staging, because this was intended to be an orbital test, but when the booster ran dry and I hit the space bar, the second stage motor didn't ignite -- check throttle, yep, it's up. Looked back up at the rocket, and the lander and transfer command pod, still coupled together, were breaking out through the side of the fairing. Well, that was unexpected. Fortunately, everything was falling clear of other parts, so I was able to manually deploy the four parachutes, then decouple the transfer command pod before jettisoning the lander's descent and ascent stages. Once both command pods were under parachute (a good demonstration of an abort procedure, anyway) I reverted the launch and returned to the VAB. I found that something about the rebuild surrounding inserting a stage break in place of a larger first stage apparently had rearranged my staging order. Once I got that straightened out, I was out of time to retest the vessel -- so, off to do that tonight.

I don't know. Can you? I don't see anything in the rules that says you aren't allowed, and one entry used an SSTO to shuttle the lander to and from LKO. Are you asking "Am I allowed to use a no-staging vessel for the challenge?" -- and if so, again, I don't see anything in the rules against it, though I don't see a category for 100% recovery, either.

This was in a game called There (aka There.com); it's been around since about 2003-2004 time frame, with about a year-long closure in (as I recall) 2012-2013. It's an online MMO without the overarching "game" found in games like WoW. More like Second Life for people with old computers (when I started it, I chose it over Second Life because it would run on Win98 in less than 1 GB RAM, and SL wouldn't, though There now requires at least WinXP and 1 GB -- it runs well under Wine, also). I won't argue that someone had way too much time on his hands. FWIW, the walk was mostly a proof that it was possible, I haven't heard of it being repeated in the intervening decade-plus (though a bunch of folks have gone around in various vehicles). The big differences between going to Jool and going to another star system would be travel time and communication range -- go to Jool, and your kerbals can get help from home, eventually -- just point a dish at Kerbin and ask, get a confirmation (or at least a read receipt) in an hour, at most, then wait for transfer windows and orbit time. Should be able to get what you need in a matter of a few in-game years, and unless you've installed life support mods, the worst that will happen is that the crew will complain about lack of snacks. Go to another star system, in which your MET was in the centuries before you got there (sublight travel, even without dV limits), and you likely won't have the signal range (if enabled) to get a message back to Kerbin, if signal lag is enabled it'll take years just to get the request through and years more to receive confirmation that they're sending what you need -- and centuries of kerbal time for it to arrive. Faster to build the capability to make what you need, if the mission planner actually remembered to send everything else needed...

One of the other "sandbox world" games I play, There, lets you do whatever you like with impractical travel times. Since avatars can walk on the surface of the ocean (until a few years ago, it was like blue concrete; since then, it's just about 1 m deep), in the early days one of the beta testers literally walked around the world. As I recall, he had to log in every morning after daily maintenance, relog several times a day, and the trip took several months. That game world is about the same size as Earth, however; a kerbal who could walk on the bottom of the ocean, could, barring visits from the Kraken, likely walk around Kerbin's equator in a matter of weeks (kerbals aren't fast walkers), not counting available time warps. All this to say, if the devs had put another star a few light years away (or scaled like the rest of the system, a few Kerbal years away at lightspeed) someone would have gone there by now, if only with infinite fuel cheat. IMO, interstellar travel isn't the focus of the game; it's about learning how conquering a solar system might be done, not about how to leave one.

I'm playing 100% stock, too, and I get engine shrouds and stack separators floating around all the time. Trying to get into the habit of staging while still suborbital or on collision course for a body like Mun, but the ejection velocity of a nose cone is enough to make it miss the Mun if I stage early in a tranMunar orbit...

Sigh. I (re)built my desktop system in late 2008, on a budget, after a motherboard failure. At that time, Core2Duo was the best I could afford, but the motherboard socket would accept Core2Quad, and when I could afford a used upgrade CPU, I bought one. With my last motherboard replacement, I was able to step up from 4 GB RAM to 8 GB. If I'm reading the specs correctly, that Pentium G4560 should have similar overall performance to my Core2Duo -- it's about 25% higher clock, same number of threads, and two cores instead of four, but the higher clock means it'll perform better with KSP, because KSP runs the most compute-intensive stuff on a single core -- right? The cost of the processor is attractive, and I see motherboards under $100, but I usually can't use the bottom end motherboards because I need multiple PCI slots for peripherals and the low end boards often only have one PCIEx16 for video upgrade. This might be a viable upgrade path if I reapportion some of my tax refund...

I know the thermal paste is good; I replaced a bad motherboard less than a year ago. At the time, I had to get a used one from eBay (took three tries to get one that would start up) due to budget constraints. When I swapped the CPU from one socket to another, I installed a new heat sink and fan, and used new thermal paste. Yeah, an upgrade isn't in the cards just now; it's hard to get performance comparisons I feel I can trust, but it looks like I'd have to get a Core i7 to improve CPU performance, and that, plus MB and 8 GB RAM, would set me back close to $700. I'll look for the delta-time slider -- am I correct in understanding that just increases the time step between physics updates? Kind of disappointing to find that modern software can't take advantage of quad core architecture, so I have to try to throw clock speed at it. I might have to look at overclocking my existing hardware. The motherboard seems to support it, and my temperature is very good as things stand.

Yes, I recall the zone lens used to focus the braking beam in Dragon's Egg and it's sequels. Is there enough gallium in the solar system to make that many gallium arsenide laser junctions? Or enough tungsten for the non-linear frequency doubling crystals you'll need when the lens construction gets put off a couple centuries? Give me a choice, I'd rather use a laser-triggered version of an Orion drive. Give it a mass ratio of ten or so and it'll get between nearby star systems in under a century -- and with inertial confinement's small pulses, the ship needn't be the size of a small city.

I bought KSP a few weeks ago, downloaded the 1.2.2 Linux-64 version, and I've been enthusiastically building and launching ships in sandbox (haven't started a career or science game yet). I've noticed that if I build a ship with more than 60 or so parts and then launch it immediately, or even if I restart the game and go direction to launch pad with a ship over about 80 parts, I get nearly constant "yellow clock", which I've read indicates frame rate lag. A few times, I've had frame rate (or other) lag so bad that keyboard commands or mouse clicks wouldn't catch on the first try, or require holding a key to take effect -- which can result in overcontrol bad enough to tumble a rocket during launch or cause other disasters. As far as I can tell, my computer is well above minimum requirements; I have a Core2Quad 2.67 GHz, 8 GB Ram, and a 1 GB nVidia GTX950 video running the nVidia proprietary drivers version 367.57 (not the generic "open" Linux drivers), in a PCI-E x16 expansion slot (my monitor is 1280x1024 with VGA connection; it's on the old side, but that shouldn't affect frame rate). I'm running Kubuntu 14.04 LTS 64-bit, kept updated daily, and generally don't have performance problems; among other things, i can run Path of Exile under Wine at a playable frame rate (and could when I had only 4 GB RAM installed), have no trouble editing large images in GIMP, though I do get some lag issues with streaming video that I believe are more to do with my data connection than my hardware (they got worse when I moved and lost a 1 Gb/s fiber to the house connection, replaced by my current 300 Mb/s TV cable connection). Again, connection quality shouldn't affect a game running locally, within my own machine. My OS and KSP install are on an SSD connected via SATA (not sure what SATA version my motherboard supports, but the SSD is quite noticeably faster than the platter drive it replaced). What do I need to look for as a source of my seeming poor performance? I'd like to add some mods, a setup similar to what Scott Manley was running when he recorded his Interstellar Quest videos for YouTube. What do I need to fix to handle higher part counts (stations, assembled-in-orbit large interplanetary missions, etc.) along with a reasonable set of mods along those lines?

An image from one of Niven's (without Pournelle) Man-Kzin Wars collections is of asteroids mounting lasers in this class "darting in and out on the thrust of their main weapons". The recoil of such a laser is not inconsiderable. And you'll need a lot more than terawatt laser power to give a light sail with an actual payload enough acceleration to bother (especially at interstellar distance; even a coherent laser beam spreads over that kind of range). As I recall, direct sunlight at Earth's orbit is good for something like .001 g on the thinnest practical aluminized mylar without any structure at all, never mind a payload massing several times what the sail does. You would therefore need a laser with a beam density thousands of times that of sunlight to make a light sail into a practical drive that requires less than decades to get anywhere, even within a single system. For an interstellar probe, that kind of long-term acceleration is the best we can manage with current technology -- but if you book passage on a ship with a light sail, you're sending your long-term progeny, not going yourself.

Today saw a design review of Selene 1 Mod. 3a and Selene 1 Mod 3-1, following a Mun flight of the latter vessel in which Jeb was to land while Elyris piloted the transfer stage. The design review was partially prompted by Jeb's spectacular crash while attempting landing within hiking distance of the flag from Elyris's previous landing. There was initial concern that a flaw in the vessel might have caused the crash, but examination of vehicle telemetry and Elyris's eyewitness report led the review committee to conclude with 60% confidence that Jeb simply screwed up -- this was to have been the first landing with the new two-stage lander, and it's believed that Jeb simply got too low, with too little thrust, overshot the landing zone by several kilometers, and struck the wall of the crater at high velocity (calculation based on observed burn time and position suggests impact was at a significant fraction of Munar orbit velocity). This conclusion was supported by the fact that he had discussed maneuver planning over the intercom with Elyris, and appeared to have set up a low eccentricity suborbital path that passed directly over the previous landing site at very low altitude. This was compounded by the rather long deceleration burn required by the LV-909 Terrier engine with the significantly heavier lander (LF/O descent stage under what was essentially the same monopropellant-only lander that stranded Elyris in Munar orbit, repurposed as an ascent stage). The design review, however, did find and correct a number of minor defects in the vessel, along with corresponding ones in the Mod. 3a version, including redundant heat shields, on both the transfer stage RCS tank (intended, this tank is kept with the command pod through reentry) and the command pod itself (unnecessary, as the pod is to be separated from the RCS tank at or after parachute deployment). Also, there was found to be no means of decoupling the transfer stage RCS tank other than jettisoning the command pod's redundant heat shield. Poorly distributed fuel cells and antennae were also found and corrected, and staging sequence reviewed and updated. Redundant struts were eliminated. The same error of omission of stack separator and docking clamp between the transfer stage command pod and the lander was found in the Mod. 3a as had existed in the Mod. 3-1. Finally, both vessels' fairings were modified to minimize cross section and reduce shoulder angle, both of which ought to reduce aerodynamic pressure and drag losses during the Max-Q regime during launch. Any issues with upper stage configuration aside, the Mod. 3-1 launched well; the two boosters, each with two orange 640 size tanks and a Mainsail engine, plus fuel transfer to the core, improved initial acceleration and allowed early yaw maneuver to initiate gravity turn, though they did (as criticized during the design phase) require throttling back rather deeply for much of the atmospheric portion of the launch. However, the combination allowed placing the transfer stage/lander stack into a stable orbit without using any transfer stage dV beyond what was needed to recircularize after deorbiting the booster core. Thus, after transferring to Mun, capturing into Munar orbit, and transferring back to Kerbin reentry (albeit without the mass of the lander's command pod and its heat shield), the transfer stage still had more than 30% remaining fuel when it was jettisoned to burn up in Kerbin's atmosphere. This much reserve seems to qualify the Mod. 3-1a (designation after design review and corrections) provisionally for Duna flyby, Mun/Minmus missions with heavier landers, and other operations beyond LKO.

This. My current base launcher, Selene 1, was too heavy to lift authoritatively with a single Mammoth, but adding four Thuds (and 480 kN) brought the liftoff thrust up enough to get off the pad smartly, without a huge amount of extra mass, totally unnecessary thrust levels from SRBs, or a lot of contortions to get other engines added onto the Mammoth cluster. The four Thuds are just about like another half Vector added to the Mammoth -- which was just right for a vessel in the 150-170 T launch mass range. They include their own fairing, too, so I don't need extra mass or effort to streamline a radial mounted engine. Two Thuds equal one Reliant, for thrust. They weigh more, of course, but they're a lot easier to add alongside an engine that needs just a little help. And, as of 1.2.2, they have higher ASL Isp, and almost the same vac Isp.

Last night was another design brainstorm session at KSC -- first order of business (on pain of pain promised by Jeb -- he was supposed to land on Mun!) was to rectify the oversight involving stack separators and docking clamps (or lack thereof) on the transfer stage command pod of Selene 1 Mod. 3, but that was followed by a number of opinions suggesting that this ship lacked the dV to go anywhere beyond Minmus while pushing that two-stage lander (despite the lander having only one acceleration couch). End result was that boosters were added to increase the mass that can be orbited, resulting in Selene 1 Mod. 3-1. Alternate opinions, however, were that the extra thrust and complexity of boosters, plus the need to throttle back deeply to avoid shock heating during the Max-Q period, wasn't needed so much as to dump extra launch mass before getting high enough to deploy the fairing, while there was still fuel to push the now-lightened vessel. Just before a fist fight broke out in the conference room, someone waved a napkin from the coffee bar with the the booster of Selene 1 Mod. 3 broken into two stages (at the obvious location, the join between the two 14,400 tanks), and a Rhino engine inserted. Since (as it turned out) that was the project director, everyone calmed down and pitched in drawing up that version -- Selene 1 Mod 3a -- as well. Both launchers are likely to see service; the lighter, simpler one for future Mun and Minmus missions, and the heavier one with larger orbited mass capacity for more distant destinations.

Last night, Jeb and Val made the first test flight of the new Selene 1 Mod. 3. Launch was smooth, as expected (the only change in the launcher was swapping out four of the 7200 tanks for two of the 14400 size). The vessel made orbit with just a little boost from the second/transfer stage engine, leaving plenty of fuel for transMunar insertion, Munar capture, and Kerbin return. On arriving in Munar orbit, Jeb decoupled... ...er... ...where's the decoupling trigger? Val, did they put it in your command pod? Nope, no decoupling trigger here. After more searching, the duo determined that the VAB crew had managed to forget to install either the stack seperator or the docking clamp on the command pod that remains with the transfer stage. The only way Jeb was going down to the Mun would be by explosive decoupling, and he likes Val too much to do that to her. Nothing for it, then, but a return to Kerbin to have a little talk with the VAB foreman. Of course, there's the little matter of reentering and landing under parachute with the lander still attached and full of LF/O for the descent stage... Not to worry. Val set up the Munar return with an aerobraking periapsis of about 45 km, then did a burn just before atmospheric interface to lower periapsis to get a reasonable orbit period, before dumping the transfer stage (now down to a whisper of fuel after spending dV that wouldn't normally be needed for Mun and Minmus missions). With crossed fingers (not easy, have you seen Kerbal hands?), Val and Jeb rode into the flames -- and found the stack of transfer command pod and complete lander was stable enough for SAS to keep it pointed retrograde. After three-plus minutes enveloped in shock heating, burning the lander's ascent motors (Puff monopropellant engines on their radial mounts) to add braking, the roar of the airflow began to lessen, the heating dropped off, and they were in a low(ish) Kerbin orbit. Next pass, more ascent engine burns ensured they would land on this entry (the ablator on the transfer stage command pod was getting a little thin), and down they came. As they dropped close to Mach 1, the stack began to destabilize (probably due to loss of the massive shock wave from the blunt heat shield), but Val was able to keep it steady enough with RCS until it had slowed enough to deploy parachutes (lower than normal, because the sectional density gave a higher terminal velocity at any given altitude). Manual deployment was chosen, because staging off the lander's ascent stage would most likely have left Val, still stuck with the descent stage's engine and full LF/O tank, in an unstable junk can (not to mention making it impossible, in game, to control both vessels). With four radial parachutes deployed, however, the falling speed was only half again normal (about 8 m/s instead of 5.5), and as the sea surface approached, Jeb burned the Puff ascent engines again to slow descent rate, striking the sea at only 5 m/s. The last issue was whether the stack would float, but it did, upright (which meant Val's command pod was submerged, but the recovery crew quickly sorted that out). We will mercifully bypass the scene back at KSC when the recovery transport pulled in. Suffice to say, there will be a new Mod. of Selene 1 before next launch...

And, after a koffee-fueled marathon brainstorming session, which included an accidental fire (allegedly started by too-vigorous erasing) that destroyed the new drawings, requiring recreation from notes and memory, the KSP design team have begun actual construction of Selene 1 Mod. 3 while the maintenance crew work on resurfacing the conference room table. Now at a (relatively) slim 254.6 T, the five tonnes trimmed relative to Selene 1 Mod. 2 is entirely from the upper stages, meaning less (or possibly no) second stage fuel will be required to reach a stable orbit. Elimination of the service module from the transfer stage command pod also means the transfer stage need not be discarded with fuel still in the tanks -- the last Munar orbit rescue mission flown with Selene 1 Mod. 2 left close to 30% of transfer stage fuel after Munar capture and circularization; that fuel could have brought the entire vessel back to LKO, had it not been necessary to jettison the transfer stage in order to redock the command/service module with the lander. Other important upgrades are a two-stage lander, insurance against stranding either on the Munar surface or in Munar orbit (if you've landed, you know you have enough dV to get back up without having to use your EVA jets to circularize, and an abort back to orbit is always available via a large, brightly colored panic button), and repositioning of the Vernor jets on the transfer stage to increase maneuvering authority (though monopropellant RCS will still be required to dock, due to the lack of forward/back and roll jets that use Lf/O).

Last night, Jeb disabused me of a significant combination of miscalculation and memory failure. I let him test pilot a flight of Selene 2 -- and far from getting to orbit with much more upper stage fuel remaining, due to my imagined lightening of the payload stages, it wound up needing almost half the fuel from the second stage just to get into a circular orbit, where Selene 1 Mod. 2 needed just a circularizing burn from the second (transfer) stage. Going back and directly comparing the two vessels, I see the problem -- Selene 1 Mod. 2 has a liftoff weight of 259.7 T, while Selene 2 managed to bulk up to 281.1 T -- hence why the ship barely staggered off the pad and needed so much of what was to be transfer dV just to get into orbit. The Selene 2 design (which was to use a 2.5 m service module under the Mk. 1-2 Command Pod) has now been scrapped, along with Selene 2 Mod. 1 (a monstrosity with three parallel Mammoth based boosters), and work is set to begin on Selene 1 Mod. 3, which will incorporate the original ideas for launching the lander atop the command pod, saving the mass of the primary pilot's service module, but will use an additional stage, hoping to get the transfer/pusher stage to LKO with completely full tanks, which should leave enough dV for (at least) a flyby of Duna as well as landings on either Mun or Minmus (possibly even Ike or Duna itself, if the dV budget can include making orbit and then breaking out for Kerbin again).

Slow night last night; had to run an errand, so all I managed in KSP was upgrading Selene 1 Mod. 2 into Selene 2. I was correct, rearranging the module order allowed me to upgrade to a Mk. 1-2 three-seater command module, and a 2.5 m service module for it, let the (now 2-stage) lander ride on its nose, and still save on liftoff weight. This might, with an optimum launch profile, SSTO to put the second stage, CSM, and lander into orbit with full tanks. If so, the second stage probably has enough dV to reach Duna (but I'll have to get Kerbal Engineer to know if the CSM has enough to get home from there). I'll know more when I can let Jeb test fly it.

The only difference that matters between one reentry and the next is the velocity you need to get rid of. If you make a swing out past Mun, let your vessel fall all the way in, and then make a prograde burn (depressed vector to prevent raising periapsis) you can add velocity and test in the same gravity and atmosphere you'll be encountering in the actual mission. You can even do this without hyperediting, though that will save time building launchers and waiting for orbits to go up as well as down. What you need to know is mostly how deep in to the atmosphere you need to dive at a given encounter velocity to avoid overheating stuff, squashing your Kerbals flat from the G forces, and so forth. I found out today that my usual choice from LKO and orbits up to about 400 km apoKerb, 37 km, apparently lets a vessel overheat if applied on a Munar return with 3000+ m/s entry velocity. The vessel wasn't destroyed, but it melted off one RCS block, which I take as a warning. Now I'm going to have to find out if shallower is better (scrub off speed in the upper atmosphere, and risk skipping out to make another, shorter orbit and do it again) or deeper (higher G forces, but dipping down into the thicker air will slow the vessel faster and reduce the heating -- I think). You'll be going faster coming back from Duna than a normal return from Mun (though I accidentally set up a retrograde reentry, which added about 600 m/s compared to prograde due to Kerbin's rotation -- in theory, that's more than the dV difference for Duna vs. Mun).

Today, Jeb finished his trip to Munar orbit to rescue Elyris. Elyris had become the first Kerbal to land on and walk on the surface of Mun, but wasted too much lander fuel getting down to be able to get back up (must consider two-stage landers as a hedge against getting down with too little dV left to get back up -- if the descent stage runs dry, quickly stage off the ascent stage and return to orbit). It wasn't certain she'd be short on dV, however, so she chose to launch -- went too vertical, instead of boosting east as soon as she was clear of terrain, though the only way that might have made the difference is by leaving her close enough for her nearly-dry RCS thrusters to finish the job. As it happened, she bailed in her space suit and used its maneuver unit to circularize -- leaving her in orbit, alone, with about 80% EVA fuel, but no way for Jeb to help her, as he was in the single-seat pusher module. The best way Jeb could help, then, was to light out for home and come back ASAP with an empty module in his stack. The KSC crew stepped up, readying a duplicate of the Mun ship, Selene 1 Mod. 2, in record time, and as soon as he stepped off the recovery transport Jeb was climbing into the command pod. Up he went, another nominal launch that left the second stage in stable orbit with about 80% fuel remaining. The burn for Mun was made in the first window, followed by the unavoidable wait for the Munar capture burn. Jeb waited to finish the capture to uncouple his command pod and dock it nose to nose with the lander pod, remembering the way the stack had flexed under full thrust once the launch struts were released. That maneuver was carried out about as quickly as the pusher's engine shroud could clear the lander, and then Jeb made a plane correction burn, ditched the transfer stage to the Munar surface, and circularized to wait in a slightly lower orbit to catch up with Elyris. Once he had an intersection of 2.5 km, he started closing the distance by flying the ball. First try, he used the Reliant at low throttle to close, and got caught by the limited ability of the stack to slow under only RCS, but even though Elyris went by his window at close to 20 m/s, he got the lander/pusher stack turned and was closing again before she could get more than 500 meters away. Second time, he didn't rush, and parked the vessel at a dead stop a mere fifteen meters away from Elyris, holding it steady as she crept in with her EVA pack until she was able to reach the hatch in the duplicate lander. As a precaution, Jeb jettisoned the lander's engine and RCS tank before Elyris could even get strapped in (to make sure she didn't try to make a better landing on the second try), then burned for Kerbin in the first window. He set up Elyris, with fully charged batteries and full command pod RCS, for a 37 km periapsis, then decoupled and corrected his own orbit to clear atmosphere (to avoid reentering simultaneously -- previously found to be extremely hazardous). The two craft flew in formation from Mun back to Kerbin, still within radar range to the point where Jeb made a burn to lower his apoapsis so it wouldn't be a week before he could reenter. That deceleration gave him a fine view forward as Elyris slammed into the atmosphere at above 3 km/s, starting to burn above 50 km. Busy watching overheat warnings from all over the tiny vessel, she was startled by an explosion as one of the RCS quads melted down, but the remainder of the craft (including, crucially, the parachutes) was undamaged, and she landed safely in the ocean a few hundred kilometers east of KSC. One orbit later (an hour or so, due to the high apoapsis he'd settled for to ensure he left enough fuel to deorbit), Jeb returned to Kerbin on a nearly identical trajectory -- but because Kerbin had turned under him, he landed on the desert continent far to the west of the Space Center. Still, all's well that ends well; if Elyris got the privilege of being the first Kerbal to walk on the Mun, Jeb had the distinction of being the first to rescue a stranded Kerbonaut from space. The ticker tape had hardly been swept up before the design team were at work upgrading the lander and designing the next version of the Selene Mun ship -- now to be repurposed to take Kerbals to Minmus, and eventually, perhaps, to Duna.