Jump to content

PakledHostage

Members
  • Posts

    2,090
  • Joined

  • Last visited

Posts posted by PakledHostage

  1. I did a short suborbital flight to see the effects, but all I got was 2 puffs of smoke. I thought that I needed more speed, so I tried reentry from a Mun return trajectory. The heatshield got very bright, but I didn't see any flames :(

    Hmmm...

    What warp were you using?

    What did you set your periapsis altitude at?

    What if you try, say, starting from a LKO in the 80km to 100 km range and lower your periapsis to somewhere in the 25-35 km range? It shouldn't make a difference if you enter in real time, but what if you re-enter at 1x time warp? Does that make a difference? You should see a plasma trail comparable to that of the video on the first page of this thread if you re-enter this way. If you still don't see any re-entry effects, then there must be some game setting or video card issue that is preventing the smoke effects from being displayed?...

  2. speaking of which... some "light" reading down at wikipedia on the matter at hand here revealed quite a convenient mathematical coincidence

    turns out, the peak shock temperature a vehicle can expect during reentry is pretty much the same value (in Kelvin) as the velocity in m/s

    I noticed that when I was developing the re-entry heat physics model. It is one of the facts that I used to check my work. It gave me some comfort that the values calculated by the current re-entry heat physics model that is used in the module already agree quite well with this. You can set the "DisplayHeatShieldUI" parameter to "True" in the heat shield's part.cfg file if you want to view the shock temperature all throughout the re-entry. Also, you may want to have a look at the the Re-entry Heating Model thread, over in the General Discussion section. This explains the current re-entry heat physics model in detail.

    I guess the question then becomes, do we use a physics model that has at least some physical significance and basis in aerodynamics & thermodynamics, or do we just fudge it? I prefer to stay with the physics model currently used in the module because it isn't just based on a rough rule-of-thumb. This allows re-entry effects to be varied somewhat realistically for different planets, merely by changing one or two constants in the model. The model will then respond according to the properties of the atmosphere that exists on that planet. That is the way it works right now, with the exception that gamma and the simplified heat transfer coefficient are the same for every planet/moon with an atmosphere.

    And as for making this module work with other heat shield/aeroshell parts, maybe the best way to do that would be to expose the HEAT_DAMAGE_LIMITS constant as a parameter that can be set in the part.cfg file. Heat shields and aeroshells that are designed for higher speed re-entries could have higher heat damage tolerance, maybe with a corresponding weight penalty to maintain some play balance and challenge.

  3. I am happy to hear that my bug fixes have improved things! I was aiming to deal with the "show stoppers" so that people newly downloading the mod would have a more positive first impression. This will buy time to work on polish and solving some of the remaining nuisance items...

    @Moach: Sounds like a good idea. I look forward to seeing what you come up with.

    @DasPenuin85: The module is structured so that it can be used with any heat shield part that has a built-in heat animation. Just develop your 3D model and include an emissive animation. There are tutorials on this forum for how to do KSP compatible models and animations in Unity3D. Configure your animation model so that it "plays" from coldest to hottest. I just display the animation frame by frame, depending on the temperature that I calculate for the heat shield. Use my module’s "HeatShieldHeatAnimation" parameter in the part.cfg file to set the name of your heat animation.

    Also, MrPwner is working on a transparent texture for emissive animations. It is an impressive bit of work because, as far as I know, it has never been done before with any other mods in KSP. When he gets it working, he will add a transparent detached shock effect to the plugin.

    @Tommygun: I like your suggestion but I think the way to deal with parachute damage is in the parachute module itself. Parachute parts could have a parameter in the part.cfg file that sets the rated opening speed. Open it above that speed and it takes damage. If this were handled in the parachute module, then I wouldn't have to apply my cludge to destroy parachutes that open in the middle of the plasma trail...

    @Subsidal: I will add this to the list of bugs. I suspect that there's an additional function that I need to call to end the mission when I destroy the spacecraft.

  4. Updates:

    1. I've posted a new version of the plugin (v1.0.17.02) over on Kerbal.net.

    2. I have posted a video in the first page of this thread, showing this re-entry module in action.

    3. I've updated the Q&A section in the first page of this thread.

    Hopefully these will, collectively, help solve some of the issues people have been experiencing.

  5. i'll post it when i get the chance

    Can you please run your changes by me before you post a new version of the module? Feel free to ask HarvestR to get you my e-mail address from the forum member's database if you don't want to enable PMs on your account.

    I am happy to work together with you on improving this part module. Some of the changes that you are thinking about are already on my list (i.e. making the heat shield work as a decoupler) while other "problems" with the module are probably just issues of tweaking play balance.

    I expected that some changes would be required before the module was finalised. In fact, that is why I haven't made the plot showing the survivable re-entry corridor vs. re-entry speed yet.

  6. 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!

  7. 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.

  8. C4fk6.jpg

    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:

    q4YsO.png

    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

    functions.php?landing=mod_infographics&target=mod_signature&id=34

    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.

    e3Id4.png

    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.

  9. But I don't think the astronauts ever had the ability to calculate when or in what direction to burn for course changes. For that data they relied on computers 100%. There's no way they would have manually taken a sighting on the moon and said "Yeah, I think now's about the right time to fire for TLI. Hang on!" like we have to do without MechJeb.

    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.

  10. 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.

  11. I love your project but i think if you make heat effects tihs will be more realistic.

    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.

  12. 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.

  13. good on this kid for taking an interest in something that most 19 years wouldnt

    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.

  14. 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.

  15. lets see you do any thing more advanced i have yet to see any one doing free trajectorys around here other then one set of videos

    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.

  16. WOW! This just looks so cool! But what does the plugin do ATM?

    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!)

    oY5EN.jpg
×
×
  • Create New...