Crzyrndm

May actually happen now the terrain memory leak is no longer an issue, although it's much less simple than just using radar altitude if you want it to be worth anything. I may need to deal with smoothing transitions out a bit first though (the current system doesn't like changing from climbing to descending much, doing that constantly would make that very obvious)

Ditch it for the time being and just use fuel lines if you need the function would be my recommendation at this stage. There's no hard dependency on it

IIRC Xenon uses different fuel rules that let it draw from radial tanks. No idea on the jet engines, it'll be something they can do though so pester them if it doesn't happen EDIT They need to add this line to their LF propellant node resourceFlowMode = STAGE_PRIORITY_FLOW

CFE has not been updated for 1.0 yet. However, changes to Jet Engines means it's no longer needed for anything except LFO. EDIT I can probably forcibly override it and make it unnecessary for now...

Since I can't replicate either issue, I really need those logs. It sounds like something is failing to initialise properly, but there's a whole host of things that could be doing so

Bottom of this post: http://forum.kerbalspaceprogram.com/threads/116916-Comprehensive-Mod-Compatibility-List-for-KSP-1-0

TWEAKSCALESETTINGS { scaleCrewPods = 0 // set to 1 for scaleable pods } @PART [*]:HAS[@MODULE[TweakScale],#CrewCapacity [*],~CrewCapacity[0]] { var = #$@TWEAKSCALESETTINGS/scaleCrewPods$ } @PART [*]:HAS[@MODULE[TweakScale],#CrewCapacity [*],~CrewCapacity[0],#var[0]]:FOR[TweakScale] { !MODULE[TweakScale] {} } Try something like this. Has may not do full variable addressing

*whistling...*

Do you have module manager installed? (you need it for the 1.0 patch to work) EDIT Github updated with a better (well, more stock anyway) thermal setup for the parts

Can't really change those too much otherwise you end up killing re-entry heating off. The issue here is that the interpolation method used is completely linear, causing an extremely sharp kink as it cuts in

Already fully compatible with the 0.90 version (notice the voxel patch in my github, that's for nuFAR) Going to need your logs. Load up the game, jump into the SPH, hit J a couple of times over a wing and then alt+f4. Upload the output_log.txt in the KSPData folder to dropbox or similar (I need the whole thing)

The raw data of the kink: [TABLE=class: grid, width: 150] [TR] [TD]Mach[/TD] [TD]Flux[/TD] [TD]Flux'[/TD] [/TR] [TR] [TD]1.995[/TD] [TD]2037.6[/TD] [TD]2.17[/TD] [/TR] [TR] [TD]1.996[/TD] [TD]2039.8[/TD] [TD]2.19[/TD] [/TR] [TR] [TD]1.997[/TD] [TD]2042.0[/TD] [TD]2.18[/TD] [/TR] [TR] [TD]1.998[/TD] [TD]2046.3[/TD] [TD]2.21[/TD] [/TR] [TR] [TD]1.999[/TD] [TD]2046.3[/TD] [TD]2.14[/TD] [/TR] [TR] [TD]2.000[/TD] [TD]2048.6[/TD] [TD]2.22[/TD] [/TR] [TR] [TD]2.001[/TD] [TD]2073.8[/TD] [TD]25.3[/TD] [/TR] [TR] [TD]2.002[/TD] [TD]2215.8[/TD] [TD]142.0[/TD] [/TR] [TR] [TD]2.003[/TD] [TD]2367.9[/TD] [TD]152.0[/TD] [/TR] [TR] [TD]2.004[/TD] [TD]2506.9[/TD] [TD]139.0[/TD] [/TR] [/TABLE] Flux' (convective) stabilises at 150 (+/- 5) per frame Oh, I have no issue with the increase in heating. It is specifically the jump as you pass Mach 2 that I was wondering: A) Is there any basis in reality Any way to even begin to deal with it C) Any settings that could smooth that out a bit Implying it's a bug I assume (although I guess there's not much chance of it not being one given how unmanageable gaining 100s of thousands of flux in seconds is). Custom plugin => excel In a stack, parts towards the rear have a delayed response almost exactly as you would expect. The parts that heat the fastest are small and stick out into the airflow (canards are really bad for this)

The red line is convective flux (heat energy transfer rate) on a craft flying at 500m altitude. The sudden spike at Mach 2 is why planes all explode when you go much beyond 700m/s at sea level (the instant speed is > mach 2, flux/second increases by a factor of 70...) Just wondering if there is any reason for there to be a sudden sharp change in heating characteristics passing through Mach 2

ISP for jets seems to be based on LF only (finally). No variance with pressure, turboram is 8k, basic is ~20k IIRC

So the sudden spike in heating between 710 and 715m/s is caused by passing through Mach 2. The rate of increase of thermal energy (flux) before Mach 2 is maybe 10 per m/s of speed increase, above it instantly jumps up to hundreds if not thousands

Added Thermal monitoring plugin because I'm sick of having to open the debug menu (and it presents the total flux rather than all the individual components)

Testing with the Ravenspear Mk1, monitoring the standard canard connected to a Mk1 cockpit (small objects that stick out into the airsteam heat up the most) 10m altitude 710m/s => rapid climb to 700K, continues to slowly climb in a manageable fashion (1400K after 10 minutes, no sign of stabilising) 715m/s => rapid climb to 1000K, continuous climb is noticeably faster than @710m/s 5km altitude 655m/s => rapid climb to 750K, continuous steady climb... (reduced atmospheric density reduces conduction faster than shock heating?) 670m/s => rapid climb to 1000K 15km altitude 700m/s => rapid rise to 800K, doesn't really slow down like it does lower down though 20km altitude 700m/s => rapid rise to 650K, really starting to slow down past 800K 820m/s => 1450K Ran out of lift past 20km and the high AoA to maintain altitude meant I was losing speed pretty quick tl;dr Stay under 700m/s until somewhere between 15 and 20km if you want to keep canards or other small sticky out surfaces. NOTE: The fact temperature doesn't seem capable of stabilising without decreasing speed for short periods is concerning me

Hehe. Having 8 mod threads to keep track of was a pain (+ all the sig links meant I went over the 1k character limit... >.>). This way I only have to manage Github and the thread will basically handle itself (much less hassle when I have an idea...)

Dynamic Deflection v1.0.1 Fixed some stock control surfaces being read as having -ve deflection

Pilot Assistant v1.5.5, Filter Extensions v2.0.5, and everything in The Plugin Workshop are updated for 1.0 B9 PWings patch has also been updated for 1.0 compatibilty

Deploying landing gear was enough to knock one of my planes from the sky in nuFAR (it was going slow and already particularly unstable...), so yes I imagine so

Alright, some more details added to the OP. I'm going to go and play some KSP now

KSP v1.0 patch Install from download as normal, and then get everything from the gamedata folder on github @fatcargo The issue lies with MFT. 0% utilisation causes a divide by zero (RF has since clamped to 1% minimum for this reason)

logs...

v2.0.5 KSP v1.0 compatility subcategory deletion is back, only applies to subcategories not created by FE Rename and changing icons can now be applied to all subcategories not created by FE as well as procedural FE subcateories (eg. engines) proper documentation of changes once I've finished 1.0 compatibility checks