Starwaster

Well it looks like it's not burning anymore but those are pretty low melting points for an asteroid. Probably it will need some custom work which I think I can work into the next update.

Ok, change made. The change is that there is now a ModuleKerbalAeroReentry What that class does is: Freezes analytic internal temperature so that Kerbals don't gain excessive amounts of heat from analytic Provides 500 watts of cooling if the Kerbal's internal temperature is over 297.6 K (~76 F) Displays 'health' if the Kerbal is taking internal damage. If the Kerbal is undamaged then the field is not displayed at all. Gradually heals the Kerbal over time IF they are at or below the desired suit temperature of 297.6 The cooling may be nerfed somewhat to make Eve or Moho more dangerous to wander around on. If I do nerf it, it will primarily affect Career mode and the suit will be upgradeable in the R&D Center to allow safe exploration of these hot places. Analytic handling may be reworked if I can properly get it handle heating / cooling If it's not immediately obvious, I'm treating the EVA Kerbal's skin properties as being his spacesuit. Internal is the Kerbal proper; his or her body.

Ah actually, I have to make a change to that file... give me a couple of minutes then grab the new one. But make sure you re-download the dll because I've rebuilt it again (probably several dozen times actually)

Test with this dll please: https://www.dropbox.com/s/2kiug1k6opjvgqv/DeadlyReentry.dll?dl=1 Be warned though that with this build, if your Kerbals overheat you will probably get an error about a missing sound file, or a nullref... I'm not actually sure what the error would be but basically it'll try to play a sound that you don't have yet. It's on the repository though if you want to grab it and put it in your sounds folder: https://github.com/Starwaster/DeadlyReentry/blob/master/DeadlyReentry/Sounds/scream.wav Just click download

Your log doesn't look like you're running 1.3 Which is all the more reason to verify your files. after making sure that you have the right version selected under the beta tabs. (opt out of all betas should get you the current latest version, i.e. 1.3. Other options would be 1.2.9 prerelease or other older versions. If you WANT 1.3 then make sure none of those are selected then verify your files)

I've recompiled a few things for 1.3 and there hasn't been much changed. Usually it was in some text retrieval fields which makes me think it was done in the course of coding the localization changes. But nothing significant, so far.

It's a pretty generic access violation error. Sometimes hardware (memory) gets blamed but 99% of the time it's just software. You've got 310 exceptions logged, some of them OnDestroy errors that you can ignore because people often don't code up a proper OnDestroy in their mods. Some of the exceptions are happening in places you don't usually see them like the stock radiator code throwing nullrefs trying to find sibling parts on your craft, and some of them when trying to create vessels or destroy parts. Some things to try: Reboot the PC (this before anything else so you don't waste time troubleshooting if you don't have to) Verify your game files in Steam If you installed or updated any mods recently then revert those changes If the problem persists then create a new save game and see if you can play without errors. Some vessels in the current save might be corrupted

@36OZone For the record, errors and crashing have nothing to do with whether you have logs or not. Unless you explicitly disable logging then you always have logs. If you don't know how to find your logs then see the following post, linked below.

That's because the person who's maintaining it has several other mods that he's involved with. Currently I'm concentrating on finalizing the Deadly Reentry update so I can push final updates for both KSP 1.2.2 and 1.3.0 After that I have several pull requests on Procedural Parts to get to (sorry github contributors ) AND two outstanding bugs to look into plus a reworking of a previous bug fix so I can do the same thing. (push updates for 1.2.2 and 1.3)

IRL most upper stages have a low TWR... which is what he's talking about there.

Consent. No.

Unable to reproduce. I need better instructions. I took a stock 3.75m tank then attached a procedural tank to its top node. Then I used the movement tool to sink the PP tank down inside the stock tank. Then I attached a stock probe core to the procedural tank and used the movement tool to sink THAT down into the procedural tank. I saved it then loaded it back into the VAB then launched it. No freeze, no crash and no errors. I looked at your log but I found no errors there to be relevant to the bug that you're reporting and none during the time that you were loading any craft. I do see you had Tweakscale installed and there have been reports of that causing issues so you might want to try without that installed and see if you still have that problem.

True, that's a common mistake and if he did the one then might not have done the other too

That's your problem right there! If you install Kerbol then of course Kerbin is your main planet. Why would you think otherwise? You can't install that AND RSS. It's one or the other. Don't install multiple planet packs.

@linuxgurugamer I went about removing the omni setting from the interstages and it seems to me that the change must have been made because those decouplers have two upwards facing nodes and omni makes it decouple every single attach node it has. Someone must have wanted both of the upwards facing ones decoupled. Unfortunately that also means the bottom facing one as well. A better solution would be adding a separate ModuleDecouple for the other node. I made a little patch to fix it for myself which fixes things so the interstage stays attached to the part beneath it while decoupling both upwards facing nodes. This seems to be working satisfactorily and should give you an idea of what parts and what changes they would each need: @PART[KW5mDecouplerShroud|KW5x3AdapterShroud|KW1mDecouplerShroud|KW2mDecouplerShroud|KW3mDecouplerShroud]:NEEDS[KWRocketry] { @MODULE[ModuleDecouple] { %explosiveNodeID = top %isOmniDecoupler = false } MODULE { name = ModuleDecouple ejectionForce = 1500 explosiveNodeID = bottom2 } }

So at least before the sun goes dark then!

From just a few posts up:

June of last year. Seems like they all got changed to isOmniDecoupler = true

@linuxgurugamer What was the reason for changing all interstages to separate both sides? Was it intended to fix something or serve some other goal? So far as I can tell it affects all interstages; haven't checked non-interstage decouplers but I found out about it the hard way when the 5-3.75 interstage separated not only from the upper stage but the tank below and trashed my rocket. (interstage ejecting forwards and trashing my solar panels. On other occasions it's destroyed the engine )

(in my best Ed Grooberman voice) So like... what... an hour or so?

Accidentally landed a test rover with crew on it. Limited O2... so I sent a K&K greenhouse base and landed it nearby... drove and drove and drove only to find out that the height differences between the Lynx docking port and the K&K base were too great for it to dock So I kept backing up as fast as I could then slamming the brakes on to try to dip the ass of the rover enough to mate the ports. Tried that for 10 minutes with no luck Then I thought of lowering the damping on the bellows joint and suddenly... WHAM! Docked

@RealGecko Regarding this mod not using stored resources, is that a hard design decision or would you be interested in a pull request if I were to code in that sort of support? (which, at some point I intend to do for my own personal use but I don't know when considering KSP 1.3.0 recently came out and I have several mods that I need to get updated for)

Well it's primarily a parts pack. There's not too many things that are likely to happen to invalidate it, and the worst of those have already happened. The PART config format is pretty much set and not likely to change catastrophically... we did have some collider changes that necessitated reworking of some of the models, and that's behind us now. There is a plugin which is my responsibility to update and that'll happen sometime over the next few days

It probably depends on how it's listed on CKAN and whether updates to the mod are handled automatically by CKAN or if it needs manual indexing. A bad *.version file could maybe do it but it's all speculation since I don't personally deal with CKAN on a regular basis.

Also, assume that every single mod that has uses a plugin AND parts WILL crash in KSP 1.3.0. Totally a known issue. (supposedly mods with plugins that aren't compiled for 1.3.0 but don't have parts don't crash but I haven't personally verified that)