Starwaster

It's not going to function with 0.90 until I get in there and do some code work and recompiling. I'll have something out either tomorrow or the day after. And it'll be a fairly big update given that it's all the things I was working on before. Sorry about the delay but I got really tied up with Deadly Reentry Edit: Looking good so far. Had to trim out some obsolete code that didn't really do anything except play with a class that no longer exists in KSP. Testing it in-game now. Resource consumption looks good. Now need to see if.... Kerbal killing... still works. A moment of silence please

It's a shame you let yourself get too upset to see when somebody is trying to help you. Don't you think your reaction is way over the top? Smart ass? really? Again, I try to offer you help and you respond with sarcasm. And yes, DLLs contain executable code The following code excerpt is taken from the Kethane source code. The link will take you directly to the Kethane source containing that code. Note the parts that I boldfaced. Does it look familiar? It should. https://github.com/Majiir/Kethane/blob/1688b8af26acb1a94d349fd2a838d9ce368924e9/Plugin/Kethane/Utilities/CompatibilityChecker.cs#L157-L179 if ((incompatible.Length > 0) || (incompatibleUnity.Length > 0)) { message += ((message == String.Empty) ? "Some" : "\n\nAdditionally, some") + " installed mods may be incompatible with this version of Kerbal Space Program. Features may be broken or disabled. Please check for updates to the listed mods."; if (incompatible.Length > 0) { Debug.LogWarning("[B][CompatibilityChecker] Incompatible mods detected: " [/B]+ String.Join(", ", incompatible)); message += String.Format("\n\n[B]These mods are incompatible with KSP[/B] {0}.{1}.{2}:\n\n", Versioning.version_major, Versioning.version_minor, Versioning.Revision); message += String.Join("\n", incompatible); } if (incompatibleUnity.Length > 0) { Debug.LogWarning("[CompatibilityChecker] Incompatible mods (Unity) detected: " + String.Join(", ", incompatibleUnity)); message += String.Format("\n\nThese mods are incompatible with Unity {0}:\n\n", Application.unityVersion); message += String.Join("\n", incompatibleUnity); } } if ((incompatible.Length > 0) || (incompatibleUnity.Length > 0) || IsWin64()) { [B] PopupDialog.SpawnPopupDialog("Incompatible Mods Detected", message, "OK", true, HighLogic.Skin);[/B] } I'll leave you to your little slide show. I'm so very sorry that I offered you any help at all. I will never make that mistake again. Bye.

Wow, three pages and still no logs. No. posting excerpts from your log files does not count. And the screenshots don't help identify the problem, they only demonstrate that you have a problem. That's been amply demonstrated. Now it's time to present a log file. No ksp.log! Click the spoiler below to locate the log file that you need. If it is too large then use a hosting service. (dropbox, mediafire, google drive, whatever. Did I mention dropbox? Use it. Love it) Windows: KSP_win\KSP_Data\output_log.txt -OR- KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) - In case you installed KSP into a Windows protected directory (C:\Users, C:\Program Files or C:\Windows\ and their subfolders) the output log file may be stored in the folder called C:\Users\[username]\Appdata, this folder is usually hidden so you should enable the view hidden folders option (more information). Note that for the demo you should find the output_log.txt file located in the KSP_Data folder. - Steam users should right click KSP in Steam, click on Properties, then in the Properties box, click Local Files, then Browse Local Files. Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: The log is written to /home/user/.config/unity3d/Squad/Kerbal Space Program/Player.log Also, regarding mods: When it comes to plugins (dll) then it doesn't matter if your ship is stock or modded. If the dll is running then it's possible for it to cause problems. (depends on the mod. YMMV). It's not correct thinking that if your ship had all stock parts that it is guaranteed to be a stock KSP issue. The only way to ensure that is to run KSP without any mods installed at all. Thirdly, KSP does not report compatibility issues with mods. EVER. It's not KSP / 0.90 that reported the incompatibility. That was the mod itself. Sorry, I'm not trying to give you a hard time, but three pages, no log files and the whole thing rife with speculation and a few misconceptions. Posting the logs in their entirety will allow those of us accustomed to troubleshooting KSP get a better handle on your problem. The logs tell us everything. What's installed, whether it loaded properly, what errors are being thrown and when and from what functions.

There's several shield packs. I don't have a list handy, but one of the things I intend to do is put a list up on the first post of compatible shield packs. Here's one to start you off: The NASA ADEPT. It's a deployable shield similar to the one that DRE itself comes with. However, I've found DRE's deployable (inflatable) to have some issues that frankly, the ADEPT shield doesn't share. (one flaw being that the inflatable gets stuck in a deployed state such that if you inflate and deflate it in the VAB then reload the craft file, you will find it deployed again. And it will launch deployed as well) http://forum.kerbalspaceprogram.com/threads/98178 http://forum.kerbalspaceprogram.com/threads/91920-0-24-2-Oblivion-Aerospace-Pack-New-heat-shields-for-DRE!-(v0-1-3-2014-09-18) Edit: Added a link to the Oblivion pack. There's a third one that should probably go there but I can't think of what the name of it is... anyone have a clue? Or at least an opinion on a heat shield pack they'd like to see links added to in the OP? (I added links to the Adept and the Oblivion pack already)

Yeah, from what I understand, certain things are just not exposed in code outside of the Sandbox now. At least not until they are unlocked. The Tracking Station itself apparently has to be updated to unlock things like normal/radial points. And probably apoapsis, periapsis and the ascending/descending nodes too....

I'll be updating DRE to give the Mk3 shielding soon. (meant to do that for the update earlier today but it slipped through the cracks....) Not for me it's not. SDF working just fine even before I updated it.

I agree. I don't *think* that e-dog will necessarily have a problem with this and he may well appreciate it if he's too busy to do anything himself right now. Though it would probably be better to restrict it to just the plugin dll as a drop-in replacement.

Ooooh that. I don't *think* it's meant to be a burial.... it's also not a stock easter egg. One of the mods adds that. I forget which one.

The message is active any time that opening the chute will result in failure. If you don't see the message then it's safe to open the chute. Density, pressure and velocity are factors. You can get away with much higher speed deployments over Duna than on Kerbin, so using Real Chute, you could well create a hypersonic chute such as Curiosity used.

I think they're all mbm actually...

...and ends with weeping and gnashing of teeth.

Apparently you missed the threat of Comic Sans...

The same way any of us know. The same way I knew. It was posted a few pages back followed by jubilant readers giving thanks for the quick update. If you get in the habit of checking for new dev versions (and especially right after new KSP updates) then you won't have to worry about being left behind.

Yes, was still editing the first post and clicked Save too early. (save early save often) Now then. For you 64 bit people: The following is TOTALLY UNSUPPORTED. Here is the latest DRE version 6.4.0 with the 64 bit disabling removed. Versions are provided for both KSP 0.90 and KSP 0.25 (if you aren't yet willing to upgrade) If you try to report issues for the 64 bit client you will be directed (via a message utilizing Comic Sans) to reproduce the issue with the 32 bit client. Only issues reproducible in the 32 bit client will receive support. UNSUPPORTED_x64_DeadlyReentry.zip Have fun

Deadly Reentry version 6.4.0 release (KSP 0.90) *Added toolbar button (for stock toolbar) *Added Easy, Normal and Hard difficulty settings accessible from new menu *Difficulty settings are per-save game!!! Use Easy for sandbox and Hard for Career! (if you want) *Alternate lower density calculation (for use with Hard mode to prevent excessive heating for high speed aircraft) *Fix for stuttering AeroFX cases. (thanks to Motokid600, Chezburgar7300, Zeenobit and Noio for feedback and/or testing) *Reworked warning messages for visibility and/or optimization *Optimized density calculations (moved all into ReentryPhysics; no more per-part calculations) *Lowered part max-temperature cap to 1250 (other parts may be even lower) *Heat shields now insulate attached parts against conducted heat *Low grade heat shielding added to nose cones and fairings. (also to parachute 'cone' parts. Deploying chutes 'jettisons' the shield) *Kerbals now react to reentry events such as overheating. (may need tweaking; even Jebediah gets scared now. Can't have that) *Merged in fixes from NathanKell for FAR detection *Merged in changes from NathanKell to support R&D / Technology requirements *Added support for (currently unused)stock KSP airstream shielding *Trapping and checking for of null reference errors in events. *Added DeadlyReentry.version for AVC and CKAN support Download link: https://github.com/Starwaster/DeadlyReentry/releases/tag/v6.4.0 EDIT: For those not yet willing to make the move to KSP 0.90 I am providing a DLL ONLY drop in replacement for KSP 0.25. Install 6.4.0 from the link above then download the following file and copy the DeadlyReentry.dll over the existing DeadlyReentry.dll in DeadlyReentry/Plugins/ Again, this is if you are still running KSP 0.25 and it is unsupported! https://www.dropbox.com/s/3a76i28kgmv9cvt/DeadlyReentry_6.4.0_FOR_KSP_0.25_DLL_ONLY.zip?dl=1

Correct. Less density means less heat transference. The reason it came about though was because when changing density exponent (to shift start of heating to higher in the atmosphere) it resulted in extremely destructive heating lower in the atmosphere. Especially to supersonic planes and space planes. What I did not intend was for Hard mode to become a 'realism' mode, but it seems like that's sort of what happened. Well, at least when used with Real Solar System. I'm probably going to have to rework 'Hard' mode to work properly with stock Kerbin. The jury is still out on that one. You should be careful with its use because it can really nerf things, especially if you're playing stock. I wouldn't enable it for Normal mode for instance, but, you know: Your sandbox, play how you like

It will not function in 0.90 at all It requires updating before that will happen. It is being worked on.

Then you don't have the latest version. Go download dev build #360

It doesn't, at all. It will disable itself when it detects KSP 0.90 So it still needs updating. Patience, that will happen.

Correct, FAR is not a dependency. If present then DRE will query FAR to determine if parts are shielded, which in some cases is more accurate than DRE's own scheme. (in a few other cases, FAR can be less accurate so if possible, keep payload parts from getting too close to the fairing wall)

It does not What needs to happen there is that I actually need to impose drag penalties for uncapped tanks (or any open node) the way FAR does. Because as it stands right now, the amount of drag imposed for a typical rocket stack with no nose cone is about on par with a rocket stack in FAR that has nose cones. Literally, if you take a rocket with no nose cone in SDF then measure the drag on a launch straight up then quit KSP and replace SDF with FAR, the same rocket will have (appropriately) more drag. Cap that stack with a nose cone and run it again in FAR and your drag losses are going to be within a few 10s of m/s worth of extra drag. Very large diameter parts are probably getting more drag in SDF than they should but I'm not actually sure about that. I have to sit down with some 5m and 10m parts and really give them a good going over. But my gut tells me that they're probably getting more drag than they should be. Edit: On the subject of fairings, I have to write something up to detect if parts are enclosed in fairings. I don't want to do it the way FAR is doing it because parts very near the fairing wall tend to be missed. The way Procedural Fairings does it is better and I just need to take the time to sit down and write up code. (basically, find every part attached to the top node of the fairing base and call that the payload. If the fairings are attached to the base, the payload is marked as shielded) Although not asked, on the subject of cargo bays, it gets much easier. KSP 0.25 introduced a cargo bay module that checks for enclosed parts and exempts them from drag. That's easy enough to add to any animated cargo bay. Some other modders expressed concerns that the system would unbalance stock KSP but I consider those concerns to be grossly overblown.

What happens if KSP_VERSION_MIN (or _MAX) don't exist?

Added a version file to the git

You could even do a ModuleManager patch that adds non-existent modules that have no plugin. ModuleManager will quite happily execute the following. (don't actually use it. Really) @PART [*] { !MODULE [*],* MODULE { name = This_Module_Does_Not_Exist_And_You_Will_Haz_A_Sad_If_You_Use_This_Code } } Hilarity ensues.

I have no objections, but I was just looking at the CKAN wiki and it seems like having a .version file would be better than specifying the ksp_version? I still have to look into that part as I don't know what format the .version file needs to be.