[0.17] Re-entry Heat Module and Mk-1 Pod Heat Shields

[mnnm1234]

Are you going to make a 1-2 thing?

[Nicolas411]

Does this work with 0.15?

[Stu82r]

Just tried this mod with the mk1 pod and thought I would add to what others have already stated. Placed the sheild with the final decoupler stage before the pod and parachute. The red integrity bar popped up and I waited for re-entry. The re-entry effect started and seemed to be in full effect when I was transported to oblivion (black screen at the 555555 alt). Went to the tracking station without ending the flight and the only flight running was this one. Clicked to reinitialise the flight and it had turned into a small RCS fuel tank on sun escape trajectory??? Tried to replicate this again for some screenshots but no success after 3 attempts. Thanks for the mod and I hope you can iron this out.

[Moach]

the console says a lot of things about references not being set to an instance of an object.... i suspect there's something unforeseen going on with whatever objects are getting destroyed there (or could there be such thing?)

lets have a look at code, shall we?

be right back...

[inferno34s]

the console says a lot of things about references not being set to an instance of an object.... i suspect there's something unforeseen going on with whatever objects are getting destroyed there (or could there be such thing?)

lets have a look at code, shall we?

be right back...

yeah I noticed that the source code was included, sadly I'm not a programer / addon maker so I would not know what to look for

[Moach]

hmm, found a possible weak spot on code where a whole bunch of what appear to be critical bits of logic don't get initialized unless the shield is activated before use...

an inconvenient oversight, if this is the case, i had not considered staging the heatshield for activation along with the pod decoupler....

let's see what happens if i rewire the functions here so they ignore staging events....

ok, that made a difference....

but surely this was like it was for a reason, and that reason is that many aspects of heat simulation cannot be applied if the shield is not exposed...

another thing is that there is also an UI thingy that shows reentry info and whatnot - you typically don't want that hanging about the screen until you need it, right?

i'm getting there....

found another potential failure point where a parachute was being referenced without proper checking of a possible null condition.... that's a recipe for problems, in my experience... let's see if fixing this does the trick

yes it did! - this time the whole thing simply exploded violently... i should have expected this, my angle was quite a bit unreasonable... but anyways, still had other problems with whatever was left of the ship....

now i have removed the parachute check code... this is moot since they don't really deploy under reentry conditions anyways, so having them active should be a non-factor

getting closer now!

the parachute code was a large point of failure - it basically expected a default-type parachute to be attached directly onto the pod (which is a no-go, my test pod has 3 radial chutes from the cyclone pack)

removed the whole thing... parachutes are no longer a part of heatshield logic

more possible faults were fond.... parts on detached remaining stages were not getting properly disassembled (aka: blown to bits) - instead the vessel was being destroyed by a call to the OnDestroy event... not sure if this automatically includes burning down any parts there....

well, it does now! - parts in detached stages will explode individually, so lets see if things go better this time...

decided to build a proper test scenario for this.... lets see how it plays out

harvester isn't on skype yet.... when he come on i'll see about that API and what exactly is the best way to destroy those chunks of debris....

boom!

discovered i oughta be more careful of what parts get blasted upon reentry start.... there's an automated debris elimination function that takes care of loose bits, but since it wasn't rigged to ignore commandable vessels, well... it included my test pod....

lets see now...

Edited September 24, 2012 by Moach

[Moach]

investigation has proven successful thus revealing the cause of the disastrous bugs encountered!

testing now for fix effectiveness

further tests for addon compatibility are in progress also...

the fix was effective! - the reentry simulation now works!

compatibility with mechjeb, flight engineer and other mods still await experiments....

found a logic inconsistency on the delta-time calculation, it accounted for elapsed time between updates, but then proceeded to multiply time-dependent values by it without first inverting this value to reciprocal form....

the result was a drastically over-sensitive simulation, prone to overheating upon the first moments of reentry....

lets see if we have it better now...

Edited September 24, 2012 by Moach

[PakledHostage]

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.

Edited September 24, 2012 by PakledHostage

[togfox]

It is easy to be critical of new code modules

I don't think a single person is being critical. Just very enthusiastic.

[PakledHostage]

I don't think a single person is being critical. Just very enthusiastic.

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.

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

[Moach]

hey! nice to hear from ya!

yes i was tweaking around your code... broke some things fixed some others, got a lot of suggestions too!

you said "sorry if i didn't meet you expectations" lol! quite on the contrary - your plugin is so formidable i could not help myself but to try and help to whatever extent possible, that's how awesome this is

i spent the morning talking on skype with harvester and tweaking this thing - some progress got done which is definitely worth sharing!

things i've noticed and actions taken:

* delta-time code was "inverted" - there was a problem with the deltaT variable, it represented the interval between frames, not the scalar by which time-dependant values should be multiplied... this was solved by replacing the calculated value with the built-in TimeWarp.deltaTime feature (so convenient to be on the phone with the guy who coded it)

* heat propagation and soaking seemed off with the given formula - replaced the calculated velocity input with the built-in vessel.srf_velocity property, which is more concise with the inner workings of the game and most reliable way of retrieving this information...

but most relevant here, HarvesteR told me the terms atmPressure and atmDensity in the API have been somehow switched (mess from older code) - and thus, the whole set of equations would generate immense heat values, making shallow-angle reentries akin to suicide

still working on it... but this has been generally fixed, and a highly believable shock temperature model has been achieved by simply multiplying the square of the mach number by the actual velocity in m/s

* the heatshield only works after activation, makes sense - but feels inconvenient as this is easy to miss on construction... my plan is to make the part class an extension of a decoupler, so it separates the pod and begins "heatshielding" all at once

* learned that for some reason my receiving of PM's is disabled - suspect this blunder is to blame on the forum engines changeover.... plan to re-enable it as soon as this reply is posted

* redid the destruction logic so the integrity check only flags a doom condition, at the end of the update pass, the update callback checks this flag and applies the proper punishment as required, this eliminating later functions running on defunct vessels before the end of a step

* modified the debris mitigation routines to work by exploding all the parts on the given vessel, ignoring commandable vessels so the pod behind the heatshield doesn't suffer a very unpleasant fate

this allows for the destruction of other plugin parts by a common and familiar logic (everything expects getting blown up in KSP) - reducing the potential for compatibility issues upon reentry logic startup

* changed the maximum tolerated temperature to something a little more forgiving, making interplanetary arrivals no longer equivalent of certain vehicle vaporization

the next step then would be to have the module check into all other vessels, regardless of the heatshield part being installed on any, and applying a general solution for those bits that dare venture in atmosphere without slowing down first....

i think i can be done, possibly... but also relevant would be to properly ease back the drag coefficient as the mach number increases past 1.0, which is how it plays out in the real world... sonic booms would be nice to have too

thanks for starting this project! i hope we can together take it up to the next level (and maybe later harvester could then let us plug it in for good, if it performs well enough)

cheers!

[Alex6511]

the next step then would be to have the module check into all other vessels, regardless of the heatshield part being installed on any, and applying a general solution for those bits that dare venture in atmosphere without slowing down first....

As a user I'd rather not have it enabled by default, sometimes I don't want full realism for my ships, because after all this is a game, not a simulator, while at other times I do want the most realism possible, in which case I would use this mod.

If you meant something else and I misunderstood you then sorry, but I'm just saying it would be nice if it was only enabled on ships we wanted it to be enabled on, similar to mechjeb, RC mod, carts, Spacebuilding, and docking.

[Sbowyer28]

Moach did you send the Bug fix to Hostage, Or is it already posted?

[Moach]

it's actually a simulator more than it's a game, i think.... but well, you're right - it didn't occur to me that the optional nature of this setup could be enjoyed by many, and serve as a difficulty level adaptation device

i shall even suggest to HarvesteR that when those things are built into the game, they are each made optional - so players can customize their experience on a per-scenario basis (different saves, different rules)

edit:

i have not posted or sent any of my tweakings yet... i had to leave in a hurry for work and there were dishes that require washing (and most still do) on my kitchen sink.... so i left it all on my home rig safely guarded by my vicious* bulldog

*by "vicious" i really mean: "loves everybody, licks faces"

i'll post it when i get the chance

cheers

Edited September 24, 2012 by Moach

[Subcidal]

As a user I'd rather not have it enabled by default, sometimes I don't want full realism for my ships, because after all this is a game, not a simulator, while at other times I do want the most realism possible, in which case I would use this mod.

If you meant something else and I misunderstood you then sorry, but I'm just saying it would be nice if it was only enabled on ships we wanted it to be enabled on, similar to mechjeb, RC mod, carts, Spacebuilding, and docking.

Then enable and disable the plugin on different saves or something.

Don't discourage the man, That would be awesome. Please do apply it to all crafts.

[PakledHostage]

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.

[Alex6511]

Then enable and disable the plugin on different saves or something.

Don't discourage the man, That would be awesome. Please do apply it to all crafts.

Thats exactly what I asked for. >_>

A way to disable it for certain missions, if you want to.

Its actually an incredibly important function for some people.

EDIT: Note removing the plugin from your directory to disable it simply isn't practical for some people.

[Moach]

Can you please run your changes by me before you post a new version of the module?

roger that, i'll let you have a look at the revisions i made and post it at your discretion - if you have any questions, feel free to ask too - i'm here to help

cheers!

[Sbowyer28]

This update wont cause unbearible lag will it?

[PakledHostage]

I expect it will be more efficient. I am happy to have Moach's input on this project. His obvious expertise and his direct connection with HarvestR make him an invaluable resource. I am sure he can improve it in ways that I couldn't do on my own.

[Sbowyer28]

It's good that Dev's are taking this serious, This mod is as good as the docking mod!!!!!

[Oicani]

Yep, I'm happy to see the modders doing what Squad isn't

[Sbowyer28]

I wasn't implying that at all... Squad is a company of I think about 20 people and there doing there best to keep up with what we want....

[PakledHostage]

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.

Edited September 25, 2012 by PakledHostage