As mentioned on the forum, i plotted the current heatCurve and noticed some interpolation issues which i confirmed in an in game editor (because the plotter i use interpolates a bit differently than the game, so the plots don't exactly represent the ingame curves):

The issues can be seen before and after the steep slope where the curve gets wobbly.
Thus, i tried to create a new, smoother and yet simpler curve with less points, and came up with:

Now, because the ingame interpolation uses tangents and works a bit differently, i sadly need tangents for all the points except one, for that one the auto-calculated tangents of the game work fine.
The new curves in in game format look like this, in this case scaled down for the light shield:

	key = 0 0 0 0
	key = 310 12 0.08 0.08
	key = 350 32 1 1
	key = 530 600
	key = 590 640 0.12 0.12
	key = 2000 720 0 0

The two medium shield curves i have came up with are now 3.635 * the light curve for less headroom, and 3.75 * light curve for a bit more headroom. The important thing here is that the tangents need to also be scaled alongside the values. Thus, the the 3.75x curve for the medium shield with higher headroom would look like this:

	key = 0 0 0 0
	key = 310 45 0.3 0.3
	key = 350 120 3.75 3.75
	key = 530 2250
	key = 590 2400 0.45 0.45
	key = 2000 2700 0 0

I set the ablation effeciency to 32000 which seems to work fine.

As mentioned on the forum, i reduced the weights and ablator of the shields to match the apollo weight, the 3.75m medium shield for example is down from 600 to 450 ablator. This means the ablation weight is a bit more than the weight of the shield structure but roughly in the same area which seems good. This also leads to nicer values in the UI, eg the 1.25m light shield now has 25 ablator instead of 33.33333333. :)
The structural weight has gone down from 1 to 0.4 for the 3.75m medium shield, together with the 450 ablator that makes the 3.75m medium shield weight 850kg, about the same as the 3.9m apollo shield.

I also changed the weight scaling of the shield types, making the light shield weight half as much as the medium shield, because it also has half the ablator - i think the structure mass to ablator mass factor should roughly stay the same for the shields.

Edit: Some data from my testing with those curves:

Light 1.25m shield, tested with just a single mk-1 pod with a battery and parachute, total weight with light shield: ~940kg:

Medium 1.25m shield, tested with above curve with a bit more headroom:
First tests use mk-1 pod, ~1000kg weight including medium shield:

Now I added some additional weight to the medium tests, first a test with ~1500kg:

And another test with 2000kg:

Thanks for taking some time to play with the configs/values.

Looks like the basis for the system works for the most part -- too steep = explode from peak heating, too shallow = run out of ablator (and then explode from heat). Just need to tune exactly where the safe 'corridor' is by tuning the configs a bit.

One change I likely will make regarding the code-side of the heat-curves (and thus the config-specified values as well), is to rework them to use 0-1 as inputs, and 0-1 as outputs, with scalar values on either side. This is to allow for the curves to be used in an abstract manner -- simply create one curve, and use different scalars to effect the 'more or less headroom' bit of things.

Cleaning up the curve tangents is probably a good thing -- the existing curve data was brute forced from an excel plot of manually input data points, so 'rough' would be putting it nicely.

0-1 on the output side sounds good, i was thinking about that too, so you can just adjust one scalar to multiply the whole curve and don't have to adjust the curve itself. I'm not sure about the input side of things, though, if changing that helps aswell or is more confusing. For example, the current curves have their steep slopes at roughly 425-450, adding the 500 ablation start threshold you're right at ~922K, which was the ablation temperature for the apollo shield. :)
To be able to adjust a generic 0-1 input curve horizontally/from the input side, you would probably have to define/find out where the 50% y-point is on the curve and warp the curve to move that value left or right based on a scalar, which wouldn't be a simple multiplication as it is for the output case, if you understand what i'm trying to say.
Of course it might also be that i'm thinking a bit too complicated. :)

Reworked the above curve to use a 0-1 input/output domain:

Will work on adapting the code a bit today, and hopefully be able to do some testing/etc on it this evening.

key = 0 0 0 0
key = 0.155 0.01666667 0.08 0.08
key = 0.175 0.04444445
key = 0.265 0.8333333
key = 0.295 0.8888889 0.12 0.12
key = 1 1 0 0

Hmm. strangely, even though the unity-editor says I should have a good curve, the input/output actual plots as (note how it dips negative in the beginning) (this is actual output from the float curve as it is used in-game):

I get this same effect whether I use the curve I posted, or the later one with the scaled tangents. Thinking I might have to add 2 more keys to smooth out some of the oddities that are going on.

Sounds good. :)
The tangents need to be scaled aswell, resulting in:

key = 0 0 0 0
key = 0.155 0.01666667 0.22222 0.22222
key = 0.175 0.04444445 2.77778 2.77778
key = 0.265 0.8333333
key = 0.295 0.8888889 0.33333 0.33333
key = 1 1 0 0

(it doesn't make a huge difference but will look a tiny bit nicer :)

Interesting - i did get similar results with my curve when i didn't use tangents, but the tangents fixed the problem (at least judging from ingame debug output, where i could see it dipping negative without tangents but worked fine with them).
If you can give me a test version with debug output enabled to get the data in your screenshot, i'd be happy to try to analyze the problem - i'm really curious about what's going on here.

Hmm... Looking at the code a bit more, I had the 'default' curve specified with improper tangents for the 2nd key (0.8 rather than the intended 0.08). When plotting with the 0.8 tangents, it does in fact give the slightly negative curve in the beginning.

Makes me think that for some reason the curves aren't being loaded properly from the heat-shield types definitions, as I'm sure that I have the tangents properly defined in those configs.

I'll have to do some more investigation on this tonight to see if the curves were even being loaded properly.

Have also added in some code for testing that will track the peak heat, flux, and g-force experienced during a flight. This should all aid in tuning for specific use cases / craft setups / re-entry profiles.

One bit that I'm going to have to figure out is what the max g-force should be for a 'standard' re-entry. This will be one of the biggest determining factors in the range of usable re-entry profiles.

I'm just looking at this right now - with the tangents from my post, i don't get any negative part in the beginning, it's all positive. I do however get a slight overshoot on that steep slope that can also be seen in your screenshot, investigating right now if a slight tweak to the tangents can fix that.

This .dll : https://github.com/shadowmage45/SSTULabs/raw/heatShieldUpdates2/GameData/SSTU/Plugins/SSTUTools.dll

Should have the debug-output code in place. It runs during the modules OnStart, and simply calls the heat-curves 'Evaluate()' method with a series of inputs from 0 to 1 in 0.001 increments. So all you need to do is load the part in the editor (or flight scene) to get the debug output, no need to go through an actual re-entry.

Using stock code to load and construct the FloatCurves, so perhaps there is some stock problem with properly assigning tangents or tangent modes (not sure the latter even applies to runtime use, might be an editor-only thing).

Thanks, that updated curve seems to be quite a bit smoother.

Currently working on an integration stability problem.... that I don't think I'll be able to solve as my code isn't properly integrated with the rest of the thermo simulation (always going to be re-active). Long-standing problem though, has existed for quite some time.

I -think- the problem is related to the heat curve steep ramp-up slope -- at some points in the slope the output overpowers the heating, and the temp drops; heat climbs, output increases, output overpowers heating, and the temp drops again.

Going to play around with a slightly different curve setup, but attempt to keep the same active/peak area (900k-1200k). Thinking that if the curve isn't so steep, it should add a bit more stability to the active range.

Small excerpt of the instability as noted in the log

[LOG 12:45:11.390] MHSDebug: In temp: 1014.6878 : in flux 0538.0268 : flux out: 0609.7695 : delta: -0071.7426 : ext: 6504.1318 : atm: 0238.4393
[LOG 12:45:11.414] MHSDebug: In temp: 1014.7108 : in flux 0538.1412 : flux out: 0609.9855 : delta: -0071.8443 : ext: 6504.1113 : atm: 0238.4479
[LOG 12:45:11.442] MHSDebug: In temp: 1014.7336 : in flux 0538.2466 : flux out: 0610.2009 : delta: -0071.9543 : ext: 6504.0903 : atm: 0238.4564
[LOG 12:45:11.444] MHSDebug: In temp: 1014.7562 : in flux 0538.3542 : flux out: 0610.4153 : delta: -0072.0611 : ext: 6504.0698 : atm: 0238.4649
[LOG 12:45:11.469] MHSDebug: In temp: 1014.7789 : in flux 0538.4655 : flux out: 0610.6292 : delta: -0072.1636 : ext: 6504.0494 : atm: 0238.4735
[LOG 12:45:11.514] MHSDebug: In temp: 1014.8017 : in flux 0538.5815 : flux out: 0610.8435 : delta: -0072.2620 : ext: 6504.0283 : atm: 0238.4820
[LOG 12:45:11.516] MHSDebug: In temp: 1014.8246 : in flux 0538.6993 : flux out: 0611.0588 : delta: -0072.3595 : ext: 6504.0079 : atm: 0238.4905
[LOG 12:45:11.539] MHSDebug: In temp: 1014.8477 : in flux 0538.8178 : flux out: 0611.2753 : delta: -0072.4575 : ext: 6503.9874 : atm: 0238.4991
[LOG 12:45:11.569] MHSDebug: In temp: 1014.8707 : in flux 0538.9278 : flux out: 0611.4920 : delta: -0072.5642 : ext: 6503.9664 : atm: 0238.5076
[LOG 12:45:11.571] MHSDebug: In temp: 1014.8936 : in flux 0539.0344 : flux out: 0611.7082 : delta: -0072.6738 : ext: 6503.9454 : atm: 0238.5161
[LOG 12:45:11.594] MHSDebug: In temp: 1014.9163 : in flux 0539.1419 : flux out: 0611.9233 : delta: -0072.7815 : ext: 6503.9249 : atm: 0238.5247
[LOG 12:45:11.618] MHSDebug: In temp: 1014.9390 : in flux 0539.2542 : flux out: 0612.1381 : delta: -0072.8839 : ext: 6503.9039 : atm: 0238.5332
[LOG 12:45:11.643] MHSDebug: In temp: 1014.9619 : in flux 0539.3686 : flux out: 0612.3529 : delta: -0072.9843 : ext: 6503.8834 : atm: 0238.5417
[LOG 12:45:11.644] MHSDebug: In temp: 1020.9369 : in flux 0539.4844 : flux out: 0641.0314 : delta: -0101.5470 : ext: 6503.8624 : atm: 0238.5502
[LOG 12:45:11.669] MHSDebug: In temp: 1020.3509 : in flux 0536.9261 : flux out: 0652.5350 : delta: -0115.6089 : ext: 6503.8414 : atm: 0238.5588
[LOG 12:45:11.697] MHSDebug: In temp: 1019.6373 : in flux 0537.2937 : flux out: 0654.8429 : delta: -0117.5493 : ext: 6503.8209 : atm: 0238.5673
[LOG 12:45:11.720] MHSDebug: In temp: 1018.9212 : in flux 0537.7213 : flux out: 0652.5518 : delta: -0114.8306 : ext: 6503.7999 : atm: 0238.5758
[LOG 12:45:11.748] MHSDebug: In temp: 1018.2633 : in flux 0538.1515 : flux out: 0648.2507 : delta: -0110.0992 : ext: 6503.7794 : atm: 0238.5844
[LOG 12:45:11.750] MHSDebug: In temp: 1017.6880 : in flux 0538.5577 : flux out: 0643.3484 : delta: -0104.7907 : ext: 6503.7584 : atm: 0238.5929
[LOG 12:45:11.795] MHSDebug: In temp: 1017.2005 : in flux 0538.9278 : flux out: 0638.5711 : delta: -0099.6432 : ext: 6503.7374 : atm: 0238.6015
[LOG 12:45:11.797] MHSDebug: In temp: 1016.7961 : in flux 0539.2611 : flux out: 0634.2568 : delta: -0094.9957 : ext: 6503.7163 : atm: 0238.6100
[LOG 12:45:11.847] MHSDebug: In temp: 1016.4660 : in flux 0539.5595 : flux out: 0630.5308 : delta: -0090.9713 : ext: 6503.6953 : atm: 0238.6186
[LOG 12:45:11.849] MHSDebug: In temp: 1016.2002 : in flux 0539.8311 : flux out: 0627.4058 : delta: -0087.5747 : ext: 6503.6748 : atm: 0238.6271
[LOG 12:45:11.895] MHSDebug: In temp: 1015.9884 : in flux 0540.0722 : flux out: 0624.8393 : delta: -0084.7672 : ext: 6503.6538 : atm: 0238.6357
[LOG 12:45:11.897] MHSDebug: In temp: 1015.8216 : in flux 0540.2923 : flux out: 0622.7661 : delta: -0082.4738 : ext: 6503.6328 : atm: 0238.6442
[LOG 12:45:11.947] MHSDebug: In temp: 1015.6917 : in flux 0540.4893 : flux out: 0621.1146 : delta: -0080.6254 : ext: 6503.6118 : atm: 0238.6528
[LOG 12:45:11.949] MHSDebug: In temp: 1015.5920 : in flux 0540.6723 : flux out: 0619.8169 : delta: -0079.1446 : ext: 6503.5907 : atm: 0238.6612
[LOG 12:45:11.994] MHSDebug: In temp: 1015.5168 : in flux 0540.8439 : flux out: 0618.8124 : delta: -0077.9684 : ext: 6503.5697 : atm: 0238.6698
[LOG 12:45:11.996] MHSDebug: In temp: 1015.4614 : in flux 0541.0060 : flux out: 0618.0484 : delta: -0077.0424 : ext: 6503.5487 : atm: 0238.6783
[LOG 12:45:12.046] MHSDebug: In temp: 1015.4220 : in flux 0541.1544 : flux out: 0617.4800 : delta: -0076.3256 : ext: 6503.5276 : atm: 0238.6869
[LOG 12:45:12.048] MHSDebug: In temp: 1015.3953 : in flux 0541.2941 : flux out: 0617.0698 : delta: -0075.7757 : ext: 6503.5066 : atm: 0238.6954
[LOG 12:45:12.119] MHSDebug: In temp: 1015.3789 : in flux 0541.4311 : flux out: 0616.7872 : delta: -0075.3560 : ext: 6503.4856 : atm: 0238.7040
[LOG 12:45:12.121] MHSDebug: In temp: 1015.3708 : in flux 0541.5660 : flux out: 0616.6079 : delta: -0075.0419 : ext: 6503.4646 : atm: 0238.7125
[LOG 12:45:12.215] MHSDebug: In temp: 1015.3694 : in flux 0541.6915 : flux out: 0616.5112 : delta: -0074.8196 : ext: 6503.4435 : atm: 0238.7211
[LOG 12:45:12.217] MHSDebug: In temp: 1015.3731 : in flux 0541.8129 : flux out: 0616.4802 : delta: -0074.6673 : ext: 6503.4225 : atm: 0238.7296
[LOG 12:45:12.263] MHSDebug: In temp: 1015.3810 : in flux 0541.9352 : flux out: 0616.5024 : delta: -0074.5672 : ext: 6503.4009 : atm: 0238.7382
[LOG 12:45:12.264] MHSDebug: In temp: 1015.3925 : in flux 0542.0586 : flux out: 0616.5676 : delta: -0074.5090 : ext: 6503.3804 : atm: 0238.7467
[LOG 12:45:12.311] MHSDebug: In temp: 1015.4067 : in flux 0542.1800 : flux out: 0616.6674 : delta: -0074.4874 : ext: 6503.3588 : atm: 0238.7552
[LOG 12:45:12.313] MHSDebug: In temp: 1015.4232 : in flux 0542.3032 : flux out: 0616.7953 : delta: -0074.4920 : ext: 6503.3378 : atm: 0238.7638
[LOG 12:45:12.360] MHSDebug: In temp: 1021.4186 : in flux 0542.4164 : flux out: 0645.5891 : delta: -0103.1727 : ext: 6503.3168 : atm: 0238.7723
[LOG 12:45:12.362] MHSDebug: In temp: 1020.8256 : in flux 0539.8394 : flux out: 0657.1105 : delta: -0117.2711 : ext: 6503.2958 : atm: 0238.7808

More log bits....

[LOG 12:45:11.618] MHSDebug: In temp: 1014.9390 : in flux 0539.2542 : flux out: 0612.1381 : ext: 6503.9039
[LOG 12:45:11.643] MHSDebug: In temp: 1014.9619 : in flux 0539.3686 : flux out: 0612.3529 : ext: 6503.8834
[LOG 12:45:11.644] MHSDebug: In temp: 1020.9369 : in flux 0539.4844 : flux out: 0641.0314 : ext: 6503.8624
[LOG 12:45:11.669] MHSDebug: In temp: 1020.3509 : in flux 0536.9261 : flux out: 0652.5350 : ext: 6503.8414

[LOG 13:07:02.814] MHSDebug: In temp: 1016.2895 : in flux 0546.0182 : flux out: 0625.1288 : ext: 6502.6319 : shock: 03370.839 : vel: 2094.8322 : alt: 051739.22 : dens: 00.000000 : dyn: 00.365000
[LOG 13:07:02.864] MHSDebug: In temp: 1016.3123 : in flux 0546.1325 : flux out: 0625.3448 : ext: 6502.6103 : shock: 03370.832 : vel: 2094.8229 : alt: 051736.71 : dens: 00.000000 : dyn: 00.365000
[LOG 13:07:02.866] MHSDebug: In temp: 1022.2944 : in flux 0546.2450 : flux out: 0682.9006 : ext: 6502.5887 : shock: 03370.826 : vel: 2094.8136 : alt: 051734.20 : dens: 00.000000 : dyn: 00.365000
[LOG 13:07:02.923] MHSDebug: In temp: 1021.3271 : in flux 0543.6668 : flux out: 0673.4943 : ext: 6502.5671 : shock: 03370.819 : vel: 2094.8042 : alt: 051731.69 : dens: 00.000000 : dyn: 00.365000

[LOG 13:17:08.777] MHSDebug: In temp: 1014.7817 : in flux 0538.2943 : flux out: 0610.8698 : ext: 6504.1983 : shock: 03371.325 : vel: 2095.5072 : alt: 051913.17 : dens: 00.000162 : dyn: 00.354605
[LOG 13:17:08.809] MHSDebug: In temp: 1014.8046 : in flux 0538.4074 : flux out: 0611.0860 : ext: 6504.1772 : shock: 03371.319 : vel: 2095.4983 : alt: 051910.67 : dens: 00.000162 : dyn: 00.354750
[LOG 13:17:08.834] MHSDebug: In temp: 1020.7713 : in flux 0538.5209 : flux out: 0668.1059 : ext: 6504.1568 : shock: 03371.313 : vel: 2095.4894 : alt: 051908.17 : dens: 00.000162 : dyn: 00.354895
[LOG 13:17:08.837] MHSDebug: In temp: 1019.8125 : in flux 0535.9737 : flux out: 0658.8399 : ext: 6504.1358 : shock: 03371.307 : vel: 2095.4805 : alt: 051905.67 : dens: 00.000162 : dyn: 00.355040

[LOG 13:28:24.897] MHSDebug: In temp: 1015.5390 : in flux 0541.6530 : flux out: 0618.0181 : ext: 6504.1920 : shock: 03371.439 : vel: 2095.5037 : alt: 051844.73 : dens: 0.0001634 : dyn: 0.3586699
[LOG 13:28:24.899] MHSDebug: In temp: 1015.5614 : in flux 0541.7586 : flux out: 0618.2295 : ext: 6504.1716 : shock: 03371.433 : vel: 2095.4946 : alt: 051842.23 : dens: 0.0001634 : dyn: 0.3588165
[LOG 13:28:24.947] MHSDebug: In temp: 1021.5227 : in flux 0541.8690 : flux out: 0675.3933 : ext: 6504.1500 : shock: 03371.427 : vel: 2095.4855 : alt: 051839.72 : dens: 0.0001635 : dyn: 0.3589629
[LOG 13:28:24.949] MHSDebug: In temp: 1020.5612 : in flux 0539.3098 : flux out: 0666.0726 : ext: 6504.1289 : shock: 03371.420 : vel: 2095.4764 : alt: 051837.22 : dens: 0.0001636 : dyn: 0.3591092

[LOG 13:36:48.978] MHSDebug: In temp: 1014.7589 : in flux 0538.4840 : flux out: 0610.6553 : ext: 6504.0494 : shock: 03371.261 : vel: 2095.4433 : alt: 051907.08 : dens: 0.0001617 : dyn: 0.3549432
[LOG 13:36:49.119] MHSDebug: In temp: 1014.7817 : in flux 0538.5928 : flux out: 0610.8700 : ext: 6504.0283 : shock: 03371.255 : vel: 2095.4344 : alt: 051904.58 : dens: 0.0001617 : dyn: 0.3550882
[LOG 13:36:49.121] MHSDebug: In temp: 1020.7556 : in flux 0538.7007 : flux out: 0667.9541 : ext: 6504.0079 : shock: 03371.249 : vel: 2095.4254 : alt: 051902.08 : dens: 0.0001618 : dyn: 0.3552332
[LOG 13:36:49.178] MHSDebug: In temp: 1019.7953 : in flux 0536.1474 : flux out: 0658.6746 : ext: 6503.9874 : shock: 03371.243 : vel: 2095.4165 : alt: 051899.58 : dens: 0.0001619 : dyn: 0.3553784

It almost seems as if there is something strange going on with the stock thermal simulation, as everything is stable and smooth up to a fairly consistent point. At this point, the skin temp suddenly increases, and the oscillations start.

Going to add more debugging to see what/where this starts at. Might be altitude related, might be air density related, or even dynamic pressure. Does not appear to be related to external temps, or skin temps.

Interesting -- I must have either messed up my tangents in the configs somehow, or the code for loading them is not quite correct. Though if it loaded and used your specified tangents, it seems more likely that my configs were incorrect.

This though, only brings up the question of why the KSP-float-curve editor for Unity is giving different results than those seen in-game.

I'll likely add some quick/dirty methods to output a .png plot of any given float-curve. Will at least remove the step of having to import log-data into excel/other plotting programs. Should make it faster to debug the curves.

Thanks to your debugging dll i could come up with a refined curve which looks quite nice i guess. I couldn't really see those small overshoots of the old curve in the tiny ingame editor, so being able to plot that debug output helped.
The new curve, plotted from debugging output:

Curve data:

	key = 0 0 0 0
	key = 0.15 0.02 0.4 0.4
	key = 0.175 0.05 2.5 2.5
	key = 0.265 0.83 4 4
	key = 0.295 0.89 0.34 0.34
	key = 1 1 0 0

No idea why you get different results. The ingame editor i use seems to show the curve correctly, it's just damn small and you can't spot tiny details with it.

Well, i've noticed this oscillation aswell, and one reason why i made the new curve slightly less steep than the original was to be a bit gentler to the simulation/try to reduce this oscillation a bit. In the end, it shouldn't really matter though, as long as the steep part where it is oscillating is not close to the max temp where the shield explodes, or am i missing something?

Yeah, after playing with this for a few hours now (far too many...) I've determined that whatever the root cause of it is an inconsistency in the stock code/thermo model. Nothing that I'm doing in the code would cause a consistent ~6k increase in skin temperature, and it is this sudden increase that is causing the oscillations to start -- my code is functioning exactly as it should, but something in the stock code is causing the temps to jump ~6k at fairly regular intervals.

In the end, I don't think it will really effect anything; it hasn't so far. At the point where the heat-shield would be getting to 'explody' temps, it is already past the steep part on the heat curve, and onto the long gradual tail. I just don't like seeing instability in the code/output.

So... now onto the actual balancing work. Going to start running some various re-entry profiles to find where the g-loading is for the various Ap/Pe setups. From there I'll just have to tune the parameters on the shield to keep it working within the intended re-entry range.

If you really wanted, you could implement a smoothing/averaging filter to smooth the temperature values before calculating the flux values (or smooth the flux values themselves). An exponential smoothing/moving average filter would probably be suitable. But as i said, i'd probably not do it unless the oscillation proves to be a problem. This would however probably be simpler than changing the curve, and would address the problem at its root - the coarse simulation intervals. :)

I don't necessarily think that the problem I'm looking at is course-simulation intervals -- rather that there is something in the stock thermo code that is erroneously applying spikes of heating. But either way, some input smoothing might help with the oscillation severity and periodicity.

Will probably put some simple input filtering in place, and perhaps some output filtering as well. Smoothing shouldn't hurt anything, and will probably give a more natural seeming response to the functions.

Will spend a bit more time investigating to see if I can track down where/why the temps are spiking consistently; would really like to find the root cause of the problem if possible (before moving onto actual balancing work). When testing with the stock heat shield, it doesn't have any oscillations in its temps -- but it also lets the temp go much higher than I would think appropriate (1800k+temps are normal with the stock heat shield).

As to the actual balancing -- not quite sure where to start, as I don't have much prior knowledge as to what acceptable re-entry profiles look like. Haven't been able to find much data on the subject aside from a very few blurbs on Apollo and Soyuz setups, and even those have been a bit light on factual/statistical information.

Mostly I'm interested in g-loading, temps (shock, heat-shield), and overall profile (steep vs. shallow vs. non-ballistic/guided). From that information I should be able to derive a set of parameters for the range of usable re-entry setups, and from there derive what the heat shield stats need to be at in order to work effectively under the chosen scenarios.

I'm thinking something like

• Max G-load - 8 -- steep ballistic re-entry seen by Soyuz during malfunctions, but survivable. This determines lowest possible Pe for a given starting Ap and craft setup/ballistic coefficient.
• Max Pe-- maximum Pe that results in a single-orbit capture.
• The 'valid range' should be nearly anything inbetween those two points.
• medium/heavy/etc.. should allow follow the same rules, but have a higher maximum orbital velocity

Finally a bit of progress; have narrowed it down to 'skin conduction flux' going to 0 for a tick.

These are the skn: values in the log below:

[LOG 17:28:51.864] MHSDebug | tmp: 1013.80 | ext: 6504.91 | shk: 3371.51 | atm: 0238.12 | alt: 52012.0 | dns: 00.0002 | vel: 2095.81 | mch: 0006.78 | dyn: 00.3489 | exp: 01.8975 | cnv: 0622.03 | cnd: -0047.68 | rad: -0040.56 | prv: -0300.72 | hsf: 0601.65 | skn: -0358.18 | snn: 0086.08 | skk: 0000.00 |
[LOG 17:28:51.897] MHSDebug | tmp: 1013.82 | ext: 6504.89 | shk: 3371.50 | atm: 0238.12 | alt: 52009.5 | dns: 00.0002 | vel: 2095.80 | mch: 0006.78 | dyn: 00.3491 | exp: 01.8975 | cnv: 0622.14 | cnd: -0047.68 | rad: -0040.57 | prv: -0300.82 | hsf: 0601.86 | skn: -0358.19 | snn: 0086.08 | skk: 0000.00 |
[LOG 17:28:51.914] MHSDebug | tmp: 1019.79 | ext: 6504.86 | shk: 3371.50 | atm: 0238.13 | alt: 52007.0 | dns: 00.0002 | vel: 2095.79 | mch: 0006.77 | dyn: 00.3492 | exp: 01.8975 | cnv: 0622.25 | cnd: -0047.68 | rad: -0040.57 | prv: -0300.93 | hsf: 0658.64 | skn: 0000.00 | snn: 0086.08 | skk: 0000.00 |
[LOG 17:28:51.932] MHSDebug | tmp: 1018.84 | ext: 6504.84 | shk: 3371.49 | atm: 0238.14 | alt: 52004.5 | dns: 00.0002 | vel: 2095.79 | mch: 0006.77 | dyn: 00.3493 | exp: 01.8975 | cnv: 0620.79 | cnd: -0047.68 | rad: -0041.65 | prv: -0329.32 | hsf: 0649.44 | skn: -0367.23 | snn: 0086.90 | skk: 0000.00 |

As the flux is normally negative, representing heat leaving the skin, when it suddenly becomes zero, it causes the temp to spike (less heat removed = increase in temp).

Doing a quick investigation pass to see if it could even remotely be caused by my code, which doesn't seem likely. If it is not something in my code/something that I can fix, I'll see about implementing some smoothing/filtering on inputs.

Tested the parts with integrated heat shields (SC-A/B/C) and there are no temp spikes during reentry. This would back up the cause being something in the skin conduction simulation.

Will work on doing some input smoothing and see what the effect is (better/worse/weird).

And then, finally,.... on to the balancing... :)

Going to make one more attempt this evening at tracking down where the temp problems are occurring. Doing this through adding additional per-tick debug output of every publicly accessible variable that has anything to do with skin temps.

-Something- is causing the temperature to spike. Really would like to know what this is, and what I can do about it.

Nice. If you are sure it's not caused by your code, maybe it should be reported as a bug to squad?
Good job anyway. :)

After many hours spent testing re-entry on the stand-alone heat shield, I think I have a decent re-balanced setup in place.

The craft were setup with a 1t per m2 of heat-shield loading, with all shields tested at the same time on a properly massive craft (75m^2 surface area, 75t craft).

I've since tweaked the efficiency downards a slight bit, so there should be less ablator remaining.

Have not yet tested or configured the stand-alone parts...but the only thing that can really be tweaked on them is the ablator amount and efficiency (the curves are set the same as the stand-alone MHS part).

Edit: Bit of work on the stand-alone parts...

Generally those mean 'test not run'. If I ran the test, but it ran out of ablator... I tweaked config values until it at least made it through.

The SC-B was modified from the posted values to have higher efficiency -- it should sit at about 80% used as the rest.
The SC-V was modified from the posted values to have lower efficiency -- it should also sit at about 80% used.

The one area I wasn't able to do much/any testing on was inter-planetary re-entry -- mostly because of the massive amount of time needed to do each test (need to get the craft to Duna/Eve, wait for transfer window, etc). From the few tests that I did using the Mun/Minmus return on the heavy/ex-heavy shields, they should be good for plenty of abuse for inter-planetary speeds.

Would still like to do some testing on those specific variants though (heavy/extra-heavy) for all parts/sizes, just for completeness sake (and to make sure there are no surprises the first time I try and return from Duna/Eve...).

You should be able to grab the current setup from the 'dev' branch if you wanted to try out a few things. It should include all of the recent config and plugin changes, and should give results very similar to what is posted above.

What do the empty lines with 100% ablator used mean, test not run or shield exploded?