Napoleon440

Yeah, I've got Real Heat and have been running off the dev version of SD. I was hoping to find a way that felt a little less "cheaty". I've been looking for way to raise the max amount of ablator on heat shields so they just hold more, or reducing the rate it burns off. In both instances, mass would be added proportionally to offset the change making it "not cheaty". Anyway, that's just me. I'm one of the types that likes the added challenge of a 6.4x scale, but isn't quite ready to tackle RSS/RO. Plus, I really do like the stock system and parts.

The only other issue I've had is re-entry is absolutely killing me. Ablator is burning up (200 units on the procedural heat shields) on re-entry just from low orbit on my 6.4x scale while still pulling almost lethal G's with Deadly Re-Entry. I was digging through RO-Mini to see how it's handled there since I wasn't having the issue when I tinkered with RSS recently. I was going to try and add something like this to see if it helped: // Heat shields @PART[*]:HAS[@MODULE[ModuleAblator]] { @MODULE[ModuleAblator] { @lossConst *= 0.1 //I'm thinking should be 1/x where x is one of the SD config values } } Haven't had a chance to actually test it yet, but was going to check it out later tonight.

I used to think I was smart until I started playing KSP. I guess the only question I have left is, should the daylengthmultiplier value be tied to one of the other multipliers since leaving it as-is causes the problem, or is the workaround with atmo height a better fix. Seems like messing with day length could have some [un]intended consequences for synchronous orbits among other things.

That seems to have done the trick as well. Any idea why rotational period would cause the problem?

Yep, just doing some trial and error checking the results in the Module Manager cache, I've been able to confirm that with both lines commented out, it defaults to 100k, and then with an Atmosphere value of 1.285, it moves to 128.5k. In fact, it looks like it's 100k for all bodies. I changed line 8 to: @inverseRotThresholdAltitude = #$../Atmosphere/atmosphereDepth$ This sets the warp threshold at the height of each planet's atmosphere. So far, it seems to be working, and looks like it is correct for the other planets with atmospheres in the Module Manager cache. I'll keep testing and let you know if anything weird comes up, but that may do the trick.

@Sigma88 Just wanted to say I appreciate your mod and have been using it for a while. However, I'm still having a nagging issue with the "Cannot warp faster than 1x while the ship is under acceleration" message while in low orbit. I'm using greywolf's settings for a 6.4k rescale. I'm able to physics warp in atmosphere during ascent, but as soon as I leave the atmosphere (~90km), I can no longer warp. It's not until approximately at 135km that the error goes away and I'm able to warp normally again. I looked back through some of the past discussion, and saw your comments about @inverseRotThresholdAltitude being a potential source of the issue. I edited lines 7-8 in "setDimentions.cfg" to read: @timewarpAltitudeLimits,0[*, ] = 90000 @inverseRotThresholdAltitude = 90000 That appears to have resolved the issue, but of course hard codes the values on all planets. My best guess is that the initial value for one or both of these is not the same as the atmosphere height, and thus are not scaling at the same ratio as the actual atmosphere. Also, for what it's worth, the exact height of the atmosphere with this rescale is 89,950m. While testing with the above edits, I found that the message appeared if I attempted to warp in that 50m gap. Hope this information helps, and I'm happy to provide whatever else you may need to resolve it. Thanks!