PakledHostage

Upon reading back through the whole thread, I think the problem that people are encountering with the blank screen is due to an interaction with MechJeb. I think it happens when the control input magnitude goes over 1.0. I ran into this during development, but didn't try it with MechJeb after I fixed the bug that I encountered myself. Mechjeb is probably working against the "inherent stability" code and running the control inputs up to the point where my code pushes it over the edge. I will have to do better error trapping. And I would love to read about a better way to destroy the debris parts. I used a call to the built-in "OnDestroy" event because that worked, but it would be great if there was a more "explodey" way to do it!

Oh. I guess I misread the bottom two lines in Moach's second comment. I tried to PM him but he's disabled the option to do so.

Uh oh! It is going to take me some time to catch up with all of this... I have been away from the forums since Friday because it has been almost impossible to log on with everyone downloading v0.17. Let me try to work out some of the bugs tonight. I'll post an update as soon as possible. Moach, maybe you can PM me with your comments/changes? Some of the "inconvenient logic" quoted above was intentional, but apparently didn't work on everyone's spacecraft. It is easy to be critical of new code modules, but please remember that no developer can play test every configuration or consider every way that a module will be used. Bugs are inevitable in a first release, so maybe I should have run it through a round of alpha/beta testing before I posted it. The parachute code is relevant because the chute opens automatically at high supersonic speeds in the game. It would burn up, or at the very least be torn from the spacecraft. It also screws up the re-entry model if it opens too early because the spacecraft slows down too quickly. Curiosity's parachute was only rated to about Mach 2.0 in the much thinner Martian atmosphere. I used a similar limit in this module. Sorry if it didn't meet your initial expectations. Stay tuned for v 1.17.02.

Contact: PakledHostage FOR IMMEDIATE RELEASE PROCYON INNOVATIONS ANNOUNCES NEW HEAT SHIELD LINE FOR MK1 AND MK2 COMMAND PODS [KSC, September 21, 2012] Procyon Innovations, in cooperation with Mechanical Mouse Industries, has released a new line of ablative re-entry heat shield parts for the popular line of MK1 command pods. The new parts protect spacecraft from the extreme conditions typical of re-entry. The two new heat shield models are the culmination of months of work that began with the development of a physics model to predict conditions experienced by spacecraft entering Kerbin’s Atmosphere. Little progress was made after that however, until an agreement was reached between Mechanical Mouse Industries (MMI) and Procyon Innovations (PI) to work together on the project. MMI would provide the 3D model, while PI would provide the plugin. When asked to comment, astronaut Jebediah Kerman remarked “I’m not sure why we need this part, we never had any difficulty with re-entry before…†He became more excited about the new heat shield, however, when he was shown the picture below: Spacecraft using this new line of heat shields will be destroyed if they experience excessive g-forces or extreme temperatures during re-entry. And while the ablative shields will sustain heat loads typical of re-entry, some planning is required. Use of this heat shield requires steeper re-entries than you may be used to. Aggressive aerobraking and shallow re-entry angles will result in the heat shield burning up. Too steep a re-entry will result in excessive g-loads. The survivable re-entry corridor therefore gets narrower with higher re-entry speeds. Procyon Innovations has promised to provide a plot of the re-entry corridor vs. re-entry speed in the user manual, but no completion date has been given. Procyon Innovations would like to acknowledge and thank the following people for their help with this project. - Dani-Sang at Mechanical Mouse Industries for his work creating the heat shield part and emissive animation. - Tosh for making his FireSmoke particle emitter class library available for use by the KSP modding community. - MrPwner for his efforts to create a transparent emissive texture. While his work didn’t make it into this version of the project, the visual effect will be a great addition once it finally is ready. - Thorfinn for his polite and constructive feedback about the re-entry physics model With apologies to NovaSilisko for borrowing his idea to display heat shield integrity in an information bar on the icon stack. It was too good an idea to pass up. The new Procyon Innovations Heat Shields are available for download here Question and Answers Q: Why don’t I see any re-entry effects? A: Have you activated the heat shield in the staging sequence? Re-entry effects are only displayed when the red “Integrity†information bar is displayed in the icon stack on the left-hand edge of the game window (see screenshot above). Q: My heat shield is active, but I still don’t see any re-entry effects? A: Are you sure you are going fast enough through atmosphere that is thick enough? Re-entry effects are calculated based on the atmospheric properties of the planet you are landing on. It takes a while to heat up. Think of it this way: - You put a pot of water on a hot stove. The stove is already glowing red hot but it takes a while for the water to heat up. If you put the pot of water over a weak heat source (like a match or lighter), it won’t heat up at all. - Just as thin atmosphere doesn’t slow the spacecraft very much, it also doesn’t heat up the spacecraft very much. Maximum heating occurs at maximum deceleration. This is a good indication that the physics behind this re-entry model reflects reality. Q: My parachute exploded during re-entry A: You opened your parachute too early, and the parachute was intentionally destroyed by the Plugin module. The parachute opens automatically in the game while the spacecraft is still at high supersonic speeds. It should burn up or be torn from the spacecraft if you let it open that early. Curiosity's parachute, for example, was only rated to open below about Mach 2. Revise your staging so that the parachute is on its own stage (see the screenshot above for an example), and then only open your parachute once the spacecraft slows below about 300-400 m/s. Q: How do you calculate the re-entry effects? A: The re-entry heating effects are calculated using a simplified aerodynamics and heat transfer model that is described in detail in the Re-entry Heating Model thread, over in the General Discussion section. Q: My screen went blank, the Navball shows “NAN†in the speed display and the altitude is showing funny numbers. A: This is a known bug in version 1.0.17.01. It was caused by an unexpected interaction with MechJeb. This bug was fixed in version 1.0.17.02. Download the most recent version (see below) to solve this issue. Q: What is the most recent version of the re-entry heat plugin? A: Version 1.0.17.03 was posted to Kerbal.net on September 29, 2012. Q: How do I know which version of the re-entry heat plugin I'm using? A: The re-entry heat plugin version number is displayed in the KSP Debug Console. Press Alt+F2 after activating the heat shield to see the version number. Q: Can I use the re-entry heat plugin with my own heat shield model? A: Yes. Just include an emissive animation for the heat effects in your model. The animation should "play" from coldest to hottest. See C7's for an explanation of how to create emissive animations. Add "module = ReentryHeat" and a "HeatShieldHeatAnimation" parameter to your model's part.cfg file. The HeatShieldHeatAnimation parameter specifies the name of your emissive animation. (i.e. HeatShieldHeatAnimation = my_animation).If you make a part that uses this re-entry heat module, please do not distribute the module with your part. Instead, set this addon module as a pre-requisite in Kerbal.net. That way, I can post updates to a single site, rather than having to keep track of every mod that uses it. For more information or assistance, please request help in this thread before contacting Procyon Innovations directly.

Sighting off the Mun is a rudimentary form of celestial navigation, and they did make extensive use of celestial navigation. You can adjust the angular displacement between the start of your TMI burn and the Mun very accurately by adjusting the altitude of your parking orbit. You can develop your own program to calculate the length the TMI burn required to efficiently rendezvous with the Mun. I wrote my own, but there are others out there. And I know I've over used this example but it continues to be relevant to these discussions. Here's 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. That was only possible because sighting off the Mun is an accurate method of navigation.

Spoken like a true professional.

You could compare it to the real thing? Here's two videos on YouTube that I found:

I think this is great! Nicely laid out plans. I haven't done much lately but I've found that role-playing adds a lot to the game. While my sketches aren't as good and my writing isn't as neat, I'll be planning my first missions to the new planets in v0.17 in much the same way. The goal will be to get there the first time I try, and without killing any Kerbals.

Welcome to the forums! This rocket configuration doesn't have enough delta-V to reach orbit in v0.16 of the game. I am sure that efficiency challenges like this one will see a renaissance when the fuel bug gets fixed in v0.17. Until then, if you really want to try this challenge, you could download the demo version of the game and try it in that version...

It isn't done yet. The image above only shows a debugging version of the PartModule installed in an RCS tank. We are still working on the visual heat effects. When they are done, the add-on will be released. It will be a while before that happens though.

I have always liked used cars... You know, reduce, re-use, recycle... But I'd be very cautious about buying something with a lot of rust on it. If you really want a Mustang but don't want to pay a lot of money, why not try to find something from somewhere where they use less salt on the roads? The last car I had before my current one was a '94 and it didn't have any rust on it. I sold it to some university students a couple of years ago for $500 (it wouldn't go into 2nd gear anymore). They took it on a 15000 km road trip and didn't have any trouble with it. I am sure you could find something equally reliable and rust-free if you look around.

You're right, but I don't think much of the criticism here is directed at Adam Cudworth. The problem is with how it is being reported. If the article was posted on these forums, it would probably be deleted by the mods on the grounds that it’s nothing more than a trolling attempt. By failing to put the facts into proper context and by over stating other aspects of the story, it makes NASA/the ESA seem like a bunch of boobs and fuels anti NASA/ESA sentiments.

Well, thanks for trying!

This may be interesting for my fellow KSP fans: Explosion on Jupiter spotted by amateur astronomers.

Objects in this mirror are closer than they appear? 7/10

Your screen shots show that you've still got one and a half tanks of fuel. Why not post your persistence file in the challenges section? Someone will be able to get them home. You'll probably be surprised how quickly they'll do it.

Of course everyone is entitled to play the game the way they want, so I don't think it is fair say that using MechJeb is cheating. That said, I otherwise agree with Jay_Em. And Kosmo-not. KSP is not so much a simulator as a physics sandbox. What I like best about it is that it gives us the opportunity to experiment. I have learned a lot by hand-flying my missions and forcing myself to only build rockets that can be hand flown. I am not alone either. Just look at all of the efficiency challenges, The KSP Star Rally, the many Kerbol orbit/return to Kerbin challenges, etc. Most of the players posting in those threads aren't using MechJeb.

Here's 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 am not alone. Lots of players are flying complex missions without using MechJeb.

So far it is only a PartModule, although MrPwner has done a lot of work developing the visual re-entry effects. The module currently calculates re-entry heating effects and uses those values to degrade the ablative heatshield's integrity during the re-entry. The spacecraft will be destroyed if the heatshield's integrity drops to zero, or if re-entry g-loading exceeds the top of the scale on the navball. I've also attempted to account for extended exposure to high re-entry g-loads. I've chosen to treat g-loads in the red arc on the navball as damaging to the spacecraft. Short-term exposure to high g's will degrade the command pod's structural integrity but won't destroy it. Longer term exposure to high g's will destroy the command pod. Higher g's will degrade the structural integrity faster than lower g's. And as this still is a work in progress, we won't be releasing the PartModule just yet. Below is a screenshot showing the development/debugging version of the PartModule during re-entry. The spacecraft will be destroyed if the "integrity" bar on the right reaches zero. (With appologies to NovaSilisko for borrowing his idea for the "Integrity" bar... It was too good an idea to pass up!)

I am certain that you are correct that human factors play a role in achieving the optimal descent, but they aren't the only reason that a low approach is more efficient. A lot of analysis was done by contributors to the Optimal Descent to the Mun challenge to verify the experimental results. Much of that analysis was idealised and didn't take human factors into account. There were also a couple of articles cited that support the low altitude transition from orbit to landing as the most efficient solution. Check out: The Apollo Lunar Descent and Ascent Trajectories article that Tarmenius posted The Orbital Transfers textbook chapter that Closette posted

I understood from the article that they intentionally crashed Lunar Orbiter 1 into the dark side of the Moon because it was low on fuel and to free up radio bandwidth for the Lunar Orbiter 2 probe. The Moon also causes orbital perturbations because its gravitational field is not uniform. Check out NASA's current GRAIL mission for more on this. The Wikipedia article about the GRAIL mission may not be the definitive source, but it is a good place to start.

What I found even more interesting was the related article about the Lunar Orbiter Image Recovery Project. I guess this was big news in some circles a few years back, but I don't remember hearing about it. You've got to admire the LOIRP team's dedication! It would have been so easy to give up.

This past spring, two challenges on this forum explored optimal descents to the Munar surface and optimal Munar orbit insertion from a given transfer orbit. And while these challenge threads pre-date v0.16, the results are still valid. Some of the experimental results were as expected but some were counterintuitive and go against the conventional wisdom. Have a look at the threads here: Optimal Descent to the Mun challenge Optimal Munar Orbit Insertion challenge

And tell your classmates about KSP! I've shown it to all of my friends who are teachers. Microsoft Flight Simulator led me down the aviation rabbit hole when I was a kid. KSP will do the same for many others.

I think this project is going to be a good learning experience for both MrPwner and I, but I think we can do a good job. And while it may not turn out to be possible to vary the transparency of the shock re-entry effect model, I think we can make it look pretty and behave realistically with a bit of effort. I am looking forward to getting it working because I think re-entry heat is something that is missing from the game. If I remember my space history correctly (I am sure someone will correct me if I am wrong), the Soviets were able to orbit impressively large spacecraft in the early days but they couldn't successfully re-enter them. This is because it is quite the technological challenge to bring a spacecraft (or warhead) down from orbit in one piece. We currently have it easy in KSP...