PakledHostage

A solar day is what we colloquially call a "day". It is the length of time between high noon (transit) on two successive days. On Earth, the length of the solar day varies by ± a few seconds throughout the year because the Earth's orbit is elliptical and because the Earth’s axis of rotation is tilted relative to its orbital plane. Our mean solar day is 24 hours long, while the Earth's rotational period (sidereal day) is 23 hours, 56 minutes and 4 (and a bit) seconds long. During the 23 hours, 56 minutes and 4 seconds that it takes the Earth to spin around once, it also moves about 1 degree along its orbit about the Sun. Ref: Durham University's Solar Days and Sidereal Days page Kerbin's solar day is 6 hours and 50.8 seconds long, while its sidereal day (rotational period) is 6 hours long. You can prove this to yourself by watching successive Kerbol rises from the launch pad. The amount of time between Kerbol rises, as viewed from the pad is 6 hours and 50.8 seconds. As mentioned above, the length of the solar day varies by ± a few seconds throughout the year because our orbit about the Sun is elliptical and because the Earth’s axis of rotation is tilted relative to our orbital plane. We reach perihelion in early January and aphelion in early July. The elliptical orbit causes a variation in angular speed throughout the year. That variation in angular speed, in part, causes the Sun to drift east-west in the sky. (The Sun's east-west motion is also partially due to a complex geometric effect of the Earth's axial tilt). In addition to the east-west motion, the Earth's axial tilt also causes the Sun to appear to move north-south in the sky during the year. The combined effect of the Earth’s axial tilt and elliptical orbit results in the analemma. Here's a famous photo showing the Sun's analemma, taken by Dennis di Cicco: Kerbin does not have an axial tilt and its orbit is circular, so the length of its solar day does not vary throughout the year. I don’t actually know. I suspect that the GPS satellite’s orbits were chosen for practical engineering reasons, rather than any physical reason. If anyone does know (and better yet, can provide a reference) please let us know. The Wikipedia Global Positioning System article says that the orbital period was chosen because it results in every satellite following a consistent ground track and being visible from any point on the Earth at least twice a day. This is important because every satellite’s orbit must constantly be characterised via measurements from a limited number of ground stations to allow the system to maintain any degree of precision. The FAA has a good website that describes how the GPS system works, including a page that describes how the GPS control segment tracks and maintains the accuracy of the satellite position information. The SV position information is downlinked via the GPS signal and is used by your GPS receiver when calculating position fixes. The Wikipedia article also says that each satellite makes two complete orbits each sidereal day, rather than each solar day. This contradicts what I have read elsewhere, but it makes sense when I think about it in the context of the above paragraph. Exact spacing doesn’t seem to matter very much. What matters is that at least 4 satellites are visible from any location at any time. @elkar: I am glad to read that you were able to construct a working GPS constellation. Hopefully you had fun doing it. Thanks for sharing that the ISA map mod includes a navigation feature. Presumably that mod implements some advanced technology that exceeds our own? I am not aware of any automated navigation technology that uses a map of a celestial body to determine position. Presumably it would utilise some sort of image recognition to correlate what the system "sees" with a map? That makes the ISA map mod different than this mod. This GPS mod allows players to implement and learn something about an existing real-world technology, rather than to implement some futuristic and yet to be invented system.

@frozenbacon: That's awesome! You've got a couple of very tidy constellations. Glad to hear that you're enjoying the mod. I will think about how to implement an arrow display but I am a quite busy this spring with life outside of KSP and may not get it done for some time. In the mean time, the nav-ball together with the UI's destination window should work. The heading displayed in the destination window is the heading from your current location to the waypoint, along a great circle. The heading will change as you fly towards your coordinate, but if you track the displayed heading, you will be following the shortest route.

In this mod's old forum thread, TheSec asked a good question about how I spaced my satellites out in the PEZ-C video above. This was my answer: Trying to be as brief as possible, I'll do this in point form: 1. I used a 1588 km circular orbit for my satellites because that gives them an orbital period of 1/2 Kerbin's solar day. Kerbin's solar day (not to be confused with its period of rotation) is 6 hours and 50.8 seconds long. 2. The 1088 km x 1588 km transfer orbit has an orbital period 5/6 as long as the 1588 km circular orbit. A spacecraft in the transfer orbit will make 6 orbits for every 5 orbits that a satellite in the 1588 km circular orbit makes. 3. Imagine that two satellites start in the same place, one in a 1088 km x 1588 km transfer orbit and the other in a 1588 km circular orbit. After 1 orbit, the satellite in the transfer orbit will be 1/6 of an orbit further ahead of a satellite in the circular orbit. After 2 orbits, it will be 2/6 of an orbit further ahead. After 5 orbits, it will be 5/6 orbits further ahead. It will meet up again after 6 orbits. 1/6 of an orbit is 60°. 4. The delta-V requirements to transition from the 1088 km x 1588 km transfer orbit into the 1588 km circular service orbit are given by equation (3) below (it may look daunting, but it is really just "plug and chug"... plug the numbers into the formula and chug through the calculation): Note: The terms G M in the equation above are often combined into a single standard gravitational parameter (µ). For Kerbin, µ = 3.530394E+12 m^3/sec^2

Figaro Global Navigation Satellite System What if Kerbals couldn’t just reach into the fabric of their universe to determine their position? What if, like us, they needed to develop technology to measure their position with any certainty? The Kerbal Space Program forum’s “KARPA GPS Challenge†thread gave me the idea to develop an actual working GPS plugin for the game. The result is a plugin that works the same way that the real global navigation satellite systems do! It calculates your vessel’s position by measuring distance to GPS satellites in known positions in orbit. Now you can Launch your own Global Navigation Satellite System (GNSS) constellation, and then start using your own working GPS network by adding the GPS receiver module to any part in your spacecraft! INSTALLATION Download the module from Curse.com The download file contains three folders. The two important ones are: Parts – Contains the FigaroReceiver directory. The FigaroReceiver directory contains the receiver part. Copy this directory to your KSP\Parts\ directory. Plugins – Contains the KerblGPS module (KerbalGPS.dll). Copy this file into your KSP\Plugins\ directory. The “Sources†folder is included per the KSP add-on module distribution policy. Most users can ignore the contents of this directory. It can safely be deleted. HOW TO USE Launch a constellation of satellites. They should be well distributed around the globe. Ideally, there should be a minimum of four satellites visible from any point on the entire surface of Kerbin at all times. The higher you place your satellites in orbit, the fewer satellites you'll need to launch and maintain. Each of the satellites in your GNSS constellation must have a GNSS transmitter part installed or they won't be detected by the Figaro receiver. Mount the transmitter part on single purpose, or on multi-purpose satellites. Add the Figaro GNSS receiver part to your spacecraft to start navigating using your GPS network. ACKNOWLEDGEMENTS Special thanks to MrPwner for providing the Figaro Receiver and Figaro Transmitter part’s 3D models. His artwork greatly improves the aesthetics and user friendliness of this mod. Special thanks as well to m4v for his help troubleshooting and beta testing version 1.0.22.01 of the mod. QUESTIONS & ANSWERS Q: Does version 1.0.23.01 of the plugin work with v1.0 of the game? A: Reports from users are that it does work in v1.0 of the game. If you encounter a problem with this mod in v1.0 of the game however, please post a detailed description of the issue you've encountered in this thread. I read this thread regularly and will investigate. Q: Do you plan to add support for contracts? A: Yes. My goal is to eventually develop a contract class for the plugin. Some users have already made suggestions, on page 18 of this thread, as to what the contract's requirements should be. Feel free to add more. Q: Can I use/display the latitude and longitude data calculated by my Figaro Receiver in other mods? A: The short answer is: Only if the other mod's developer implements it in their mod. The plugin exposes Lat, Lon, number of visible satellites and DOP for other plugins to access. Those other plugins must be coded to use that information in some way, however. An example of a mod that has been adapted to work together with Figaro receivers is SirJodelstein's Persistent Trails mod. Q: What orbits should I use for my GNSS satellite constellation? A: The geometry of your constellation doesn't need to be super precise. You just want your satellites to be well distributed around the globe. Real world GPS satellites are in circular orbits with an orbital period of 12 hours (half the Earth's mean solar day). They are located in 6 orbital planes, spaced 60º apart and inclined at 55º from the equator. The Kerbin equivalent orbital period would be 3 hours and 25 seconds (because Kerbin's solar day is 6 hours and 50 seconds long). A 1588 km high circular orbit has about the right orbital period. You can achieve the 60 degree spacing between orbits by launching at 1 hour intervals. Wikipedia's Global Positioning System article has a cool gif showing how the number of GPS satellites that are visible from a given point on the Earth's surface changes with time: Q: I've launched a satellite network but I still don't get any fixes. Why not? A: You need a minimum of 4 satellites to be visible above the horizon to get a fix, and all satellites must have the Figaro Transmitter part installed. You could get a fix with just three satellites if the solver were to make an assumption about your vessel's altitude, but I haven't implemented this because I want the system to work at a range of elevations, from sea level to orbit. And while it is true that I could use the altitude information from the game's UI to make a good guess about your vessel's altitude when solving for position with only three visible satellites, I have chosen not to do so. Q: I've launched a satellite constellation and I have confirmed from the map view that more than 4 satellites are visible to my receiver, but I still don't get a GPS fix. Why not? A: Every satellite in your GNSS constellation must have a Figaro Transmitter part installed. Q: I have a slow computer, and I find that the plugin bogs my computer down since you added the new Figaro Transmitter part. Can I revert to using the old method of giving satellites in my network a unique acronym? A: The plugin maintains a list of spacecraft in your GNSS network that is only updated whenever the number of vessels changes. The module should not add much computational overhead over previous versions of the plugin. If you do have problems with computer speed, you can try reverting to the old method of identifying satellites in your constellation by means of a unique acronym. Just edit the FigaroReceiver part’s Part.cfg file. You will find a “GNSSacronym†parameter there. By default, it is set to "NONE". You can change it to anything you like. The plugin will then search for satellites with that name, rather than satellites that contain the Figaro Transmitter part. Q: How do I know how many satellites are visible to my receiver? A: The number of visible satellites is shown on the Figaro receiver's "Status" UI. Q: Can I close the Figaro Receiver’s UI window when I am not using it? A: Yes. You can use the game’s right-click menu or action groups to turn the UI on and off. Right-click on the Figaro receiver part to display the action menu. Q: I am having some trouble getting my satellites into the same orbital plane and evenly spaced around the same orbit. Do you have any tips for how to do this? A: One option may be to emulate the ESA's method of launching their Galileo GNSS satellites. The Galileo system's In-Orbit validation (IOV) satellites were launched two at a time. If you do this, all satellites on any given booster will start out in the same orbital plane. You'll need only to space them out evenly. I launched three satellites at a time aboard my PEZ launch system. The video below shows the PEZ-C launch. Q: Why are my position fixes erratic sometimes? A: The module calculates your Figaro receiver's position using a method called trilateration. Like with real GNSS systems, the accuracy of the fix is dependent on the geometry of the visible constellation of satellites. The accuracy of your fix may change quickly if satellites are close together or if they are moving quickly in low orbits. Q: Why do you seem to use the acronyms "GPS" and "GNSS" interchangeably? A: I recognise that the American GPS system, like the Russian GLONASS system and the proposed European Galileo system, are specific examples of global navigation satellite systems. I use the terms somewhat interchangeably however, because I believe that most people are more familiar with the acronym “GPS†than they are with “GNSSâ€Â. Q: Accurate navigation requires accurate position measurements. What methods are available for measuring position if you can't "reach into the fabric of your universe" to establish an accurate position? A: One option is an Inertial measurement unit (IMU). IMUs "add up" the entire history of accelerations and rotations to estimate position. These tend to accumulate error over time. The accumulation of error is aggravated by things like vibration. Accumulated IMU error can be corrected with external references, such as celestial navigation, ground radar measurements, etc. NASA has provided an interesting description of how flight controllers navigate the Cassini probe, on their Cassini Mission Overview web page. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

You make some good points. But to be fair, I don't think that the automated systems in KSP are that much better than us human pilots. I can give you at least one solid example showing that human pilots are entirely capable of flying better than MechJeb: Check out the Optimal Ascent Profile for this spacecraft challenge. The top three entries in the non-MechJeb category beat the best MechJeb assisted entry at that challenge. And as for the Protractor mod, what people forget is that in the real world, your navigation systems are only as good as the accuracy of your position measurements. There is no uncertainty in the position measurements displayed by MechJeb and Protractor because the values they display are taken directly from the game. By contrast, ground controllers and the crew aboard Apollo 8 weren't entirely sure that they wouldn't hit the moon rather than fly by it when they flew there in 1968. This was despite the fact that they had all of their computers, automation and some of the smartest people in the world managing the flight. Even the stock game's map view eliminates that uncertainty.

@nhnifong: No, the ejection speed and angle are important, but you also need to time your escape such that you arrive at Duna's orbit at the same time Duna does. And because you're crossing Duna's orbit at a significant angle, your relative speed is very high. As a result, the "window" during which you're within range of Duna's SOI is quite short. During a Hohman transfer intercept, you have a fairly long period where you are basically flying parallel to the target's orbit, so you don't need to be as precise. As for the semi-major axis of the transfer orbit, it needs to be the (cube root of 32 divided by 2) times Kerbin's semi-major axis. This yields an orbital period of 2 times Kerbin's orbital period, so you'll intercept Kerbin again after it makes two complete trips around Kerbol. @Nibb31: Thanks. I am aware that this wasn't a true cycler trajectory and that they aren't very useful for a single trip to Duna. I just wan't sure what to call it because, as Vexx32 points out, it is unclear whether it is really called a free-return trajectory either. Instead, I called it a "proof of concept Duna cycler trajectory", because it is that. It wouldn't take much fiddling with these initial conditions to turn it into a true cycler trajectory. But maybe someone out there knows the proper term for a trajectory like this? I will use this trajectory when I send my Kerbals to Duna. For the time being, this was just an unmanned "dry-run" so I could prove my calculations and navigation before risking my Kerbal hero's lives on the real mission!

In preparation for when I send Kerbals to Duna, I decided to plan and execute an unmanned free-return Duna flyby trajectory. The principle of this type of trajectory is similar to a Mars cycler trajectory, even though it isn't a true cycler trajectory. I intend to use this type of trajectory for my manned mission to Duna because it will give my Kerbals the best chance of getting home if something goes wrong en route to Duna, just as Apollo 13 took advantage of a similar contingency to get back to Earth. The only catch is that it will take them almost 180 days to get home if they do have to use this option. Another catch is that it is less fuel efficient than a simple Hohman transfer. I calculated that I needed 260 m/s more delta-V to get to Duna using this method than I would have if I’d used a simple Hohman transfer. And it will take even more fuel to align them for Duna capture when they arrive. That being said, the outbound trip to Duna took just shy of 33 days. This shorter trip has obvious benefits. And while some may question the practicality of this type of trajectory due to the high fuel burn, it was an interesting challenge to plan and execute. It requires a very high degree of precision that would not be possible without accurate navigation. Even so, I did not use any mods to help me navigate the mission. Only the command pod’s part.cfg file was modified to set the crew capacity to zero. Instead, I planned the mission prior to launch and relied on rudimentary celestial navigation and ded reckoning for navigation. Here are the screen shots for anyone who’s interested: The inter-planetary escape burn was timed to begin 28 seconds after Kerbol set. This would give me the correct ejection angle. The patched conic renderer in the map view was flicking back and forth between a Duna intercept and Kerbin intercept because I had intentionally set the spacecraft up to just graze Duna’s SOI, thereby minimising the effect of Duna’s gravity on my trajectory.

No, I am pretty sure I know what is happening and what you describe wouldn't make a difference if I am right. I'll add it to my ToDo list for the next revision. Thanks for pointing this out.

Maybe you can explain how you mounted the shield upside down? Did you modify the config file, or is there some trick that I don't know about that allows you to mount parts upside down?

Clearly the issue of mods such as MechJeb, Protractor, etc are very controversial... But just as AlternNoctern and others have expressed frustration about members of this forum who diminish players who use mods, I get frustrated by the recurring claim that flying without using mods is imprecise. It isn’t. It just requires playing the game in a different way. It requires careful planning, observation and calculations that many players would find tedious, but that other players like myself really enjoy. At the risk of sounding like a broken record, I’ll re-post a link to an example of a free-return trajectory that I flew around the Mun back in January, long before MechJeb or the Patched Conics trajectory projection system even existed. Per the challenge, I jettisoned everything but the pod and parachute immediately after completing my TMI burn. I had no way to adjust my trajectory after that but the boys still made it home on the first try. I could dig up many other examples of precise mod-free flying by other contributors to this forum, as well. For me, the challenge of achieving my missions “NASA style†(i.e. get it right the first time I try, no do-overs) while working within the limitations of the existing instrumentation and flight controls is what keeps me hooked.

If you are starting your burn at mid-day, then you are probably starting your burn too early. The periapsis of your hyperbolic Kerbin escape trajectory will move during the burn because you don't instantaneously accelerate to your escape velocity, but it won't move by that much. I don't know how the various mods like MechJeb or Protractor account for this effect because I've never used them, but for reference I started my Duna transfer burn 20 minutes and 44 seconds after Kerbol rise, as viewed from my 100 km parking orbit. Below are screenshots that I took during my first (and so far only) attempt to reach Duna. While I did require orbital corrections en route to lower my periapsis at Duna, it wasn't more than a few m/s. The RCS tank in the spacecraft is empty; the boffins at KSC re-fitted it with sensors to measure Duna's atmospheric properties during descent. Transfer trajectory (screenshot taken 6 minutes and 45 seconds after the one above, immediately after the transfer burn and trim were completed.) Also, it is relevant and interesting to point out that NASA intentionally biased Curiosity's initial transfer trajectory so that it wouldn't intercept Mars [Ref. F. Abilleira, 2011 Mars Science Laboratory Mission Design Overview]. They corrected the trajectory only after the spacecraft separated from the Centaur upper stage. This ensured that the Centaur booster would not crash into Mars, which would have violated their planetary protection criteria.

Brilliant! I laughed, I cried! It was better than Cats!

Do you mean this "forum" or this "thread"? I don't think most posters to this thread are being self-righteous. Reahreic asked if anyone is using mods. Most respondents are just answering that question.

I have never used a mod to rendezvous, to navigate to another celestial body or to land. I have used mapping, atmospheric probes and re-entry heat mods.

There's also the case where a binary asteroid pair gets close enough to a larger celestial body that one of the two gets captured by the celestial body while the other escapes. This is the same mechanism that is believed to produce hypervelocity planets and stars. This mechanism could also explain how Gilly's moon was captured.

I'll add the plot below to illustrate Vanamonde's point: The plot compares a free-return trajectory calculated using the "KSP patched conic" model with a free-return trajectory calculated using a 3-body model given the same initial conditions as the KSP patched conic model. Both trajectories are shown in Kerbin centric coordinates. Even though Kerbin and the Mun wobble around their mutual barycentre in the 3-body model, there still isn't a huge difference in the results when I transpose the 3-body model results into Kerbin-centric coordinates. In short, the KSP patched conics work just fine at simulating even complex orbits like a free-return trajectory.

Thanks for the compliment! I have been working on the next update to the module in preparation for MrPwner's contribution to the project but I don't have an ETA for its release yet. I have also added a "hard-core" mode that will allow command pods with the heat shield attached to behave as a lifting body, like the Apollo capsules did. The mode can be enabled by setting a flag to "true" in the heat shield's part.cfg file. Doing so gives the capsule a 10-15 degree angle of attack and a lift-to-drag ratio of about 0.3 during the supersonic phase of re-entry. I have tried a few re-entries with the "hard-core" mode's lift effect enabled and it is kind of neat. I've found that it tends to reduce re-entry g's but increases heating due to longer term exposure to high temperatures. I even managed to get a slight skip during one re-entry! That result will probably require that slightly steeper trajectories be used when the "hard-core" mode is active. And finally, I tested the current version (v1.0.17.03) of the re-entry heat module in Duna’s atmosphere: It worked as I expected it would but the entry was actually pretty benign… Even though I flew a hyperbolic trajectory to entry, the atmosphere relative entry velocity was only about 1500 m/s. The peak shock temperature wasn’t much to write home about as a result of Duna’s cold atmosphere and the low entry speed. As a result, I now tend to agree with Togfox that I should leave the physics model alone and not set custom constants specific to Duna’s atmosphere. I would have to set the heat transfer coefficient and gamma significantly higher before Duna atmospheric entry would even approach the severity of Kerbin atmospheric entry. I don’t think that is justified.

Thanks. I've updated the leader board. You're still in first place. And to MavrickSawyer's point: I guess it then becomes a question of play balance. Maybe they'll need to change the part costs when campaign mode is finally implemented. For the time being, it seems that the cost of fuel is included in the part cost. SRB's give you a lot more Delta-V for the buck than a LFT/LFE combination. For my design, I decided that I could afford to waste delta-V by using SRBs in a non-fuel efficient manner, since the objective of this challenge is merely to build a cost efficient rocket. Why not throw your hat into the ring with your own entry?

I tried to work within the game's existing UI when I set the limit for max G's in the re-entry heat module. You won't have any trouble re-entering if you keep the g indicator needle out of the red arc on the navball. The longer the needle stays in the red arc, the more damage your spacecraft will sustain. And the higher the g's you experience, the quicker the spacecraft will reach its damage tolerance threshold. In playing with the re-entry heat module myself, I have found that shallower trajectories result in increased shield temperatures (lower heat flux but high maximum temperatures due to longer term exposure), while steep trajectories result in higher g's and lower shield temperatures (i.e. high heat flux but lower maximum temperatures due to shorter term exposure). I have also been working on the next release of the plugin already, in preparation for MrPwner's contribution to the project. His heat shield model will include a transparent bow shock effect that I will be able to display during re-entry as appropriate per the physics model. I have also added a "hard-core" mode that will allow users of the re-entry heat module to enable a lift force in the part's configuration file. Playing with the module with the lift enabled, I've found that it tends to reduce re-entry g's but increases heating due to longer term exposure to high temperatures. That result will probably require that slightly steeper trajectories be used when the "hardcore" mode is active.

As Alephzorg and szpw mentioned already, there are a lot of good mods that can be used. And maybe you can even come up with something on your own, too. For example you could calculate the mass and radius of the celestial body that you're orbiting without using any mods.

Yes, but the objective of this challenge is to be cost efficient, not fuel efficient. They aren't necessarily the same thing.

Nice. I've updated the leaderboard. Edit: Can you check your cost calculation? I will use the value that you have provided, but I get a different value when I calculate the cost of your stack myself...

Here's some relevant data to compare Kerbin and Duna's atmopshere. Unfortunately, the temperature axis is plotted using different units on the two graphs. The pressure and density axes "units" are the same though.

Here’s my entry (please forgive the double post). I flew the stack shown in the “On the Pad†spoiler below on a mission to collect data about Duna’s atmosphere. The data is plotted below: The rocket consisted of the following: Qty 1 Single Parachute (cost 422) Qty 1 Command pod (modified to be flow by ground controllers) (cost 600) Qty 1 Empty RCS tank (refitted to carry scientific instruments) (cost 800) Qty 2 Stack decouplers (cost 975 each) Qty 1 Small fuel tank (cost 225) Qty 1 LV-T45 engine (cost 750) Qty 2 Radial decoupler (cost 1275 each) Qty 2 SRBs (cost 450 each) Qty 4 Strut Connectors (250 each) Qty 3 Fuel tank (850 each) Qty 1 LV-T30 (850 each) Total: 13572 I am sure this can easily be beaten. Do your worst!

I would like to propose a challenge in the spirit of NASA's Faster, Better, Cheaper initiative of the 1990's. While that initiative was controversial, it makes a catchy headline for a challenge that may motivate the advancement of Kerbal science. THE CHALLENGE: 1. Send a scientific (or scientific capable) mission to Duna for minimum cost. 2. Accomplish some scientific objective. 3. Show off your innovation. METHOD: Build a rocket using stock components and fly it on a one-way mission to Duna, carrying a scientific payload. Ideally, deploy the scientific payload and collect data that you can post along with your entry. (Example scientific objectives could include mapping probes, atmospheric probes, etc.) The mission can be kerballed or unkerballed, but kerbalitarian groups will likely oppose kerballed one-way missions. Calculate the cost of your rocket by adding up the cost of the components, as given in the VAB. There is no credit for recovering used parts because doing so doesn't account for the cost of fuel and preparation of those parts. There is also no credit for re-tasking parts. Rockets must be made from stock components, with the exception that parts may be modified as needed to carry the scientific payload or reduce crew capacity. (i.e. in my case, I modified my command pod to set the crew capacity to 0 and I modified an RCS tank to carry my scientific payload plugin.) Modification of engine thrust or part masses are not allowed. Make note of which mods you used in your entry. (i.e. ISA Mapsat, MechJeb, Protractor, etc.) I have entered my own flight to start, but I expect others will be able to easily achieve a better result. LEADERBOARD: 1. andydouble07: cost 13025 (MechJeb and ISA Mapping Mod) 2. PakledHostage: Cost 13572 (no mods other than a home-brew atmospheric sensor plugin) 3. 4. 5.