NathanKell

Thanks all! Friendly request: please post the version number when you post (as well as the link). That will lower my workload a fair bit (don't even have to click the link, can just copy/paste your post text ).

Northstar1989: If you look in the RealFuels folder, you too will be able to locate it. Its filename starts with KSPI, so... I'm happy to accept help from anyone who wants to update/maintain it; I have my hands full getting v8 done (soon , and if it stretches more than a few days I'll upload a fix for .25 to tide people over).

Sarbian just said it's for .24.2, but also works on .25

Changelog: v6.0 *Support KSP 0.25 *Reverted to old density exponent *Support SPP stock parts *Give wings heat shielding NOTE: Does not support KSP 0.25 Windows x64 Plugin will be disabled on x64; SQUAD says it's unstable (more unstable than last time) and I'm not going to be responsible for breaking it further. This is now under Starwaster's control; this is, in fact, my (extra-)final update.

Known Compatible, but upgrade required (as of listed version) FAR (Ferram Aerospace Research) 0.14.2 NEAR (Neophyte's Elementary Aerodynamics Replacement) 1.2 Kerbal Joint Reinforcement 2.4.4 Kerbal Isp Difficulty Scaler 1.4.1 Deadly Reentry 6.0 RLA Stockalike 11.3 [thread=91034]Contracts Window + Version 2.0[/thread] Module Manager 2.5.0 Kethane 0.9.2 Dang It! A Random Failures Mod 0.4 CrewFiles 2.0 Mission Controller Extended 1.03 MechJeb 2.4+ [thread=64972]DMagic Orbital Science 0.8.6[/thread] RealChute 1.2.5b Taurus HCV 1.3.0 Stage Recovery 1.5.1 RemoteTech 1.5.0 QuickRevert 1.10 Real Solar System 8.0 Kerbal Engineer Redux 0.6 and 1.09 Advanced Fly-By-Wire 1.1.2 FASA 4.98 JSI RasterPropMonitor 18.3 Part Catalog 3.0 RC8 Action Groups Extended 1.18a Chatterer 0.7.1 Kerbal Attachment System 0.4.9 SCANSat 8 RCS Build Aid 0.5.1 Custom Asteroids 1.1.0 Infernal Robotics 0.19.2 Procedural Dynamics Procedural Wings 0.9 Final Frontier 0.5.6b blizzy78's Toolbar 1.7.7 Precise Node 1.1.1 SDHI Service Module 2.3 Kerbal Alarm Clock 2.7.9.0 Texture Replacer 1.7.3 Auto Asparagus 0.7 TAC Life Support 0.10.1 kOS Scriptable Autopilot 0.14.2 TweakScale 1.44 Near Future Technologies 0.3.0 Stockalike Station Parts Expansion 0.2.0 Simulate, Revert & Launch 1.10 Proceudral Fairings 3.10 Connected Living Space 1.0.9.0 Athlonic Electronics / LCD - Launch CountDown 1.7.3 Editor Extensions 1.4 Resource Overview for VAB/SPH 1.0.1.1 Modular Fuel Tanks 5.2.1 FreeEVA 0.2.0 Extraplanetary Launchpads 4.3.0 Real Fuels 8.0 Near Future mods 0.3.0 TAC Fuel Balancer 2.4.1 Alternate Resource Panel 2.6.0 Enhanced Navball 1.3.3 Karbonite Parts Pack 0.4.2 KSP-AVC 1.1.5 [X] Science! 3.0 Navball Docking Port Alignment Indicator 4 NovaPunch 2.07 B9 Aerospace 5.2.5 Interstellar Flight Inc 1.12 KSP Interstellar 0.13 Known Compatible (as of listed version) Part Angle Display 0.2.4.5 B.U.L.B Aug-10-2014 release Simple Part Organizer 1.2.1 Vertical Velocity Control 1.13 RCS Landing Aid 1.2a Landing Height 1.1 SelectRoot (18 July 2014 version) AutoAsparagus 0.6 HyperEdit 1.2.4.2 (with its usual bugs) SurfaceLights (no version info; uploaded 1 Jun 14) Celestial Body Science Multiplier Editor Universal Storage 0.9.1 Docking Port Alignment Indicator 3.0 Science Library 1.2 KDEX 1.02 Aviation Lights 3.6 Camera Tools 1.0 KW Rocketry 2.6d Known Incompatible (as of listed version) Lack's SXT 17a (but see patch here

Mod Compatibility in 0.25 KSP 0.25 has just been released. A number of mods have already updated for .25, but there are a lot which have not yet. Even those that have, however, may experience issues in .25. Those that have not may or may not still work. See the second post for the lists This thread is for reporting compatibility issues. However, there are some guidelines which I would ask you to follow. In particular: 1. Please include the forum link and version number when reporting. 2. If you are using the Windows x64 version, please do not report on compatibility. As Squad's own download links and the .25 FAQ say, the Win x64 version of KSP is unstable and it is impossible to say whether an issue encountered on it is a stock problem or a mod problem. Therefore all reports regarding the Windows x64 version of KSP will be ignored. 3. If you get a warning on launching KSP that the mod is not compatible, please respect the warning; there's no need to post that you're getting such a warning, the mod author already knows (as, now, do you) that the mod is not yet compatible with KSP 0.25 4. Details: Saying "it doesn't work" doesn't do any good unless you provide some details. What doesn't work? 5. Interaction: If you wish to ascertain whether a mod works, please try it alone. If you have multiple mods installed, and something breaks, all you can say for certain is that some interaction between them, or one of them, broke--not that they're all incompatible. Thanks!

Yep, worth trying.

It can be eliminated if it's in a mod, but if it's in stock code it's up to Squad to fix it. What I suggest you do is open your existing sfs file in a text editor and search for NaN. If it exists anywhere let me know; if not, then we know it's being triggered by something you're doing right now, rather than it being a timebomb. Then we can narrow down the source.

However, when *changing* SOIs, due to how KSP works, the forces are instantaneous but tremendous. This is why one needs to warp through them or DRE pitches fits (taniwha found this out the hard way).

Um, TweakScale?

Updates come when they do. I would *much* rather Squad nailed everything down they could, then releasing an update that isn't finished just because it was getting near what people imagined to be the release date. In an age of zero-day patches, that's *praiseworthy* rather than a source for complaint.

Thanks so much!

"Not a Number" It happens when you do something like dividing by zero. I'm not sure exactly what would be causing it--as I mentioned as long as some math operation *somewhere* returns NaN, it will spread to anything involving that value. Consider: for some reason x = 0 y = 15/x (now y is NaN) z = y * 5 (now z is NaN) on the next frame, x = z + 5, now x is NaN As for preserving the save: if you can't revert, force-quit (alt-F4 if on Windows). That should not save to disk.

Ah, answered this in the thread you started in General Addons. RF *does* have a config file that modifies KSPI resources; I take it by your post it's not working right. It is quite dated, so I'm not surprised. Also, RF v7.4 *should* work with B9. Make sure you followed the instructions in the OP and deleted your RF folder before installing it, otherwise configs from prior versions will persist (and double up B9 tank configs).

There's even a cfg file in the RealFuels folder to do that, but I'm guessing by your posting this lots that it's outdated?

It's like cancer, though--there presumably isn't "one" NaN bug; it's that if *any* one of hundreds of variables that interact gets set to NaN, it spreads to the others. That's how NaN works: if you do any operation, however long and complex, that involves a single NaN term, the result becomes NaN.

Note, however, that KSPField works for only some types. It doesn't work for double, for instance.

Yeah. I asked Mu to add it (it has to be done on Squad's side, basically) so all we can do is contact Squad and ask them to add support for it.

Noio: Yeah. By one metric of balance, if there *is* ablative shielding remaining by the time you hit the ground, that means it's too easy. That was the metric of the original DRE, if I recall; FAR lessens the danger considerably, so then people I think got used to having lots left. In real life, of course, one very much *over*-shields crewed pods for safety; Apollo, for example, they speculate could have survived 4x? 6x? the heat load and flux. In general, the lower the G, the higher the heat load but the lower the peak flux. A ballistic reentry will (excepting something strange like negative-lift reentry) have the highest G load for a given entry angle, and will always have the same heat load (the integration of flux over time; flux will decrease and time increase for shallower angles). A lifting reentry will keep you in the upper atmosphere longer, lowering Gs and having a lower peak flux (because you've slowed down more by the time you hit the it), but a higher heat load. Since Kerbin's atmosphere is shallower than Earth's, and entry velocity is only about a third Earth's (for LEO/LKO), the structural and crew-health limits that prevent high-G reentries don't apply as much, and therefore you can dramatically lower how much temperature change your pod undergoes by increasing the entry angle (due to how KSP models temperature, and how DRE was written around that, if you go for a steep reentry you will spend so much less time at high flux that you won't actually increase your temperature very much, even though notionally the heat load would be the same). HERE is a nice booklet on reentry. smart013: apologies: the easypeasy was not a swipe directed at you, or anyone else; it was merely a comment on how in prior versions it was entirely possible to make unshielded reentries, which more or less defeated the purpose of having shielding. Certainly you should *not* be able to reenter engine-first and survive; that was going to change, whether by tweaking the heating model or adjusting the maximum temperature of various items or both (the latter is still planned, I think). Consider: there is no way an antenna should be able to survive until *twice* the melting point of aluminum (which is 660C, for reference). And yet even as modified by DRE, its max temperature is 1450C, I believe. Same for fuel tanks. Engines can only survive high temperatures inside their combustion chambers and nozzles through some serious work: regenerative cooling for the hotter ones like your Mainsail or LV-T30, ablative cooling for low-chamber-pressure-and-efficiency ones like the LV-1. So once they've finished their burn and are turned off, their maximum temperature shouldn't be much more than 8-900C tops, I'd say (a good bit less, considering all the exposed machinery that's not shielded by the nozzle). All that said, it should still be possible to reenter with spent stages for reusability, you'd just need to put a heatshield on the nose of the stage. Finally, it's worth noting that KSP makes things harder in a perhaps-unanticipated way: the pods have the masses their real life equivalents do, but they create less than half the drag (.64 the width/height/depth = .64*.64 the surface area = .41). That means a much worse reentry, where speed is kept high until much lower so your heat flux (roughly density^.5 * speed) is much higher.

If your shockwave exponent is 1.0, you are not playing with RSS settings. Period. What's happening is that heating now occurs much higher in the atmosphere than it used to, which is good. Also, you no longer get to do 5G ascents--DRE isn't just about reentry, it's about making you a careful pilot in atmsophere. However, if the exponent stays where it is, shields should get a buff. Even though as I and Athlonic demonstrated the current level is quite survivable, it is not the "easy peasy don't worry about it" level it was before.

If you change density exponent (NOT afx density) to .85, you will get pretty much *exactly* the prior behavior. So if you want to "go back in time", do that, don't use an obsolete version. For now I will release an update with just that, and Starwaster can figure out how things should be balanced later. I also *do* want to point out that, until 5.3.x, much of the DRE thread was taken up by people talking about how reentry was too *easy*. So I figured, why not fix that problem, *and* use the real life density exponent. I did, of course, test a full reentry in a Mk1 pod (ballistic, not even lifting) and succeeded just fine, so it did not seem over-hard to me.

The stock jets have insanely high thrust because the stock atmosphere is a soup. Since FAR gives you realistic drag, the jets' thrusts are lowered to match. They still *far* outperform real jets, because they're still modeled as rockets (KSP don't actually model jets, just airbreathing rockets) so thrust does not decrease with air density. Also they're ~16x as fuel efficient as they should be, since due to another bug, IntakeAir is included in Isp calculatons.

Or put density exponent back to 0.85, that's easiest.

There's a possibility of an issue with the logic in the code. I am trying a fix.

Thesonicgalaxy: please, please, do update the download. I have just released RSS v7.4, which should be the canonical version for .24.2. Please use that dll.