maltesh

Looking at my numbers, for the most part, you do get some saving over departing refueled from standard 100km orbit, based on the standard equatorial/circular assumptions. [TABLE=width: 500] [TR] [TD]Destination From Kerbin[/TD] [TD]Optimum Refueling Altitude (km)[/TD] [TD]Ejection Delta-V from Optimum(km/s)[/TD] [TD]Ejection Delta-V from 100 km orbit (km/s)[/TD] [/TR] [TR] [TD]Moho[/TD] [TD]680[/TD] [TD]1.661[/TD] [TD]1.693[/TD] [/TR] [TR] [TD]Eve[/TD] [TD]11309[/TD] [TD]0.551[/TD] [TD]1.012[/TD] [/TR] [TR] [TD]Duna[/TD] [TD]7775[/TD] [TD]0.649[/TD] [TD]1.047[/TD] [/TR] [TR] [TD]Dres[/TD] [TD]1020[/TD] [TD]1.476[/TD] [TD]1.554[/TD] [/TR] [TR] [TD]Jool[/TD] [TD]360[/TD] [TD]1.918[/TD] [TD]1.921[/TD] [/TR] [TR] [TD]Eeloo[/TD] [TD]209[/TD] [TD]2.089[/TD] [TD]2.082[/TD] [/TR] [/TABLE] So the savings are maybe useful when departing for Duna or Eve, however, there are obvious problems with putting a refueling station in a circular orbit over Kerbin at 11,309 km. It's probably not really worth it for the other destinations: the meager savings are chump change in terms of the other burns you're going to have to do. And of course, I've not run the nubers based on going elliptical to a low Kerbin Periapsis from your refueling orbit, then burning at periapsis to eject to your destination. I suspect if I did that, very high Kerbin orbits would be the optimum position for the refueling.

Yeah, here's where things get complicated. From the reference frame of the first ship, both stars are moving relative to it at 0.75c. Which means that, in that ship's reference frame, the distance between the stars experiences length-contraction, and so by the first ship's measurement, the distance between the two stars shrinks from 2 light years down to 1.32 light-years. And so when he fires his light-speed signal, he sees it cross that 1.32 light-years at the speed of light, and reach the other ship at the appropriate time. Edit: Going further, an observer stationary relative to the two stars also measures the radio beam crossing the distance, which is 2 light-years in his reference frame, at the appropriate time: 2 years after it left . However, if he asks the ship about how long it took the light beam to cross the distance between the two stars, the ship will give him a different answer: 1.32 years. Odd, but consistency is maintained (after a fashion) because, relative to the star observer, the spacecraft is moving at 0.75c, and experiencing time dilation. The star observer sees all clocks moving abord the spacecraft ticking at 0.66 ship seconds per star second.

If you're going to completely fill up, and depart straight from a circular orbit (instead of, say, plunging to an atmosphere-scraping orbit that ejects you in the correct direction) then yes, the closer your destination is to Kerbin, the higher the optimum departure altitude winds up being. When I ran the numbers a few weeks back, the results ranged from about 11,000 km for Eve down to about 200 km for Eeloo. There used to be a post that went a lot deeper into the specifics of this sort of thing, by someone else, but the forum implosion ate it.

Basically, both protractor and kerbal alarm clock give countdowns by by assuming that all the planets move in equatorial, circular orbits at constant velocities. Only Kerbin actually does. If you want an alarm that is closer to what Protractor is eventually going to show, you may want to set an alarm that hits a week or two ahead of the prediction, and then set a new alarm that may produce a more accurate number when the alarm hits zero. Is it that big of a deal? My feeling is "Not really," as SkyRender mentions. If you were measuring phase angles by putting an actual plastic protractor on the screen, you'd probably wind up being off by more, and ultimately, the mod is intended to help get you close to your target, the rest is your piloting.

No, they're not physically moving at 150% of the speed of light relative to one another. Length contraction, time dilation, and the fact that the speed of light is constant in all reference frames means that the observer on the planet doesn't measure either spacecraft moving away from him at greater than the speed of light, nor do either spacecraft measure the other moving away at greater than the speed of light.

The two spacecraft don't see each other receding at 150% of lightspeed. When things are moving at an appreciable fraction of light speed, you have to use the relativistic velocity-addition formula. The result is that each of the ships see the other ship receding at 96% of lightspeed.

Once in orbit, any amount of thrust can take you interplanetary, as long as you have sufficient delta-V capability in your fuel storage. Very low thrust can make the trip more complicated to achieve, though. I ran a similar Tugbot and Tanker design to the one you mention in the OP (though with fewer NTRS) to Moho last week. Unfortunately, said design didn't have much fuel after arrival. But that's Moho for you.

Like radial decoupler scabs, strut scabs disappear the next time the craft is loaded.

One of the interesting features of Mechjeb 2 (requiring that you set up a custom window for it) is a Suicide burn Timer, giving you a countdown to the last point where you can save yourself with a full throttle-burn.

Moho's a hard target, and 3.5 km/s of relative velocity on arrival is fairly good, all things told. It sounds like you did fairly well. You want a periapsis as low as possible on arrival, and you /want/ to come in as close to the direction of Moho's travel as you can. Basically, the Delta-V map assumes that Moho is in an equatorial circular orbit whose radius is equal to the semimajor axis of Moho's actual inclined, elliptical orbit, and that you do a perfect Hohmann transfer to this hypothetical object. When you descend on a Hohmann transfer deep into the sun's gravity well, you're arriving much faster than an object running around down there, which results in a high relative velocity on arrival. If you aren't moving in exactly the same direction as Moho when you arrive (because you're not exactly in the same plane, or because you had to cut inside its orbit to catch up with it) that cranks up the relative velocity. If you hit Moho when it's near Apoapsis, it's moving much slower than the circular velocity for its orbit, and that cranks up relative velocity. The delta-V maps are fairly good for many destinations, but you generally need to take them with a fist-sized rock salt crystal with Moho.

Aye, James Clark Maxwell proved that solid rings around a planet are unstable back in 1859. If you don't have some sort of thruster system to push them back into place (Which Niven retroactively added in The Ringworld Engineers), any disturbance that pushes your ring off-center results in it accelerating off-center until it comes into contact with the planet.

I put a protractor on a rover, and drove it far enough away from the pad that launching a craft wouldn't force-delete it. Now, when I want to lanch interplanetary, I load the rover, and use it for 100k time accel until its go time, then either exit to the Space Center and load the interplanetary craft for launching, or switch to the map screen to load an interplanetary craft already in orbit.

That's because Specific Impulse has nothing to do with Kerbin's gravity. When measured in seconds, it's the amount of time that(for example), the amount of fuel that weighs 1 N measured under a standard gravity will produce 1 N of thrust with the specified engine.

Normal and Antinormal are points on the horizon boundary of the Navball equidistant from your prograde and retrograde markers. If your orbit is near equatorial, you can get away with burning directly North (Bearing 0) or South (Bearing 180). However, if your orbit is significantly inclined... Put one velocity marker on the left, the other on the right (or as close as you can make it), then use W and S to pitch up or down until your nose marker crosses the Navball horizon. THen you will be pointed either at Normal or Antinormal. (the other direction is on the opposite side of the Navball)

An incoming object can gravitationally interact on a close pass with a satellite object already in orbit of the planet, and exchange momentum as it swings past the satellite. If enough momentum is lost, the incoming object can wind up captured, and if enough momentum is delivered to the satellite, the satellite may wind up being ejected. There are also weird paths to capture that result from the actual gravitational gradients in a multiple-body system that Kerbal Space Program does not simulate. When considering the Giant Impact Hypothesis, you have a /lot/ of mass being splashed around and interacting with itself gravitationally.

Yes. It's fairy bright when illuminated by the sun before sunrise or after sunset. It's usually brighter than Vega (the fifth-brightest star) when visible, and every so often, gets brighter than Jupiter.

Aye, both mornings and evenings. The program I've been using to scrape Heavens Above has changed quite a bit over the years. Initially, I'd set up a Google Apps Script to do it and automatically create events in my calendar. Later, I built a Yahoo Pipe that would accept an address and produce a subscribable calendar. Unfortunately, the fickle rules of Yahoo Pipes broke it often, so I abandoned that path. Later, I wrote a C# program which, given an address, would fetch the information, create an .ICAL file, and save it to my Dropbox's public folder, and set up a Scheduled Task that would launch it every day at 3AM, and subscribed to the public link in Google Calendar. Unfortunately, earlier this year, Dropbox started using a robots.txt that disallowed Google Calendar from fetching calendars from Dropbox. So now I use the File synching utility Syncbak to launch the C# program, which runs. Then Syncbak FTPs the .ical file to my website, and Google Calendar pulls the .ical file from there. So far, so good.

I'd say the opposite is true for the mid-latitudes. I'm at ~41 degrees North latitude. Been running various programs to scrape Heavens Above and put ISS passes (And Iridium Flares, and Tiangong-1 passes) in my Google Calendar on and off for the past three years. Days on which the ISS is visible (either before sunrise or after sunset. ) are the norm. interspersed among that are scattered days when it isn't visible. Every few months you get a week or two where it isn't visible. Even more rarely, you sometimes get a day or two where it's visible both in the morning and in the evening.

You can use the Muon Detector to pinpoint the locations on Kerbin where the Monoliths lie. The large version is a lot more useful than the small version for this, but is also a lot more unwieldy atop a rover.

The thread Analytically Solving for Gravitationa Parameter and Body Diameter discusses several methods for measuring the radius and mass of celestial bodies in Kerbal Space program using information you can get from the Map Screen. If you just want to know what the reference radius of Duna is, it's 320 km.

Something's wrong with the Physical Characteristics section. VOID lists Kerbin's radius as 600km, which is correct. VOID's Surface area result is 4,523,893 km^2. Aso correct. Volume is listed as 6.97*10^8 km^3. Assuming that same 600-km radius, it should be about 9.05 *10^8 kg. Mass is listed as 5.29 * 10 ^19 kg. It's actually 5.29 * 10^22 kg. I think you're assuming that the game stats are offering the mass in grams, when they're offering it in kilograms. Using the actual mass and volume results in a density of about 58,500 kg/m^3 instead of VOID's 77.98 kg/m^3.

Heck, I Aerobraked from an Escape Trajectory over Duna with a much heavier spacecraft than that, waited until the atmosphere had slowed me down significantly, then popped the chutes (I had only three of the large chutes), and didn't burn the landing engines at all until I was less than a dozen meters up because I thought hitting at 10 m/s might cause damage to the lander. Said lander included three of the 1600-unit tanks and a three-man pod, three aerospikes and an NTR built into it. Far more than enough fuel to rescue my previous Duna pilot from orbit, and return to Kerbin. If you are solely going to count on aerobraking to slow your spacecraft from an interplanetary Trajectory to Duna, coming straight down is probably a bad idea. You'll almost certainly smack into the planet that way. You need a periapsis high enough to miss the mountains, but low enough to shed velocity. I believe I went for about 8-10 km periapsis on the aforementioned descent, but I had a Mechjeb on board for fine-tuning.

If you want to map an entire world without having to change your orbital inclination, put the mapper in a polar orbit, and let it run. There will be overlap; that's completely unavoidable. For some objects, (especially the ones that rotate swiftly) it will require that you keep mapping for several revolutions for full coverage. Mapsat can map at up to 50x time acceleration. Moho rotates slow enough that a polar orbit will get everything in half a revolution (which will take about 12 hours of play time at 50x). When mapping the other bodies in my game though I started with a polar orbit, and let the object rotate underneath for two revolutions or so. I then looked at the latitude of the highest unmapped region, and burned to set my orbital inclination at that value, and did a few more revolutions that way.

Correct! It's not nomming, it's eating.

Up through v 0.11, the sun was a harmless lightpoint. Up through v 0.13 ish, the sun was a lightpoint with its current mass, which you could get arbitrarily close to. It had a reference radius of about 65,400 km. Up through v 0.16-ish, the sun was a lightpoint surrounded by an invisible surface that you would impact at about 4500km over its reference radius. In v0.17, the sun has a visible surface with a significantly larger radius than previous versions (About 216,000 km, if I recall correctly). I've flown spacecraft as close as 13km to that surface. I've been told, but have not personally confirmed, that about 150 m above that surface, parts of your ship will overheat and explode.