maltesh

Fun fact: There were initial plans to guide Pioneer 11 through the Cassini Division. They were decided against on the (later-confirmed) basis that there might be sufficient debris in there to damage the spacecraft. WHen Cassini passed through saturn's rings, they took it through the much sparser area between the F and G rings.

Generally, when it happens, it's because something's triggered that looks like possibly suspicious behavior on the account. Perhaps the user is suddenly logging in at an IP that registers as being a significant geographic distance from typical login locations. Perhaps, through trickery, malware, or because the user was using the same password on other, less secure sites, someone /did/ get into the user's account and began using it for nefarious purposes. Perhaps the user is attempting to log in from a location where such things happen more frequently. There's a balance between security and convenience that winds up getting struck, and it's always extremely annoying when you wind up on the wrong side of that balance.

If you can get within 300km, that's more than close enough on a solar orbit. Remember that you can flick the navball over to target-relative velocity at any time by clicking on it as long as you have a target selected; you don't have to wait for it to autoswitch. From there, it's a matter of using your main engine to push the relative velocity indicator onto the target-direction indicator, with adjustments to keep it there until you finally close the distance. That said, bringing back a capsule using grappling legs from solar orbit is going to be pretty difficult. Since you won't be docked to your target, it will be considered a separate vessel, and every time you use time acceleration or switch to a distant vessel, the game will recalculate its position based on its then-current velocity converted to Keplerian elements, which will result in it escaping from your cage and moving significant distances away from your spacecraft. Unless you're willing to spend time re-rendezvousing with your rescued pod on the way back, (or worse, do the entire trip in Physwarp) you should probably either look into using Kerbal Attachment System to dock and tow back your pod, or settle for just rescuing the Kerbals.

The kill line is at about 21-22km over Kerbin. One of the things I used to do in every save was to edit an Impossisat into a stable 25 km altitude circular orbit, just to see its icon dart by KSC at 2.3 km/s every thirty minutes or so.

In the time before time, when there was no map screen, and no time acceleration, when the only world was the single, non-rotating planet of Kerbin, the most basic way to tell whether or not you'd made it into orbit without using third-party tools or performing mathematical calculations on the UI information was to wait to see if your periapse was above the atmosphere. A low Kerbin Orbit is completable in about 30-35 minutes, requiring a velocity of about 2.25km/s. A low Earth Orbit would be completed in about 90 minutes, and require an orbital velocity of about 7km/s. For the players of those ancient versions, the former was somewhat more forgiving. There is currently a mod in development that increases Kerbin's radius and mass appropriately to put it at Earth Size. http://forum.kerbalspaceprogram.com/threads/55145-0-22-WIP-Alpha-Real-Solar-System-%28Kerbin-Earth-rescale-etc%29-v2-1 Scott Manley did a video on it, which can be found here.

Mechjeb's "Closest Approach to Target" and "Time to closest approach" readouts are significantly more accurate than the in-game versions. As a result, my most commonly-used window in Mechjeb is a custom "Zee Rendezvous Info" window (So named so it autosorts to the bottom of the panel.) "Zee Rendezvous Info" contains Distance to Target, Relative Velocity, Total Vacuum Delta-V, Max Acceleration, Time to Closest Approach, Closest Approach Distance, and Relative Velocity at Closest Approach lines. Makes it a /lot/ easier to fly the navball on a rendezvous. My other most common window is "Maneuver Node Info", because I have gotten used to the in-game burn timer either lying to me, or forgetting how long a scheduled burn is going to be because I switched to another vessel since the last burn. If I did more Aerobraking, I'd certainly use the "Landing Guidance" window more often, as its aerobrake caclulations are almost invariably spot-on. And when I really do need to set something down on top of a flag, I use Landing Guidance then as well. I also use the Ascent Autopilot quite a bit as well. I know some players find every manual ascent exciting. After having done several hundred, the luster's a bit lacking for me. Personally, I significantly prefer the part of the game above Kerbin's atmosphere.

A sufficiently-long object, left to orbit in reality would eventually wind up radially oriented due to tidal effect, yes. That said, possibly because people rarely did build things long enough to make the effect noticeable, and even more rarely did they leave physics enabled for the hours to days it would take to happen, KSP stopped simulating differential gravity for the individual parts of a spacecraft back in 0.11. In KSP as it is now, all parts of a particular spacecraft behave as if feel the exact same gravitational attraction in the exact same direction, regardless of the size of the spacecraft. As a result KSP Vessels experience no tides, and cannot make use of gravity gradient stabilization by themselves. I've done some basic experimenting with a 300m-long chain of KAS-attached craft that /seemed/ to attempt to orient itself radially after several hours in orbit, but the fact that any spacecraft chain set up so would come apart when put on rails makes the experiment of extremely limited utility in actual play. Especially since the tidal forces on that 300m craft in LKO wound up being pretty darned small.

Protractor will give you an angle that decreases to zero when the worlds are near the appropriate configuration for a Hohmann transfer. It will also give you closest-approach information that's more accurate than the in-game version, and let you know the orbital inclination of your arrival trajectory. Kerbal Alarm Clock allows you to set a host of different ridiculously-useful, save-spanning alarms that make it one of the mods I would consider absolutely essential, doubly so if you ever decide that having more than one mission running in a single save at one time. One of its options is setting alarms for Transfer Windows.

For what it's worth, the surface gravity of the KSP sun is "only" 1.75 gees. Surface gravity dropped considerably when the sun went from roughly 65,000 km in radius in 0.17 to 216,000km in radius in 0.18, while keeping the same mass. Orbital velocity near the surface, on the other hand, is more like 67 km/s. And true, a spacecraft capable of 67 km/s delta-V with more than 1.75 gees thrust would be a sight to see, if the game didn't typically destroy by overheating anything that got closer than about 1.2 km to the solar surface (Or at least, that was the threshold back in 0.21).

For the most part, I don't ship Kethane. 99% of what my spacecraft need is Fuel and Oxidizer. The vast majority of my dockings use less than 15 units of monoprop. The only ion drive spacecraft I use, I consider one-way probes, or toys. As a result, I tend to refine on the surface, and ship fuel and oxidizer to orbit. Kethane patches are huge, and if I decide it needs to be stored, I usually leave it in the ground. Invaluable to my setup were two mods: Kerbal Attachment System (To allow Kerbals to connect the various spacecraft together) TAC Fuel Balancer (To automatically pump fuel and oxidizer from one part of a spacecraft to another, and back) This was the basic setup I wound up running over the Mun in 0.21. In the Left foreground, the Wellhead. Left in place on the Mun, it used three large drills, and a single large converter, powered by three Kethane reactors to mine and refine Kethane. Kerbals stationed in a Habshack nearby used one of its three KAS Winches to attach to the Citrus-Class Spheretanker, shown in the background, whose spherical tank holds appoximately 3/4 the voulme of a Rockomax Jumbo-64. Also shown: A flag being used in the capacity of "low-profile, self-sustaining targetable beacon," as per Galane's musing in the original post. If you are not going to be using them in that capacity, it can be helpful to remember that if you divide the radius of the world you're landing on by 200 km, the result is very nearly the linear distance in meters of one second of arc Latitude. e.g, 0°0'10" North of target on the Munar surface is approximately 10m North of the target. The Citrus-class Spheretanker uses paired LV-Ns as its landing and drive engines; as a result, it typically only used about 1/7 of its capacity to go from the munar surface to a 50 kilometer altitude orbit for rendezvous with the Depotsphere, as shown above. The particular depotsphere in the image holds about 6 Rockomax Jumbo-64's worth of fuel when filled. I never even came close to emptying the monoprop tanks it had. The Ultimate setup I wound up using over Minmus was different, primarily because I got tired of needing to make nine trips to fill a depotphere, and I had decided to send two depotspheres as part of the 20-ship Dunar fleet. Minmus' significantly lower gravity, and having to get twenty other spacecraft ready before the window made me decide to go with the "Ship Kethane" option. It is hard to tell from this viewpoint, but the Minmal Sphereminer has four Rockomax-16 fuel tanks clipped into its sides, which, if I recall correctly, turned out to be something like 4-8 times the fuel capacity it actually needed to perform its mission. It used four small drills powered by a single Kethane reactor to fill its 96,000 unit spherical tank Kethane capacity, after which it used its four LV-Ns to return to orbit. Once in orbit, it would dock with the nuclear-powered refining station, and fill up the storage depotsphere with refined fuel and oxidizer. I would later ship other depotspheres to Minmus, fill them up from this facility, and send two of them to Duna, and one to Eve.

Correct. Given how ancient this thread is however, someone should probably just come out and state the rule and end it, so it's not dragged-out, it's concluded.

There isn't one. The line you're attempting to draw is between "Ways the game can be played" and "Ways that the game can be played that you decided are acceptable."

It isn't bending the rules. It's playing the game as it currently exists. The title of the thread is "Optimal ways to gain science discussion." If, as seems likely, the benefits of beaming back all the science are going to change in future updates, then the optimal way to gain science may change. If the methods presented conflict with the way you wish to play the game, don't use them.

Kerbin's moons are small, light, and moving perpendicular to the direction you ultimately want to head, and the game doesn't have a good interface for pre-planning trajectories. As a result, it is very, very, very easy to spend more delta-V setting up and aiming your Munar gravity assist than the small amount it could potentially save you over a direct burn from LKO. If your destination is within the Kerbin SOI, or very near the orbit of Kerbin, and you've done the math and planning beforehand, and your fuel budget margins are razor-thin, a gravitational assist by the Mun may be worth it. For the typical interplanetary destination, it is probably not worth the extra hassle.

It doesn't really matter whether you beam first or capsule first. The total you can extract will remain the same. You can beamspam down to 0.0 if you so desire. There may very well be some fractional bit you can't scrape out by repeated beamspamming that doesn't show up in the resolution of the UI, or you may just get tired of repeating before you beamspam out everything. The amount of science available in a location is like an open-topped keg. Bringing back an experiment is like a large pitcher that you can put under the tap of the Keg, but you have to leave after you fill it. If the amount of science left in the keg is less than the volume of the pitcher, you'll get it all. Beaming back is like scooping out of the top of the keg, using a spoon with a hole in it, into as many cups as you want. It takes longer, and some of what you spoon out won't wind up in the cups, but what drains out of the spoon falls back into the keg, it doesn't splash on the floor.

If you have the power and the time for it, beaming back science through antennas is the way to go. There is typically more science available to any experiment type at any one location than a single return can deliver, and, as mentioned upthread, you do not lose any of the total science gainable at a location by beaming it back. In general, as far as total science gainable from a location: Beamspam + Return > Beamspam > Single-experiment return. Some otheer weirdness. Kerbals in an External Seat can make EVA Reports, and because they're attatched to the vehicle, can immediately beam them back if transmission capacity is available. If the vehicle is landed, they can also take surface samples and immediately beam those back. No in-and-out shuffle with a pod required. Crew pods do not have to have a Kerbal inside them to do a Crew Report. Haven't checked to see if the requirement is that there be a Kerbal somewhere in the vehicle to get a Crew report, or if an unmanned, empty vehicle with a pod can do a crew report. The 2-man landercan has 200% efficiency when beaming back Crew Reports. Yes, you read that correctly. You can get up to twice the science value of a Crew Report by beaming it back from a two-man landercan (Assuming the location has sufficient remaining Crew Report Science for you to do so.) in a single, normal-size transmission. This is probably a bug, the 3-man pod and the hitchhiker do not work that way.

Use the radial-mounted parachute to balance, if necessary, but attach the module with a decoupler or docking port, and disconnect it to handle its own landing when the chutes pop.

Well, as I recall, when the scale was being made, that 1:1:1 solution was an easy laboratory method to make a consistent, cold temperature. Subsequently pinning the freezing point of water at 32 degrees makes the gradiations easy to mark, because 32 = 2^5 power, so you bisect the distance along your thermometer between those two pinned points five times, and you've got a length that will match up to 1 Fahrenheit degree of temperature on your homemade thermometer, and you can start scribing the lines on. Take that 32-degree length, measure it out twice more, and 32 + 64 = 96, which is where Fahrenheit pinned human body temperature. It is the 17th century. It's going to be some time before you can go to the store and buy a thermometer.

As per the Version history, since Kerbal Alarm Clock version 1.3.2.

When the change was made in 0.21, the answer was "backwards compatibility with 0.20-era craft." Also, the EAS-1 External Command Seat doesn't have torque or onboard computer, though spacecraft built with the seat that can't get what they need from probe pods are probably rare.

Two points: 1. The Cubic Octagonal Strut supports fuel crossfeed, as a result, you don't need the fuel line; the Rockomax Mainsail will be able to pull fuel through the COS just fine. 2. You can actually get away with as few as two bracing struts. I suspect you can get away with one bracing strut, but I haven't tested that few.

I would never have considered flying a twenty-spacecraft fleet to Duna without this mod. It was invaluable in setting up SOI Escorts, saving mid-course corrections, and setting reminders for all the maneuvers necessary to get twenty spacecraft into their desired orbits around Duna and Ike. That said, having done so, I probably wouldn't do it again. Managing 20 spacecraft is a lot ofwork. Two things I noticed: I let Kerbal Alarm Clock autogenerate the SOI -crossing alarm, autopausing one minute before the boundary of the Dunar SOI. Every time I hit that alarm and the game paused, KAC would immediately autogenerate and set off a second one-minute alarm to the SOI boundary. After clearing the second alarm, things would proceed as normal. It would be really nice of you could restore a maneuver node longer than one minute after passing its alotted time. When the saved maneuver node is a course-correction to intercept the Mun or Minmus, missing it by several minutes isn't much of an issue. A burn of the same amount will still do almost exactly what you want it to do. On interplanetary flights, being late on the burn by hours, possibly days, might not be particularly problematic. The former tends to be more common than the latter. When assembling some of my Earlier Minmus and Munar Stations, I tended to find myself in situations where my choices were: A) Complete this docking in 3+1 minutes, Leave the docking undone and switch to the spacecraft whose burn is scheduled, or C)Complete the docking, then switch and plot a new maneuver node for the other ship.

A really, really useful thing to do is to open up the games settings.cfg file, and find the line that says CONIC_PATCH_DRAW_MODE = 3 And change it to say CONIC_PATCH_DRAW_MODE = 0 When you do this, instead of getting weird squiggly lines of dubious value when your future path passes through a world's SOI, the patch will be drawn in the frame of reference of the object (So it looks like a normal hyperbola) and at the current position of the object (So you can hit Tab a few times and center on it for a really close view.) The result being that, weeks or months before you reach your destination, you can pop a maneuver node a few hours ahead of your ship, run your time accel up to 5x so things stop jumping around, center the map screen on your destination, and spend a few minutes finessing the maneuver node that will move your periapse and arrival trajectory close to where you want them, and spend maybe a 10-15 m/s of delta-V doing it. It also makes it a hell of a lot easier to plot circularization nodes inside the SOI before you reach it, if that's something you want to do. If you use Mechjeb, the Maneuver Node editor allows you to change CONIC_PATCH_DRAW_MODE in-game, and there are a couple other mods that do the same thing, but personally, I change it in the settings.cfg as soon as I install a new version, as I have no use for any other mode than Mode 0.

Watching the analemma of the sun in 0.17 Moho was kind of nifty. Back on topic: I found out that time passes on the Space Center screen, when one night, I left the game on the space center screen and came back in the morning to discover that a spacecraft I'd been planning to take to Minmus had missed its capture burn and had escaped the moon's sphere of influence.

In KSP as-is, when your target is a spacecraft, the game will give you relative velocity information (including the direction and magnitude) which makes maneuvering to rendezvous a lot easier, and you can trigger this at any time by clicking on the navball. When your target is a Celestial body, you get no relative-velocity information when you switch the navball to Target mode, and the speedometer always reads 0 m/s. This would give the player a better idea of the arrival velocity, and would really help when navigating to certain bodies that are kind of difficult to chase down with maneuver nodes, namely these guys. Moho and Gilly have pretty small SOIs relative to their semimajor axes, and closing on them would be a bit easier with relative velocity information, as you'd be able to pull off the same kind of navball-guided manipulation on the relative velocity vector that you can do when rendezvousing with a spacecraft.