Starwaster

A lengthy beta doesn't ensure that bugs will be fixed. We've had a lot of major issues fixed with Kerbal Space Program and can look forward to more being fixed in the future. I can think of MMORPGs I've played that had betas of decent length where I tried in vain for eight years to have one simple bug fixed that persisted until the day they shutdown.

At the time that he posted that, I too was having trouble accessing the site. The site is working now, but please be careful in suggesting to someone that they have technical problems on their end that need resolving when it may have been transient issues with the site itself or anywhere else on the 'net.

ModuleAeroReentry is added to every part. ModuleAnimate2Value is added to some animated parts (primarily to landing gear and shielded docking ports) I don't know what the original reason was as it predates my 'inheritance' of Deadly Reentry. But it's probably because animations themselves are graphical in nature and update every frame. As far as the end application, I can see arguments for using either FixedUpdate() or Update() depending on what it needed it for. Leaving it in Update is probably safer even if it runs more frequently than if it only used FixedUpdate()

Or it can be solved by adding seats to the IVA.

The mk1pod has a maxTemp of 2400 until its shield burns out (ablator depleted) and then it drops to 1200. Other heat shields are going to be higher (stock shield keeps its maxTemp of 3800 until it depletes, not sure about other shields) So I don't see any reason why they would burn up at 1000 no matter what issues FAR might bring to the table...what was the internal part temperature, do you know? (should be a lot lower.....) The in-game number is just because I forgot to change it. It's just a string that I set manually and it doesn't grab the dll's version at all. But that won't affect functionality (line where menu version number is set) https://github.com/Starwaster/DeadlyReentry/blob/master/Source/DRToolBar.cs#L139 I've tested DRE with RSS+FAR+RO and didn't experience what you're describing. (did not have RP0 but I'm not aware of any relevant changes it might make...) Note above that some people have had trouble with FAR and DRE. Chrisl says that 0.15.5.1 fixed it for him (and that's the version I tested with) but Jovus says it did not. A few things I should mention here... 1. DRE edits a few things like max temps, skin-internal conductivity, some minor changes to the stock heat shield (by way of extending the ModuleAblator class) but aside from that, all thermodynamic functionality is the stock code. So if there is some issue between FAR and thermodynamics, it's still stock. There's not a lot (that I can see) that I could do to resolve a FAR-DRE compatibility issue, because it's mostly stock 2. NathanKell has mentioned (and this isn't really news, but it seems to be frequently forgotten) is that capsules are too massive for their size. Or rather, are 64% smaller than they would be IRL while retaining the same mass, which means drag has less impact on them. Is maybe reducing stock capsule masses something that I should look into?

FAR was implicated as a culprit in this post: http://forum.kerbalspaceprogram.com/threads/54954-1-0-4-Deadly-Reentry-v7-2-2-update-July-24-2015-%28The-Melificent-Edition%29?p=2180893&viewfull=1#post2180893 I haven't kept up on the issue so I don't know what you need to do. (drop back a version, get the dev version, etc...)

Is that what First Class looks like? (I want to say that it doesn't, but.... I've never flown first class and never even SEEN the inside of First Class so I readily admit that I may not know what the heck I'm talking about...)

That works for both VAB and SPH. It's a very recent addition to KSP. (1.0?)

This is what I use for Deadly Reentry when Realism Overhaul is absent. (gives RO levels of depletion rather than DRE defaults) (actually, a generic version that uses ModuleAblator and checks for absence of DeadlyReentry, should you ever install that) // RSS specific tweaks @PART [*]:HAS[ModuleAblator]:FINAL:NEEDS[RealSolarSystem,!RealismOverhaul,!DeadlyReentry] { @MODULE[ModuleAblator] { @lossConst *= 0.0008 @pyrolysisLossFactor *= 50 } }

Guys, this conversation has played itself out and everyone has made plain how they feel, but now it's derailing the thread. We should call it quits.

Hold down the alt key while placing. The part will stop trying to surface attach and only attach to a node.

Keeping his name from the original config files is not any proper accreditation at all and I doubt you'll find it on these forums anytime soon as it would get shut down pretty hard because of license violation.

Use the throttle limits. Set them in the VAB. (Easier than doing it in the field)

It was. It sounds to me like he doesn't have the latest release.

Oops, one caveat: It was tagged as beta and due to the chaos in moving to DRE 7.0 (for the KSP 1.0 update) it was never marked as full release. I tried to remove the beta tag when I linked to it for you, but that caused some other issues where Github was saying that 6.5.3 was the very latest update so I put the beta tag back. Correct link (for anyone who might find this in the future and need the download) is https://github.com/Starwaster/DeadlyReentry/releases/tag/v6.5.3-beta If you already downloaded it, you're fine. If for some reason you didn't and try the old link, use the new link above.

Sorry, but no. output_log.txt is not the same as ksp.log. A lot of critical stack information is stripped from ksp.log and it really would make it easier to see what's going on with your issue. There's just not enough to go by in that snippet from ksp.log

Last version for KSP 0.90 was DRE 2.5.3. https://github.com/Starwaster/DeadlyReentry/releases/tag/v6.5.3-beta

It's a known stock bug. The more you space station, the greater the odds that it will eventually happen as you dock more and more modules and craft to it.

No. But it doesn't not work with it. They really don't have anything to do with each other.

Destruction is unlikely as it's going to be getting substantially more drag in the upper atmosphere before heating becomes severe enough to destroy the ballute. Is the actual ballute going to be a part or will it be like the parachute canopies in the stock chute or Real Chute mod? Will it be using the chute partmodule?

I think I need your logs anyway (output_log.txt; player.log if Linux/Mac. No ksp.log plz) With regard to NanoGauges, or any other mod that reads resources: EVA resources don't actually 'exist' in the same sense that part resources do. That's something that I'll do something about eventually, but at the moment they are virtual and that's a legacy holdover from before I branched off the mod. When the Kerbal goes EVA, a gauge is added (via the Ioncross EVA partmodule) and virtual resources assigned based on how much O2 was able to be drained from the ship. So it's not unusual that other mods can't read the amount of O2 on the Kerbal.

The temple in Kerbin seems to have moved. It's about maybe 25-50km to the east. (and I might be wrong here but wasn't that area more desert than mountainous? Or was it always nestled in mountains?)

alt-tabbing is like Russian Roulette. It might cause no problems at all or it might crash the application (whichever fullscreen app du jour). Or cause graphical glitches in the game. (L4D2 tends to result in black skinned zombies and transparency issues) Pre KSP 1.0 it would throw lots of errors if in DX mode. In general, do it at your own risk. If you get away with it, 'more power to you' . If you crash and burn "I told you so"

Have you gone into map mode and turned on 'Biomes Visible in Map' to see how your flipped texture lines up with the terrain?

Stockalike_OPT.cfg has mismatched braces which prevents the aerospike engine from switching its engine configs. (i.e. hydrogen only, no kerosene)