PakledHostage

Awesome videos! I would think that even the Moon\'s interior density distribution would have an effect over a long enough time period? Check out the GRAIL mission. I heard an interview with Dr. Maria Zuber (the GRAIL mission\'s principal investigator) on the CBC\'s 'Quirks and Quarks' program some months ago. She explained that they will be able to measure the Moon\'s density distribution by accurately measuring variations in the distance between the tandem GRAIL spacecraft caused by the Moon\'s mass distribution. I guess the question is whether or not the effect is strong enough or if it is overshadowed by other effects (like tidal effects)?

But you could build a spacecraft with comparable thrust-to-weight ratio and practice flying that around KSC? I agree with samstarman5. I spent a lot of time learning to hover and doing extensive preparation before I ever flew my Kerballo 11 mission. I flew a Kerballo 8 mission around the Mun, Kerballo 9 to test my lander in low Kerbin orbit. Kerballo 10 was my Munar dress rehersal mission. That mission tested my lander in Munar orbit and made a trial descent/abort. I only lost a single crew during these missions. The crew of Kerballo 10 was lost in a 5000 km by 12000 km Kerbin orbit after they ran out of fuel returning to Kerbin. The board of inquiry blamed that accident on engineering errors and inadequate crew training. It was more than a month after the Mun was first introduced into the game before Kerballo 11\'s Pheonix lander touched down in the Sea of Pandemonium. I flew all my Kerballo missions real time, too. All of that preparation and commitment made it all the more satisfying when I finally did land on the Mun. I still remember how my heart was racing when the boys shut down on the Munar surface and announced to KSC that 'the Phoenix has landed'. PH.

For what it is worth, I\'ve attached a PDF printout of the first few pages of the MathCAD spreadsheet that I\'ve been using since I discovered KSP last summer. It gives some of the same forumulas as UmbralRaptor but in a format that might be a bit easier to read. Anyone who\'s keen could use these forumulas to set up their own Excel spreadsheet.

Congratulations on getting this done! Excellent work! I ran into this problem while developing my own mapping plugin (I\'m running KSP on a very marginal computer), but I\'m glad to see that others were able to get it working. I guess I\'m the Kerbal equivalent of the Canadian Space Agency - lots of ambition but limited by my budget... An idea that I did manage to get working was scanning the 'radar/laser' beam back and forth through a ±40° arc about the heading vector, rather than just sampling the distance to the terrain directly below the spacecraft. Sampling this way increases the resolution of the data because you get more data points. And it doesn\'t actually take very many lines of code to do because it uses Unity\'s built-in quaternion rotation identity function. Let me know by PM if you would like me to give you the code to rotate the radar/laser beam for your project. This sample map shows data acquired using the scanning radar while flying NW out of KSC. Lowest elevations are dark blue while highest elevations are red. Black pixels are 'no data' pixels. You can just make out the coastline and the mountains to the NW of KSC in the image. PH.

I rolled my own by modifying my old Mandelbrot Set Explorer project. (Do I get uber geek points for that?)

I\'m trying to develop one but I haven\'t got it working yet. As I mentioned above, I can measure terrain height while I\'m flying at sub-orbital speeds, but something seems to be limiting my ability to do it at orbital speeds. The spoiler below contains a sample map that I created from data acquired while flying NW out of KSC. Lowest elevations are dark blue while highest elevations are red. Black pixels are 'no data' pixels. You can just make out the coastline and the mountains to the NW of KSC in the image. My radar plugin measures the distance from the spacecraft to the terrain by scanning a 'beam' from side-to-side in a ±40° arc. It subtracts the resulting distance vector from the spacecraft\'s position vector to get the terrain height at locations between the angular limits of the beam. I record the data to a file and then use another application to process the data into a bitmap. All the pieces are in place for this to work but at this point I seem to be limited by the game engine (I know that I\'m WELL outside of the intended use of the game here). Maybe I\'ll get this working eventually but for now I\'m stuck. If I get it working and if it doesn\'t violate the prohibition on reverse engineering the game, then I\'ll share my results and the plugin.

Thanks, but I wrote my own altimeter plugin so I\'m able to adjust the range that it works over. As I said in my previous post, it doesn\'t work on my system while moving at orbital speeds. That doesn\'t mean it won\'t work on other peoples machines. I know my computer is marginal for playing KSP (it is only a little netbook). Also, the security settings on my work computer cause the map in your post to not show up as an animation, so it wasn\'t obvious that your measurements were done from orbit. Mu and HarvestR\'s explanation over in the other thread of what might be causing the problem suggests to me that the collision meshes aren\'t being filled in under my spacecraft while it is moving at orbital speeds. That prevents the altimeter from working and it also allows the spacecraft to fall through the Munar surface without a collision being detected. To reiterate, my altimeter does work from sub-orbital speeds and it does work from higher than 3 km. If I get a chance, I\'ll try running it on a faster computer and will report back what. In the mean time, it is great that it works for you.

I\'ve tried to do it from orbit but I can\'t get it to work on my system because my radar altimeter doesn\'t detect the munar surface while moving at orbital speeds. It detects the surface fine when I\'ve slowed down to final approach speeds but I can\'t map much of the Mun\'s surface that way. I think this is related to the reports over in the KSP development thread where people\'s landers are falling through the Munar surface.

I noticed this so I bumped up the mass of the full 1/2 tank to 1.3 mass units in the tank\'s config file. It modifies the part, but not in a way that makes things easier. This does raise an interesting point though: Should there be a standard fuel density for LFTs? The values (both for standard and mod parts) are currently all over the map.

I just ran some more numbers to follow up on the How do we get to Mars thread, and you really don\'t need very high speeds. In the example in the post that I just referenced, you only need about 880 m/s at Kerbin\'s SOI to reach a planet orbiting at 1.5 times Kerbin\'s orbital radius. You can achieve that by boosting to just ~3260 m/s at 112 km altitude. By contrast, getting out to the Mun\'s orbital radius from Kerbin orbit requires ~3080 m/s at 110 km altitude. That\'s only about 180 m/s less than you need to get to out to 1.5 times Kerbin\'s orbital radius! (These are post-burn speeds following a 95 second and 80 second burn, respectively, by a 5 mass unit spacecraft powered by a LV-T45 Liquid Fuel Engine.) The trip would take about twice as long as your ~39 days, but that doesn\'t take very long at 10000x warp.

I don\'t know if you are referring to my post here, here, or even if you\'re referring to one of my posts at all... But I have been involved in these discussions before. Below is the plot that I posted in the 'N Body Gravity why not?' thread back in December. I plotted it in Excel but the data comes from my trajectory planner (the physics engine is mine and I use it to plan all of my KSP missions, so I trust the results). At the time, I noted that: 1. The initial orbital velocity (2266.9 m/s at 152 km altitude) was the same for both test cases 2. The Munar periapsis was the same in both cases (140 km) 3. The length of TMI burn required to yeild the 140 km high Munar periapsis was 0.8 seconds longer (85.0 seconds vs. 84.2 seconds) for the 3-body case than in the patched conic case. 4. In the 3-body case, the Mun\'s initial orbital speed was set to the 542.5 m/s used in the game (rather than the 547.4 m/s that it requires for a 12000 km radius circular orbit). 5. All three curves were plotted in Kerbin-centric coordinates. (i.e. the coordinate frame moves about the barycentre together with Kerbin in the 3-body case.) 6. If you\'re paying close attention, you might have noticed that the Mun\'s orbit crosses the Y axis at something less than 12000 km in the plot above. This is an artefact of Note 4, above. I should have plotted the Munar position for the patched conic case, not the 3-body case. Now reading this thread this afternoon, I decided to go back and make another plot. This time, I compared a trajectory in the “KSP patched conic†model with a trajectory having the same initial conditions in the 3-body model. Only this time, I set the Mun’s orbital speed in the “patched conic†case (where the Mun moves on rails) to the same 547.4 m/s that is required in the 3-body model to yield a 12000 km radius circular orbit. (Using 542.5 m/s for the Mun’s initial speed results in it having an 11573 km x 12000 km elliptical orbit.) And 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. I personally see very little benefit to revising the physics to a 3-body model, although some benefit could be realised by adjusting the Mun`s orbital speed upwards a bit. Edit: Fixed a blunder in the plot that I posted earlier this afternoon.

The easiest way to do it is to depart Kerbin on a trajectory that results in an elliptical orbit with periapsis at Kerbin’s orbital radius and apoapsis at the target planet’s orbital radius at the time of rendezvous. It is even easier if the target planet is in a circular orbit and in the same plane as Kerbin. For example: Planet X is in a circular orbit 1.5 times the radius of Kerbin’s Planet X therefore orbits Kerbol at 1.844 deg/day An elliptical orbit with periapsis at dkerbin and apoapsis at dplanetx has a period of 148.653 days. The trip from periapsis to apoapsis will take half that, or 74.327 days. Planet X will move 74.327 days x 1.844 deg/day = 137.1 degrees in that time. If our hero’s make their escape burn from Kerbin when Planet X is 42.9 degrees ahead of Kerbin, they will reach their point of apoapsis at the same time as Planet X reaches that point. They’d need about 880 m/s excess velocity at Kerbin’s SOI to do this. The only tricky part is making your escape burn so that your velocity is in the correct direction when you exit Kerbin\'s SOI (I do this by timing my burn with reference to Kerbol\'s rise/set time, as seen from my parking orbit). And if you time your burn so that you arrive at your apoapsis an hour or so before Planet X, it will catch up to you because you’ll be moving about 800 m/s slower than it at that point. For a bit of practice with this stuff, consider trying BoolyBooly\'s Shoot for the Sun challenge. The principle is the same as what I\'ve described above, except you don\'t need to worry about timing your escape burn. PH. Edit: Added sentence about timing the escape burn relative to Kerol\'s rise/set time.

But I would hope that at least some of the other planets will have elliptical orbits (much like Nova\'s proposal). Think of it like levels in the game. If you rescued the princess the first time you ever played Super Mario Brothers, you probably wouldn\'t have played it very many times. The Mun is easy to get to because its close and has a circular orbit. Other planets with circular orbits would be a bit more difficult. The most difficult planets to reach could have elliptical orbits (and maybe even non-zero orbital inclination). Even more complexity (i.e. levels of difficulty) could be added if those planets in turn had moons.

Brilliant! Remote sensing comes to KSP. You\'ve given me an idea for when other planets are eventually added... To the Batcave!

Thanks for clearing that up. Sorry for the poor choice of words. But did you know that even though our Moon is tidally locked with the Earth, there is a narrow band at the boundary of the 'Dark side' where the Earth does rise and set? It happens because, unlike the Mun in KSP, our Moon\'s orbit is elliptical. That\'s one of the many tidbits that I didn\'t know before I started playing KSP.

Three of my favorites:

Something to keep in mind as well is that typical orbital speeds for Earth are on the order of 7500 m/s, while they\'re on the order of 2200 m/s for Kerbin (give or take). You need to fly a much more efficient trajectory to get into Earth orbit because real rockets have a lot less margin than our typical Kerbal rockets.

And once you master that method, you could strive for higher efficiency re-entries that still get you close to your target. I\'ve brought my capsule down at KSC from a 100 km high orbit using only 82 m/s Delta V. It is possible to do it with even less Delta V than that. Check out the Mercury 'Friendship 7' Commemorative Challenge. I included retro-fire timing and Delta V values there for three different starting orbits (you have to click on the spoilers to see them). PH.

Wow, pushing the envelope! [Jeb gives me a look of annoyance as he hands over the IOU for the peanuts... He\'s still angry at me because he and the boys had to make their own way back to KSC after their last mission. Seems I installed a timer upside down and it subtracted 10 seconds rather than added them when calculating the time for their re-entry retro-burn.]

Well, Jeb could use a girl like her. I\'ve even heard her called 'The Lady Who Tamed Pegasus'... Sounds like the stuff of legends.

Sorry BoolyBooly, I don\'t want to get in between you and Mary-Lou Kerman but I couldn\'t resist the challenge of trying to go for a smaller spacecraft. I managed 7 full-size LFTs and 2 1/2 size LFT\'s for an equivalent of 8 full LFTs. I used 2 LV-T30s and 1 LV-T45 (total mass 4.5 tonnes) for propulsion and left the RCS and SAS at KSC. The total launch mass was 26.7 tonnes. Here are the screen shots (you will see that your Sunbather 1 influenced my design): First pass: Scenic detour between first and second aerobraking passes: Second pass: Third pass: Landed a bit short: 18.2 km east of the pad at KSC. The boys are walking home... If you see them, give them a lift, will ya? I figure someone could shave about another 1/2 tank off this assembly if they went for a 2-year or longer mission. I\'ll leave that for someone else to do though.

Jotting some figures on the back of a 'Dog and Booster' paper coaster, I think I might be able to get it lower. Until then, enjoy your peanuts and all the prestige of your current status as record holder!

Impressive! By improving my first stage booster, I\'ve managed to get down to 9 and 1/2 tanks but you\'ve still got me beat on the propulsion end. I\'m still using 7.0 units (3 LV-T30s and 2 LV-T45s) of engines on my latest design... I could cut that down to 6.5 units of engines without changing the flight plan, but topping your performance is clearly going to take some drastic measures!

Quick tip: In Windows, you can get the ASCII degree symbol by turning on Num Lock, holding down 'Alt' key while typeing '248' on number pad. You can get any symbol in the ASCII character set this way. Try it, its fun! (It only works with a full-size keyboard though.) Now back on topic: I like the idea of naming rights to places on the Mun where\'ve we\'ve landed, but I also think that the major features like the Mares should be named according to the results of an open vote. Maybe we could start by compiling a list? I like Mare Tenebris, but I also like Mare Pandemonium. PH.

I don\'t play golf, but I can understand the satisfaction of planning a shot and then sinking the putt... I\'ve been practicing precision re-entries since I posted the Mercury 'Friendship 7' Commemorative Challenge about a month ago and I kind of enjoy it. I\'ve also learned a lot. In a nutshell, my method is to make my de-orbit burn starting from a circular orbit (because circular orbits have a constant angular velocity), then time my de-orbit burn in reference to overflight of KSC\'s antipode. I find that I can target my re-entry fairly accurately by watching the purple anti-KSC reticle on the nav ball as it passes the nav ball\'s nadir. If you look closely, you can see the edge of the white dot disappear under the centre dot of the purple reticle within about 1 second accuracy. It starts to re-emerge about 20 seconds later. I get the best accuracy by recording both times and averaging them. This method only works because KSC is very close to the equator and if you use an equatorial orbit, but I find that I can usually get my capsule down within about a 5 km radius of the pad. I think better accuracy than that comes down to luck (or active control using thrusters or lifting surfaces). PH.