Starwaster

Why? The only part you will see is the nozzle. Where is this longer model going to be? Inside? Where it won't be seen? Here is an F16 engine. The horribly drawn red line marks where the nozzle begins. You can only see what is to the left of the squiggly line. Everything to the right is buried deep in the part you attached it to. The blue + is roughly where its center of mass is. (above a point dead center between the wheels on the carriage) There's just no point in having anything more than the nozzle for most of the jet engines we have in this game.

Look at convection and radiation for any suspect parts. If shielded then those stats should be pinned at zero

wrong solution. Read one page back.

Not even this? http://forum.kerbalspaceprogram.com/threads/126664-MAJOR-Heating-Bug?p=2091430&viewfull=1#post2091430

Please read my response to the person you quoted. I want your entire log file; (output_log.txt or player.log depending on platform. No ksp.log) And the cache file too. EDIT: Just in case: Make SURE you have the latest. Delete whatever you have and download this: https://github.com/Starwaster/DeadlyReentry/releases/download/7.2.1/DeadlyReentry_7.2.1_The_Melificent_Edition.zip Install it. EDIT #2 Actually... scratch that... it's probably a version mismatch. I didn't properly restrict DRE by KSP version revision #, only major/minor. (i.e. DRE considers itself compatible as long as the KSP version is 1.0.x and doesn't care what x is equal to) So if you're still on KSP 1.0.2 then you need to fall back to Deadly Reentry version 7.1.0 OR update to KSP 1.0.4

In an act of blatant plagiarism I'll rip off someone's reaction to another mod to a different game: "people are starving to death in this world... and somebody had time for this....."

And this is why any projects I care about are backed up to Dropbox

No logs, no cache file, no tasty sammich. Who knows? Having to guess in the absence of real information but I'd say that Ven's chute part isn't compatible. He probably renamed the chute or cap transforms or both. Increasing frequency of compatibility problems is why I stopped using Ven's parts. Go back to using the stock Mk16 part or use the parts that RealChute comes with. Or bring the issue to Ven. That's my advice.

Woefully inadequate information. I need: log (output_log.txt if Windows / player.log for Linux or Mac) http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support ModuleManager.ConfigCache (from your GameData folder) Also in your GameData folder, you might try deleting ModuleManager.Physics and then run the game, but I'm really just shooting blanks in the absence of the information I need to troubleshoot.

Sounds like you need some patches I posted. They're no more than a few pages back.

If interpreting your question literally, the answer would be no ... you don't really say what the operator would do if the key is present. (NOT set it...?) There is % which sets it if it's present and adds it with the assigned value if it's absent. example: %skinMaxTemp = 1523.15 Regardless of whether skinMaxTemp is absent or present, the above line will result in the part having skinMaxTemp with value of 1523.15

Why do you think it's a memory leak?

How about instead you stop forgetting to put panels on? Or... if you do forget, it's the same as any other major component that you forgot to put on your ship. OOPS. Mission is in jeopardy. MISSION FAIL. And you have to launch a new probe. (or if you have KAS then a rescue mission may be an option. Where you send a crew to go attach a panel on) Obligatory smiley

Ok, FAR could be an issue.... in the past it has affected the radiative area. I'm not able to make it explode. HOWEVER. Ooops. MODULE { name = ModuleAnimation2Value animationName = dockingring valueName = maxTemp valueCurve { key = 0 2700 0 0 key = 0.1 1250 0 0 key = 1 1 0 0 } } Major OOPS on my part. Actually I'm not sure WHY it doesn't explode for me, FAR or no FAR. But its overheating gauge is right on the edge. Probably wouldn't take too much to push it over the edge. I'll have a fix out in the next day or two. In the meantime, edit your DeadlyReentry.cfg file and see that second 1 on the last key? Change that to key = 1 1250 0 0. That will stop it. Make your reentry angle a lot shallower. That sounds way too steep. You're going to want to be halfway around the planet, roughly. I can't say for sure exactly if it's more or less with FAR. Probably more than halfway? And make your pitch about 35 degrees. You have some leeway but you want to increase your cross section. Increase drag and lift and do as much braking as you can high up. One final warning: If you have the overheat gauges on, they WILL light up, even following my advice. That's the skin temperature. However, as long as you're not coming in too steep then it'll be in thermal equilibrium and not explode. (though again; I haven't done a reentry with FAR very recently so you might not be able to do enough braking high up. I may need to bump up the skinMaxTemp value on those parts. But it works in stock aerothermo)

He GAVE you an answer to your problem. Practically handed it to you on a platter. It's not his fault you didn't understand it. Everyone of us using the AppLauncher in our mods has had to go through this when KSP updated.

Repro steps.... cache file... logs?!?? WTH is going on here.... did I accidentally slip through the portal into the mirror universe? Where is my evil opposite? What is he doing at this very moment???

breakingForce won't stop them from moving relative to each other. It controls whether or not the connection is severed due to applied force.

Wolf, there's a number of things wrong there in your speculations. First the config files. All of of that is parsed one time only: when the game starts up. It's already parsed and serialized and Unity models and textures loaded before the game gets to the main menu. Second, your GPU: I've run quite a few tests here over the past couple of days and have been corresponding back and forth with Sumghai and trying different things out and I am really not finding that my GPU is being challenged at all. (it's a 650 too). Just to give you the benefit of the doubt, I just went through and butchered the crap out of those texture files. I cut them all to 25% (never mind halving them). It had zero impact on performance issues. I do find that the CPU is being worked pretty hard but that's going to be more of an issue with whatever work the plugin is doing every update than with the graphics card.

Stock behavior doesn't result in abnormal costs when a resource's amount is set to 0. I'm giving the stock procedural fairings the same treatment and I'm not having to do anything odd like increasing the cost of the part. It's not sensible to think that adding a resource necessitates altering the base cost to avoid buggy part costs. Either way there's a definite bug at work here The problem was that parts weren't heating up on reentry, correct? Well this wouldn't be the first time we've had problems with that mod Is the problem confirmed in the SETI thread? Is there a solution? Or is it being worked on or is it considered to be someone else's problem?

That's very interesting; I didn't realize there was a bug with PF where adding resource to the fairing side could break cost. And that's what it is; it has nothing to do with me not changing cost and that probably won't help because the cost is determined procedurally. Seems like adding a resource where amount = 0 is what triggers it. Increasing amount results in a positive cost value. Picking the fairing up by the base and setting it down again also fixes it. So yeah, that's a bug there. I'll see if I can work around it, if not then I'll remove the shield. Ok, specifics? What part? What error? Logs? MM cache file? Throw me a bone here? (need the info...)

No, that's Christo at work, not having contented himself with making the Florida Keys pink....

This one will too, but since 90% of its previous functions are now done by stock, it all got gutted until I can get new menu functionality going. Either the next update or the one after that will have a real menu. (depending on if I want the next update out sooner or later)

I did find a problem that is probably not apparent to anyone: One change that was supposed to have been made in the last update was to use FixedUpdate instead of Update or OnUpdate. The difference is that FixedUpdate (as the name implies) runs at a fixed rate of every 0.02 seconds. (50x a second) Update however runs every graphics frame update. Considering that graphics frame rate can be over 60x second (my hardware can do 120x second for 3D support) that can make things more expensive in CPU resource use than necessary. So another update is coming out as soon as Forge approves it. CKAN... maybe

No reason. I didn't implement a means by which it could be hidden so the answer to the question is 'no'. I don't have anything against blizzy's toolbar but implementing it just hasn't ranked high enough in priority for me to devote the time to it. If anyone wants to code Blizzy support, feel free to write it up and do a pull request.