maltesh

To get around to answering this quesiton: Step 1: BACK UP YOUR SAVE FILE, BY copying it to elsewhere on your hard drive. Failure to back up the save file will make it somewhere between difficult and impossible to fix things later if you screw things up. Build your Marker Object in the VAB, and move it to the Launchpad. Scott Manley has a tutorial on Persistence file editing here: THe basics are: Hit F5 to Quicksave. Open the quicksave.sfs file in a text Editor such as notepad (but not Wordpad) Find the your marker object's Vessel information in the persistence file. Within it will be the following attributes: sit = LANDED landed = True landedAt = LaunchPad And you'll want to change them to sit = ORBITING landed = False landedAt = Which will make KSP ignore the surface information about the spacecraft and pay attention to the orbital information. Now you've got to modify the Orbit info to put it in the appropriate place. In Kerbal Space Program, the Mun's orbit, and its position along it is defined by the following orbital Parameters (Converted to the Persistence File's Vessel format for clarity) ORBIT { SMA = 12000000 ECC = 0.0 INC = 0.0 LPE = 0.0 LAN = 0 MNA = 0.9 EPH = 0 REF = 1 OBJ = 0 } Since the Mun is a special case, with a circular orbit, and apparently the desired distance from its center is 3100 km. If the distance you want to place the marker object at is 3100km measured along the Mun's circular orbit, the calculation is fairly simple. The Mun mover along its orbit at 542.5 m/s. It takes an object moving at that speed 5714.28571 seconds to cover 3100 km. So if you place an object on the Mun's orbit with the same Mean Anomaly at Epoch (MNA) such that its Epoch (EPH) is 5714.28571 seconds later, it will be 3100km behind the Mun. ORBIT { SMA = 12000000 ECC = 0.0 INC = 0.0 LPE = 0.0 LAN = 0 MNA = 0.9 EPH = 5714.28571 REF = 1 OBJ = 0 } Similarly if you set EPH = -5714.28571 , it will be 3100km ahead of the Mun. Note that the reason this particular edit works is because the Mun is in a circular orbit; There is no orbital position that maintains a fixed distance from a non-gravitating object in a non-circular Keplerian orbit. Once you've adjusted the approapriate information, save the modified quicksave.sfs file, go back to the game, and hit F9. Your marker object will be now teleported to a position on the Mun's orbit, 3100km away from the Mun, measured along its orbit, as requested. You may now launch a real mission to rendezvous with the Marker Object, and delete the Marker Object when it gets there. So yeah, that's basically how I'd do it. Hyperedit has a similar facility to teleport things off the pad, but I've not made use of it, so I don't know if it lets you modify your orbit's epoch. But if you have known, specific set of Keplerian orbital parameters that you want to guide a spacecraft to (such as what I had when setting up my Tetrahedral Configuration Challenge), I find the process fairly useful.

Thread is ancient. That said, the AR202 radial attachment part that has been with Mechjeb since the 0.15-era is nearly massless, at 0.00001 mass units.

Aerobraking results in bring your spacecraft's velocity around the sun /closer/ to the velocity of the object you're braking against. When a spacecraft going from Kerbin to , say, Duna aerobrakes in Duna's atmosphere, the spacecraft's sun-relative velocity is /increased/ by the atmospheric friction.

Photos of the Apollo 11 landing site, taken by the Lunar Reconnaisance Orbiter in 2012. http://www.nasa.gov/mission_pages/LRO/news/apollo-11.html

If solid- or liquid-fuel rocket thrust from your engines hit something that's part of your spacecraft, that thrust is nullified. You should build so that exhaust of the engines of the skycrane do not hit the attached flat panel. RCS thrusters and Ion Drives have no issue with their exhausts being blocked currently.

In the simulation of Kerbal Space program, 1 Force unit of thrust / 1 Mass unit = 1 m/s2 of acceleration. The general convention is to assume that the force units of thrust are kilonewtons, and the mass units are metric tons.

About 8 months, between July 2011 and March 2012.

I had one with a blue face and feet that granted wishes.

To the best of my knowledge, no, there's no stock capability mod that allows you to target a user-specified position on an orbit where no object currently is. My general tactic has been to teleport a marker object into the position I'm aiming for by editing the persistence file, and then rendezvous with the marker object for the real mission.

That sounds about right. A plane-change of 90 degrees costs about 1.414x your current orbital velocity. In general, for plane changes over about 55° it's more cost-effective to burn to push your apoapsis out to near the edge of the SOI, do the plane change there, then return and recircularize. That tends to max out at about 0.85x of your current orbital velocity. Personally, I'd porbably just leave the mapper where it is and launch other probes based on its design to head to interplanetary destinations.

I got the same answer when I ran the numbers awhile back. a plane-change to reach minmus at about 30,000 km tended to max out at about 85 m/s, and was generally significantly cheaper. And besides, all the cool kids use CONIC_PATCH_DRAW_MODE = 0 in the settings.cfg, which makes it easy to see exactly what your path will be around Minmus when you get there, and lets you tweak it effectively with maneuver nodes far outside the SOI. All told, if you're already in orbit, it probably would be cheapest to combine your plane change and the transfer burn into a single burn, but KSP isn't very accommodating for that sort of thing.

Ah, didn't answer this question. With regards to this, you just need to adjust the semimajor axis of the configuration to get the periapsis high enough over the surface. I haven't gone back to revisim my orignal calclation and went for round numbers just above the limit for Kerbin. The resulting altitude scales with radius, though, so, using my Kerbin Numbers... For body X with radius r, the semimajor axis of the Draim Tetrahedral Configuration orbits needs to be at least 7.25*r. Also, congrats to Mesklin, who's become the first person to submit a completion (now linked in the original post), though he hasn't yet posted his completion in the thread. Hopefully soon?

Done. Both satellites are in circular orbits around Kerbin, with radius 47 000 km, and maneuver nodes are placed by hand to push solar periapse down to 500 000 km. Spacecraft Prograde (inclination 0°): Delta-V on Maneuver Node: 5988.7 m/s. http://i.imgur.com/gRIWPhi.png http://i.imgur.com/sBU1c16.png Spacecraft Retrograde (inclination 180°): Delta-V on maneuver node: 6040.7 m/s. http://i.imgur.com/T5ZqA1Y.png Delta-V requirement on the retrograde-orbiting craft is higher by roughly 60 m/s, and then there's the extra delta v to get into the retrograde orbit in the first place. I suspect that, in your test, you placed the maneuver node for the prograde craft in a suboptimal location. (Edited to fix screenshots; should have labeled the bloody things)

This was my first Munlander. It was v0.12, and I'd had pretty much no experience landing spacecraft. Given that flying to the Mun took 15-30 minutes, I decided to do things backwards, and learn how to land before I learned how to build a normal craft that could fly there. I threw together a trainer craft to get some practice. The reason why the bottom of the fuel tank is blue, is to distinguish it from the stock fuel tank, which did not contain five million units of fuel. After I got the hang of landing and returning, I built a zero-fuel-consumption craft that could put a normal (though not stock, as landing legs and small engines didn't arrive until 0.14) lander on the mun, and got used to landing on a fuel budget. After I got the hang of that, I built a zero-fuel-consumption craft that could put a normal transfer craft and lander into LKO, got used to flying that to the Mun, and returning. And after that, I put together a spacecraft that could fly to the Mun, land, and return, without using zero-consumption parts or nigh-infinite tanks. That was probably some variation of this craft. Then 0.13 came around and brought fuel lines, and my design priorties changed. And then 0.14.2 brought lander legs, and the ancestor of the LV-909. And Klopchuk's thread taught me about Asparagus staging. I had designs that could have Munlanded stock then, but because I thought a set of fins I'd been using to spread out my lander's footprint were stock instead of being Nova-Punch, it turned out that I didn't do a completely stock Munlanding until 0.15.

Actually, Longitude of Periapsis and Longitude of the Ascending Node are not surface-relative coordinates. They're celestial-relative coordinates; that is, relative to the fixed celestial sphere. Image by Wikipedia User Lasunncty, CC-BY-SA-3.0-MIGRATED; Licensed under the GFDL by the author; Released under the GNU Free Documentation License. In the case of the Kerbin System, the reference plane (analagous to Earth's ecliptic plane), is the plane in which Kerbin orbits. In the kerbin System, if you were to draw a line from Kerbin through the sun at UT=0.0. the Reference Direction would be a little counterclockwise of that direction. (I don't think the Kerbin System has any obvious feature on the skybox that points in the Refeerence direction.) If you were to place a plane that passed through the center of Kerbin parallel to the Reference Plane (Since it's kerbin, this would be the reference plane,), the Ascending Node would be the point at which your orbit passes through the reference plane headed in the Northward direction. The Longitude of the Ascending Node is the angle, measured counterclockwise in that plane, between the Reference Direction and your orbit's Ascending Node. Argument of Periapsis (Which is what I should have written, instead of Longitude, and will go back and change it), is the angle between your orbit's Ascending Node and your orbit's periapsis, measured counterclockwise in the plane of your orbit. KSP's persistent.sfs files use the abbreviation "LPE" for Argument of Periapsis. As for "How do I get into an orbit that has those parameters?", I don't really have a good answer for you. The stock game doesn't really give you good information for that. Really, there needs to be some kind of targeting capability that lets you enter orbital parameters and gives you a target box you can aim for when rendezvousing. A longer discussion of the orbital parameters can be found in my signature.

Heck, until v0.10, we couldn't hit "M" and look at our apoapsis and periapsis values either, but the navball,speedometer, altimeter, and mission clock (assuming you know the mass and radius of Kerbin) provide enough information for you to calculate them.

The reason the Molniya goes for half a sidereal day is to keep the ground track stable over the high-latitude region you want to service. Since the period is an integer fraction of the fraction of the sidereal day, the path of the satellite across the rotating surface always remains the same, and spends large amonunts of time over the region http://en.wikipedia.org/wiki/File:Molniya.jpg An actual Molniya constellation uses three satellites in three arrayed Molniya orbits, phased so they reach apoapasis a third of a day apart, and arrayed with the longitudes of their ascending nodes 120 degrees apart from one another, which results in the satellites being visually near each other from the ground viewpoint when the time comes to handoff from one satellite to the next as the planet rotates.

Keep in mind, though, that aerobraking at Eve brings your velocity closer to that of Eve. It does not necessarily reduce your sun-relative velocity. Passing through the atmosphere of a massless Eve on the way deeper into the sun's gravity well would tend to raise your spacecraft's solar periapsis, not lower it. (Eve, of course, is not massless, and its own gravitational effects would significant things to say about your trajectory.)

You seem to be conflating the Mean Anomaly, the Eccentric Anomaly, and the True Anomaly. The three are equivalent if your orbit is circular, if your orbit is elliptical, they are only equivalent at periapse (where all three are 0), and apoapse (when all three are equal to pi)

To get continuous coverage over a spherical surface, including both poles, with only four satellites, you can use John Draim's Tetrahedral Satellite Configuration.. It uses four satellites arrayed in four separate elliptical orbits (eccentricity =0.28), inlcined at 33° and arrayed so that they maintain a tetrahedral framework around the planet. But that's really more of a commsat setup than a GPS setup. My signature contains a challenge that involves setting up such a configuration over Kerbin.

See the Centaurs.

An unorthodox method: (BACK UP YOUR PERSISTENCE FILE IF YOU'RE GOING TO DO THIS). Build any object, and place it on the launch pad. Call it "Target" or something. Exit to space center. Open your persistence file with a text editor, such as notepad (but not wordpad.) (SERIOUSLY, BACK UP YOUR PERSISTENCE FILE BEFORE PROCEEDING.) Find the Target object. Find the line sit = LANDED and change it to sit = ORBITING Change landed = True to landed = False Change landedAt = KSC and change it to landedAt = Make sure splashed = False In the ORBIT section, make the following changes: SMA = 3468751.0 ECC = 0.0 INC = 0.0 Leave the rest of the orbit parameters the same. Save. When next the persistence file is loaded, the Target will be in a synchronous orbit over Kerbin above KSC (or close enough to not matter, because KSC is not /exactly/ on Kerbin's equator). If you screwed something up, exit back to the space center, and restore your persistence file from the Backup. You now have a Target. Now build your real satellite deployment craft, and fly it to rendezvous with the target. Kill relative velocity. Deploy your satellite. Delete the target.

The Mun's SOI is close, and relatively large. Minmus is also fairly closeby. Navigation from Kerbin to reach either is fairly easily doable with ye olde "Munrise burn" technique. With interplanetary destinations, their spheres of influence are /tiny/ compared to their orbital distances, they're moving around the sun in their own orbits, that are both inclined and eccentric, and hunting down the locations that the worlds will be at when you cross their orbits is kind of tricky /with/ maneuver nodes, and was even more difficult without maneuver nodes back in 0.17. Most of the tools used for interplanetary travel date from around that time, and while most of them use simplified calculations to help you find launch windows, they're extremely useful for that sort of thing. Not using a Hohmann transfer launch window can cost you quite a bit in delta-V to chase down your target, or (if you really don't know what you're doing) can mean you spend /years/ of K-Time searching for the SOI of your target world.

The question is: What are you trying to simulate? Are you ultimately headed for multi-body simulation, where every body gravitationally interacts with every other one? Or do you want to just put non-gravitating satellites in the gravitational field of the primary body, generate the Keplerian orbit that is defined by their initial position and velocity,and work out their positions as a function of time based on that orbit? The former gets somewhat complicated for long-term accuracy. The latter is mostly straightforward.

Without seeing the rest of your code, it's going to be pretty much impossible to diagnose. That said, you aren't going to get an absolutely perfect ellipse using the method you detailed, even if you implement everything correctly. The smaller your timestep, the closer the resulting path will be to a approximating a Keplerian orbit, but the step-and-calculate method is always going to result in shifting of the orbit over time.