Starwaster

I'll see about a GitHub release. Is there something I have to do for CKAN specifically? Edit: https://github.com/Starwaster/StockDragFix/releases/tag/1.1

http://www.curse.com/ksp-mods/kerbal/222057-stock-drag-fix SDF 1.1 Change log: Update for KSP 0.90 - Recompiled for KSP 0.90 - Optimization changes: - Removed unnecessary checks and computations - Moved dragScale sanity check to main SDF class. (one time execution) - Fed some turkey sammich to Cleopatra, The Feral Cat

There were no aerodynamic changes in stock KSP. I know that it was said that stock aero was going to be looked into implying change but no such change has happened yet.

No, don't try it and report it. Or at least don't report it. It will NOT function in 0.90 and Ferram knows that so don't pester him about it. He knows it won't work in 0.90 because it is coded to disable itself if it detects a new major KSP version change. not for me because I have my own solution and it still works in 0.90

After you do your initial transfer burn, schedule a fine tune burn. Enter the value of the altitude above the target planet that you want. (make it close but it doesn't matter because you probably won't get it) You can schedule the burn even before you pass out of Kerbin (or other origin planet) SOI. It will be scheduled at around the midpoint of your journey or possibly earlier depending on your trajectory but it schedules it for the point where you'll need the least fuel to make the correction.

Check your ElectricCharge.

Ok, you need to also make a new game instead of testing with your old save. Also, what DID happen to the Androsynth???

Still working on integrating the Mk3 parts and tweaking the warning message placement as it's not quite centered. However, here is the recompiled DLL. First install the mod as normal, then copy the DLL to the DeadlyReentry/Plugins folder, overwriting the existing dll. https://www.dropbox.com/s/moge45bumutdcwj/DeadlyReentry.dll?dl=1 EDIT: Install the latest beta.

Known issue. And not one likely to be fixed unfortunately.

Recompiling and testing the DRE plugin now. (recompiled against the KSP 0.90 binaries without complaint so it should be just fine) (You can probably even still use the existing version, but no promises or guarantees. Might let you land your Kerbals just fine then issue forth a low guttural laugh as it flash fries them to death inches from Kerba Firma)

I should have a new version of the Animated Decoupler up tonight after I recompile it and test it.

It doesn't usually take much to get a plugin working with a new KSP update. Sometimes it will function without any intervention at all but it's a good idea to recompile against the new binaries anyway.

Sarbian has had his finger hovering over the upload button all day. He's probably pretty tired and his hand is cramping.

Ok, how's this for warning messages:

When you suspect a specific mod *cough*deadlyreentry*cough you should go get the latest update for that mod. (cuz you know... sometimes someone else might have reported this problem and MAYBE the developer might have fixed it.... last month....)

Not without seeing the configs in question

Updated beta 6.3.3 with a hotfix: https://github.com/Starwaster/DeadlyReentry/releases/download/v6.3.3/DeadlyReentry_v.6.3.3.1.zip Reverts the difficulty settings change. (can't put config files in PluginData at all apparently) No other change (other than fixing the version number in the menus)

Bait and switch attracts more people.

Of course you can always suggest it! But the answer is no, I'm not removing it. It's there because people's chutes were failing and they had no idea why. As to not being readable, the chute messages aren't the first time DRE has displayed messages in that area and in that format and color. It's always displayed unsafe g-force warnings for crew, and there's been enough feedback about that to suggest that readability isn't an issue. Still, if it will make it MORE readable, I could look into changing the color. If that is possible. I do not know enough about the feasibility of altering the staging icons, especially from a 3rd party mod perspective. And as far as attracting the player's attention, it sounds insufficient to alert the player about unsafe chute opening conditions. Neither the stock game nor any mods (AFAIK) make use of such icon overlays and players would be unfamiliar as to their meaning. At least a message displayed at the upper half of the screen in plain English has the benefit of already being established by both stock KSP and DRE itself for displaying feedback messages to the player. I do thank you for your suggestion and your feedback however. If the message can be made plainer or more noticeable then I'll see about doing that.

I found a problem with difficulty settings not being properly saved or loaded, but it's not anything that would stop your heat shield from working. Ablation is working just fine on my end. I'll have to take a look at your log and see if that turns anything up. It might help to see a look at your DRE debug screen so I can see the settings. Also, what shield is that and where did you download it?

No, you can't. But you can and should be checking for and discarding null references every single time you bind to an event. Specifically OnVesselWasModified: Every KSP event can be and often is called multiple times for a single event occurrence with only one being valid. When you allow a null reference exception to be thrown in your code it can cause cascading errors breaking everything else in the chain. There's no knowing for sure when it's going to happen but every modder needs to start guarding against it and it's real simple to do: private void OnVesselWasModified(Vessel v) { [B] if ((object)v == null) // Do the same for your on/off rails events return; [/B] if (JointUtils.debug) { StringBuilder debugString = new StringBuilder(); debugString.AppendLine("KJR: Modified vessel " + v.id + " (" + v.GetName() + ")"); debugString.AppendLine(System.Environment.StackTrace); debugString.AppendLine("Now contains: "); foreach (Part p in v.Parts) debugString.AppendLine(" " + p.partInfo.name + " (" + p.uid + ")"); Debug.Log(debugString); } updatedVessels.Remove(v); RunVesselJointUpdateFunction(v); } Or encapsulate the entire thing in a try/catch construct and discard the error. It's not a question as to whether this is happening, it's just a matter of when and how often. KJR is probably throwing the error in question more often than people are actually reporting but it doesn't always cause problems so people don't know about it or report it. There's even a good chance if you go look at your own logs after a lengthy play session that you'll see it yourself.

I think I'd only released it as a drop-in update via Dropbox. The official beta with that fix didn't go live until just now. (plus some other minor things)

Pushed latest updates. This will probably be the last beta. Next update will be official. https://github.com/Starwaster/DeadlyReentry/releases/download/v6.3.3/DeadlyReentry_v.6.3.3.beta.zip ModuleManager 2.5.3 compatibility change: Moved difficulty and settings related files to DeadlyReentry/Plugins/PluginData (EasySettings.cfg, DefaultSettings.cfg, HardSettings.cfg and Custom.cfg) Added virtual keyword to ModuleAeroReentry.Start() Added override keyword to ModuleHeatShield.Start() Fixed FixAeroFX() fixes. (was not properly calling coroutine) Moved crew/chute warning messages to ReentryPhysics Updated ModuleManager file to 2.5.3 (to-do: move per-planet atmospheric data to ReentryPhysics; right now it's calculating that on every part instead of being static on ReentryPhysics. If you don't know what that means don't worry)

Wait, is THAT what that's supposed to be??? I thought they were just digging for samples...

Unable to duplicate your problem. Latest beta, 8 chutes: Dunno why you would be seeing 8 messages. Try downloading again? That fix might not have made it into the last push... if not it will definitely be in the next. I'll have to think about allowing the outright disabling of the message because right now it means fewer support complaints about chutes not working/buggy chutes/ chutes overheating even though the part was at -69,105 Celsius.