Zeiss Ikon

There may already be a mod for this -- something like "Easy Vessel Switcher" or the like (that one lets you switch when deep in atmosphere or out of physics range, when the stock game wouldn't let you). Might be worth checking on.

Worth noting that for contract fulfillment purposes, you'll automatically fulfill a flyby requirement if you go into an orbit around the designated body. So, if you have a tourist who wants to Flyby the Mun, and also Orbit around the Mun, if you keep your contract status display open as you warp outward toward Mun, you'll see the Flyby clause get the green check (seemingly, as soon as you enter SOI), even if you subsequently brake into an orbit (and no longer have an escape trajectory from the body's SOI). Flyby, for contracts, seems to just mean enter the SOI. On my very first flyby contract, there was a fulfillment hint: "To fulfill this, just fly anywhere near the Mun." Sounds suspiciously like entering the Mun's SOI to me.

For a tailless or flying wing design, you need to have the COM a little further forward and design in either twist in the wing or preset up elevon to raise the nose against the nose-down moment of COM ahead of COL. Using elevon or wing twist this way ensures that as speed increases, the nose will rise, and as speed decreases, the nose will drop, making the craft what model airplane designers call "longitudinally stable." The other issue with this and a couple other Horten designs is that without a vertical fin, you're going to have huge issues with adverse yaw -- that is, when you apply aileron (elevon) for roll, the down-going wing will want to fly faster and the up-going wing will want to slow down -- which is exactly opposite the direction you're planning to turn. One way to work around this is to couple spoilers to the roll control channel; they'll lower a wing while adding drag, instead of reducing it. Combine those with reduced roll throw on the elevons, and you can get a yaw-neutral roll, or even a little proverse yaw if you like feeling as if you ailerons and rudder are coupled (like in an original Ercoupe). It's possible to use spoilers alone for roll, but you'll get a lot of proverse yaw, probably enough to make you think the aircraft is handling badly. Combining the spoilers with aileron (or elevon roll), and having adjustment for the roll authority in the ailerons or elevons, gives the best of both worlds.

Aha. That explains the orbiter subassembly's misbehavior, but doesn't make sense of why the partial assembly (800 tank, storage bay, and Swivel, mirror image symmetry wings and tail fin) would only attach at the wing root, not anywhere else on the (first part attached) tank, after I accidentally picked it off the decoupler. By this rule, I should have been able to stick it back on in exactly the orientation I'd built it; instead, it wanted to rotate 45 degrees and offset so the decoupler was attached equally on the tank and either wing.

So, the other night, I was redesigning my four-passenger Munar orbit tourist bus (stock career, 1.3). Because I had a very good-flying and reliable two-passenger space glider orbiter, and the four-passenger version (stretched, and tandem wings) hadn't worked at all well, I decided to just strap two of the reliable ones belly to belly. I rearranged the strap-on boosters so the booster cores could be close together, then pulled the subassembly, an entire orbiter, out of the storage shed and went to stick it on the radial decoupler on the primary orbiter's belly (planning to build down the booster from there, likely also with a subassembly). https://imgur.com/a/H5kvP (Album showing similar orbiter -- added a 100 unit Lf/O tank ahead of the Crew Cabin for Munar service) Imagine my consternation when no way, no how, would the fully assembled orbiter stick on the radial decoupler. I satisfied myself that the decoupler's attachment node was working -- I could pull a fuel tank out of the parts rack and stick it right on there, but the orbiter subassembly wouldn't go. Furthermore, the subassembly would happily mount to an end node on a tank that was rerooted upward from an engine (equivalent to being built from the ground up). Even odder, I started building up a new orbiter from the fuel tank (22 parts, not that big a challenge), got the storage bay, engine, wings, and tail fin mounted, then accidentally pulled the tank off the decoupler -- and this partial orbiter assembly would only stick onto the decoupler at the joint between a wing and the tank. It would stick there reliably, on either wing root, but no way would the tank stick back onto the decoupler. Thinking about it now, I wonder if this doesn't come in some way from having parts mounted in mirror symmetry, disabling radial attachment. Contrary to this idea, however, the orbiter that was still on the stack gave no trouble in mounting the radial decoupler to its belly. I did eventually get the orbiter built back up from the primary fuel tank, everything in place, and verified with a reverted launch that the combined vessel handles exactly like the single-stack version (not too suprising, but gratifying none the less). I was left, however, with this mystery. Any idea why the orbiter subassembly wouldn't latch onto the radial decoupler, and the partial assembly would latch only at the wing roots?

How does it take 36+ days to get to the Moon and back? Apollo did it in three days each way?!

I spent some time last night designing what has to be my most Kerbal vessel to date. If the new "stretched" tourist bus doesn't reenter well, but you need the capacity to launch four tourists at once, what do you do? How about, couple-and-strut two very slightly modified (for strap-on clearance) two-passenger buses together, belly to belly? With six Swivels and four Reliants ignited on the pad, Taxicab V flies just like Taxicab III, and is capable of reaching orbit with significant fuel remaining in its twin booster cores. From there, the orbiters can be separated for individual missions, or can continue into Munar orbit and return as a unit before separating. Operational doctrine is to separate the orbiters before burning for Kerbin return, to avoid confusing Mission Control with concurrent reentries, but in practice this decision will be left to the command pilot; if sufficient fuel remains, the option exists to return to LKO parking orbit before separation for reentry.

I've been playing for almost a year, no idea how many hours (I don't get to play more than a few hours a week, so probably no more than 150 hours). I've been to Mun and Minmus, of course, and done crewed flyby of Duna, landing on Gilly, and captured an asteroid into Kerbin orbit (and mined it dry). I don't do much with probes; it's all crewed. I also haven't messed with life support, so it does no harm for Val to spend seven years in a Mk. 1-2 Command Pod...

Based on my (recent) experience, a Kerbal who dies when a cockpit or pod overheats doesn't leave anything denser than smoke behind. Since Kerbals can live years, or even decades, in space suits or tiny command pods, I doubt they die naturally; they seem to die only in an explosion when they or the vessel they're in is overstressed in some way. And the explosion leaves nothing -- so nothing to dispose of.

Last night, I killed Adeny Kerman (in my career game). I have a few photos from the mission, but they aren't up on imgur yet; I may come back and offer them up when I have more time. The contract was to take four (4) tourists variously to orbit and fly by the Mun. Adeny, the newest pilot in the Program, had been out to Mun orbit as a passenger/student on Jeb's previous flight, and was now able to fly prograde and retrograde hold -- same as both Jeb and Val, though he had fewer flights. He was picked for the four tourist excursion; Val was going to fly two VIPs to Munar orbit following, then there were a pair of two tourist orbital flights on tap. In a possible bad decision, Adeny was handed the newest tourist bus -- Taxicab IV, with two passenger cabins and tandem wings plus a canard, and 50% greater fuel capacity than Taxicab III. Like Taxicab III, the dorsal surface was festooned with parachutes (Mission Control is still waiting on R&D to provide landing gear that can stand up to supersonic/hypersonic flight). The new secondary wing also had RCS quads at the tips, but the vessel had the same monopropellant capacity as Taxicab III. Launch was a little difficult; even with the booster fins upgraded to the same swept wings used on the orbiter, the vessel is less stable at launch than Taxicab III (COM is further aft, due to the required upgrade from four to six strap-on boosters). With proper nose management, however, Adeny was able to pilot the stack into orbit, and once there, set up his trans-Munar burn. Despite the much heavier booster, the orbiter's engine and fuel had to be used to circularize. Adeny calculated there was enough fuel to complete the mission, and there would be an opportunity for abort back to Kerbin instead of capture if his calculations turned out to be incorrect. Munar orbit capture was nominal, however, using just less than half the remaining fuel -- return from Munar orbit takes the same delta-V as Munar orbit capture from transfer orbit, so that was fine. After completing the contract orbit and giving the tourists the best view of the Mun ever achieved without magnification (orbit was 90x91 km), Adeny set up his return burn -- which completed with a 59 km Kerbin periapsis for a first aerobraking pass, leaving about 4 units of Lf/O and monopropellant tanks nearly full (a small correction burn had been done using RCS while outbound). Well, that's okay, it's all downhill from here, right? First aerobrake pass demonstrated that apoapsis was too high; very little braking occurred, and Adeny used almost half the monopropellant slowing with the RCS. At apoapsis (still above 2000 km) he adjusted his periapsis down to 54 km (a tiny RCS burn, just a few m/s). The next aerobrake pass confirmed that Taxicab IV shares one of Taxicab III's problems -- it can't hold its nose up high enough for reentry with aerodynamics alone; in fact, even with additional elevons added on the trailing wing, pitch authority is less than Taxicab III. Still, with a little RCS assistance, Adeny was able to keep the nose pointed vertically upward through this pass -- but now RCS was nearly empty, and the batteries (last fully charged by the Swivel's alternator during the Kerbin transfer burn) were down to about half capacity. Next aerobrake pass, with similar periapsis, saw enough energy bled away to ensure the ship would land. It also, however, used the last of the monopropellant, and batteries were down to 5% by the time the ship was down to 40 km. Adeny killed the reaction wheel, and continued flying on aerodynamics alone -- still able to keep the nose up at about 45 degrees AoA, lower than preferred, but all the vessel could do without RCS or reaction wheel assistance. At 29 km, with velocity down to 1900 m/s, the Mk. 1 cockpit failed due to excessive heat, killing Adeny instantly. He must have suspected this might happen, because he had pre-armed the parachutes (doctrine for the Taxicab III is to hold the parachutes, as the vessel lands slowly enough to make ditching in the ocean a viable alternative to parachute landing). The remainder of the vessel (lacking any control inputs and the canard, and with COM well back from where it ought to be relative to the flying surfaces) immediately started to spin and rapidly shed the bulk of its remaining speed, the four tourists still conscious and uninjured. The headless vessel slowed enough in its unstable configuration that, when the air pressure rose into the "safe" range for the parachutes, they deployed -- eight furled canopies that lowered the vessel, still spinning, at a mere 200 m/s until their full opening altitude of 1000 m. From there down, the vessel dropped stably, a little tail down (unbalanced by the missing mass of the cockpit), and touched down at a mere 4.8 m/s. All four tourists were fine, and most of the orbiter was recovered intact, but Adeny has gone to the Kraken, a victim of the cardboard and foil construction of the Mk. 1 cockpit. Taxicab IV has been grounded pending design review. Space Center authorities have announced that open tourist contracts will be serviced with the Taxicab III, which has an excellent safety record. Future tourist flights will also be instrumented, so that excursions can also gather science data to advance the Program.

Going way up high is the only practical way to change from prograde to retrograde (or vice versa). Adding the aerobraking is a nice way to get from "long skinny orbit you can change cheaply" to "an orbit like ordinary people would use for ordinary purposes." I've done it in Kerbin's SOI when I was trying to intercept an asteroid, though I didn't aerobrake because I was trying to match with the asteroid well before periapsis (it was on a collision course, I was trying to divert and capture at the same time -- I failed, BTW). Of course, if it's an orbit around the Sun, it takes years to get that high and years more to fall back, leading folks trying to rescue a retrograde Kerbal to do it the hard way.

The reason imgur is popular here is that it's free (unlike Photobucket, who now want $400/yr to allow "third party hosting"), gives unlimited storage, and handles embedding images very smoothly. Just upload your image there (or create an "album" with multiple related images), then get the link to the full size image from imgur and just paste it into your posting here. This forum will automagically embed your image and prompt you whether that's okay (alternative is to keep it as a link, which happens automatically for any link that isn't an image on imgur).

I think the BFR/BFS has a good chance to provide the first "flag and footprints" on Mars, as well as starting a permanent occupation there -- if only because SpaceX has a pretty good record for delivering, albeit a bit late. Hence, I think a BFS will visit Mars around 2050, more likely than 2030, and we'll have a base on the Moon first (technology demonstrator, reduced delta-V fuel source). Beyond that time frame, I don't see manned missions to Jupiter or Saturn by 2100, just because the orbit time to get there (even one way) will greatly exceed the time an astronaut can spend outside the Van Allen belts and stay anywhere close to lifetime radiation exposure limits -- and I don't see a likely breakthrough in shielding before 2100. What we might well see, instead, are crewed asteroid missions. With a good transfer window and a cometary orbit, a mission to Ceres (perhaps to test ice extraction technology or even establish a long term presence) needn't be any longer than a Hohmann transfer to Mars, and once in place, there are resources available on site to refuel the ship and provide long term shelter (i.e. mass shielding, as with underground Lunar bases).

I'd suggest you start with the tutorials. I skipped them, because I don't follow advice, but I've also been a space enthusiast since the 1960s, built and flew model rockets both in the early 1970s and again in the 1990s, and watched a lot of YouTube videos before I even had the game. I started by finding instructions on the web about how to build and fly a rocket into orbit in the free demo; once I had the game, in my first sandbox save, I had orbit on my third launch (first two lacked sufficient delta-V). But if you don't like tutorials, follow the advice above, about adding stages and seeing what you get. Read the part descriptions. Find out for yourself what various engines can do. Learn how the nav ball works. Watch Scott Manley and Mark Thrimm videos on YouTube. You'll get it. It's not -- oh, yeah, it is rocket science, but it's not brain surgery.

You might want to correct the spelling of Robert Zubrin's name on that... Just saying.

There's a "drive" that pumps ore (or other mass, but ore has the highest density of any transferrable resource) back and forth between rotating tanks. Scott Manley demonstrated such a "reactionless drive", using KOS to control the transfers, and was able to actually lift off the surface of Kerbin with it. There's a short series of videos on his channel showing his initial demonstration of the effect, then various iterations of development of the drive. I'm not sure if this is the same as the "Kraken drive", but as far as I know, it isn't any more prone to attract Kraken attacks than any other design that takes advantage of the lack of collision between parts of the same vessel.

The slow hardware and rapidity of Mariner's flight didn't allow it, but you can create a full color image by combining any two primary filters (or even, as demonstrated by Edwin Land, one color and an unfiltered image). This was done commercially for some years prior to about 1940, with "two-color Technicolor", which used only two color filtered films (usually red and green filtered), sometimes with a grayscale strip, to project an image that the eye would interpret as "color". Comparing two-color with the more commonly seen three-color Technicolor, you can tell which is which, but the two-color is clearly still "color". Land Color, using one filter and one unfiltered, always lacks some hues, but still reads as "color" image when viewed (BTW, Land Color even works if the eyes see the two images, filtered and unfiltered, separately).

If you have a single well-defined position and velocity, and know the value and radius of the local gravitational field, you've got everything you need to calculate an orbit -- including finding the orbital elements. Astronomers usually need three observations to define an orbit, because they can't directly measure velocity, and get position only as a direction from the point of observation.

A digitized photo (in grayscale, the Mariner camera didn't have color) would be transmitted and stored as an array of numbers, which would define the level of brightness of each pixel in the array -- akin to a grayscale BMP format image file. I, also, hadn't been aware that Mariner had transmitted digitally; I don't think even NASA had the technology to do that in the mid-1960s. The camera would have to have been slow-scan in order to digitize an image with even NTSC broadcast resolution (approximately 1/3 megapixel) with the electronics available in the day, and there was no way other than magnetic tape loop or storage scope to store a video still. Apollo footage from the Lunar surface was transmitted in analog form (albeit at higher resolution than then-current broadcast TV) -- why the step backward if Mariner had the ability to send digital data? Edit: 'Doh! I'm confusing Mariner with Ranger and Surveyor on the Moon. By the mid-1970s, the technology to digitize a TV image could proceed in nearly real time and the sensors were solid state (at least in NASA equipment).

I'm used to seeing eccentricity as a scalar, calculated from scalars (scalar lengths of semi-major and semi-minor axes, which can be measured directly). I'm no mathematician, but you're probably getting something akin to the vector that defines the semi-major axis in 3-space, with the scalar eccentricity mixed in.

No, but trying to find a mod that does what you want does. I spent all my (very limited) playing time yesterday trying to find a suitable tech tree mod. I found three tech tree mods, total, of which one looked likely to be close to what I wanted. I had thought there was once one called "Realistic Progression", but searching for that, or reasonable variations of it, yielded nothing. I like this idea, but it sounds as if the only chance of it happening is to buy a previous DLC I'm not at all sure I want/need. I don't like that idea; my game budget is limited in more than just time (the list of things I'd like to do and don't have free money for is about as long as the list of things I'd like to do and don't have time for -- and they overlap a lot). I'm not a programmer (I'd done a little programming over the past nearly 40 years, but if you're not doing this stuff every day, you can't even keep up with the tools, and the last time I tried to relearn ANSI C -- yes, useless for mods, but nice for original programs and I'd actually used it previously -- I found myself bogged down with a bug in my project that I couldn't kill and then my "play" time evaporated). I've edited config files for various things, but I gave it up a while back, when the complexity level started to get out of hand (I won't even try to dig into my browser's configs, for instance). Furthermore, see above about time limitations; there's no chance at all that I'll create my own tech tree mod if it's more involved that dragging items from node to node and/or resizing nodes. Bottom line, I might, possibly, pay for a tech tree mod like you describe, @nobodyhasthis2, but I won't let that desire make me buy DLC I don't want or need (or, in this case, know anything about).

True, but it still bugs me that (for instance) we have reaction wheels before RCS, and don't get anything you could call a wing until we've got the rockets that can go to the Mun. In the real world, we had thrust vectoring (jet vanes in the German A-4) before RCS (one early helicopter prototype, modified F-104, X-15, Mercury) before reaction wheels (long term satellites, still not used for manned vehicles AFAIK). We had high-subsonic aircraft before rockets that could leave the atmosphere, and the first manned flights that needed RCS were winged. We had liquid fueled rockets boosting men (Redstone, Atlas, Titan) before we had solid boosters that large. That progression is much more interesting to me...

When you say you "disabled RCS on a part" I'm wondering if you disabled the RCS quads or ports in the VAB. If you did, then you won't be able to reenable them once in space with the RCS toggle (R); you'll have to right click each individual RCS unit and reenable it (if you have advanced tweakables on, you'll have to do this for each function of each RCS unit -- roll, yaw, pitch, fore/aft, dorsal/ventral, port/starboard -- that you turned off in VAB).

Upgrading the desktop computer I have would almost certainly improve my game experience -- I'm running a Core2Quad at 2.7 GHz. Almost any reasonably current Core i-something processor at comparable or higher clock will perform better in KSP, because it will do more per core (real or virtual), per clock cycle. I recently bought a laptop with a mobile Core i5, dual cores at 2.9 GHz, and it significantly (like 15%) outperforms my desktop machine even in multi-core tasks -- for work like BOINC tasks, it does better per virtual core than the Core2Quad, same RAM size and the desktop machine has an SSD while the laptop has a platter hard disk. Naturally, it runs KSP at least as well as the desktop, even though I'd expect the desktop machine to have an advantage on graphics (nVidia GTx 750 vs. Intel something-or-other in the laptop). So, if I could get even a dual-core i5 for my desktop at, say, 3.5 GHz, it should run circles around the current Core2Quad. Then again, I installed the Core2Quad as an upgrade (from Core2Duo) about eight years ago; I've gotten a lot of good use out of that tech. That doesn't, however, have anything to do with my wish for a more sensible tech order and the ability to research individual items instead of whole nodes at once. I may have to go digging through the mod catalog and see if there's one that breaks up the nodes. Realistic Progression is something I definitely need, though I'd have to restart my career to gain anything from it. Does anyone know of a mod that breaks up the tech nodes? Or would I have to get one that lets me make my own entire tech tree, and go through it item by item?

I'd be very interested in which mod(s) does that. I'm considering installing a parts mod that gives two-Kerbal pods, plus "Realistic Progression" (RP-0); that would be a good time to add single-part tech nodes or partial node research.