Starwaster

Are you using FAR? You could try flying the error out. (assuming you're using a lifting body.... if not, disregard)

The bottom of the Mk1-2 could use a bit of tweaking... a little narrower (or less curvy) and down a few... centimeters? Has some overlap with the SDHI shield. That part isn't too bad, but with the 2.5m DRE shield, the two parts don't meet at all.

If you're asking for a specific course of action, I haven't decided yet and am not going to commit to one other than to say that I will be going through the entire list of parts in those files and deciding if any need specific handling, which is why they are in that file in the first place. Each part on a case by case basis. If any need further adjusting then they'll be adjusted instead of being removed. There's a lot of parts in there and I'm not going to blanket delete them from the file.

The ridiculousMaxTemp cap was set with what I thought was a good max cap that nothing should go above. It's a subject that's come up before with the previous cap as having been judged to be too high. But the intent wasn't to set that capbased on parts that were being adjusted elsewhere. Those parts were just caught in the crossfire and that will be dealt with. The actual cap is 1250, not 660. Though depending on the part it could have been dropped lower than 1250 because of the config file issue that Persig mentions. As far as heat transfer between parts goes however, that hasn't been altered at all in the beta with heat shields being the sole exception. (heatConductivity reduced to ~8% of previous value) All heat transfer between parts is handled by stock KSP so the only way your parts are exploding from the engines conducting heat into them is if they were already being heated up to levels that became lethal because said parts got capped at or below that level. It would be helpful to know specifically what parts, what temperatures, altitude and speed. Edit to include DeMichel's post I'll look at it but I'm already thinking that I'm going to have to defer on coding up a workaround to Hyperedit teleports.

Fantastic, I was really worried about the salt mine thing. It's bad for the skin.

Sure, why not. After their accident, maybe they'd appreciate the attention...

It happens at the main menu. All parts are iterated through by the plugin and adjusted exactly as you say. The value for ridiculousMaxTemp can be adjustedin DeadlyReentry.cfg if you're using the latest official release or in DefaultSettings.cfg in the beta (and in future releases) I had planned on making that configurable by difficulty setting but that requires a good deal more coding and I ultimately decided against it. (because the current implementation happens at the main menu and because difficulty settings are per save game, there is no concept of difficulty until after a game is loaded up) Actually, 1250 is from the beta. I cut the value for ridiculousMaxTemp in half. The latest official is 2500 so 1700 (for the Mk1-2 and others) is well below the cap. So, if you're looking at the latest official then those numbers are ok. The beta numbers are still subject to change so the maxTemp adjustments will come down to something suitable. Unless I raise the cap back up. In addition to that however is that (oops sorry, I left this out of my explanation) heat shield parts are exempt and that includes the SPP parts and most other plane related parts. In fact, those have to be fairly high because their heat shield configurations are reflective only and lack ablative shielding. Typically those parts will reflect 10% to 25% of all incoming heat which is sufficient for stock Kerbin. (RSS... not so much)

I think it's likely that you're not looking at all delta-v requirements and that you're not really going to see any savings even if TWP could actually plot that node for you.

Yikes, that thing looks like it will make the air bleed!

No, there's not, but it's not really an issue for most of those parts. The reasons for having configs on any of them are: to add a heat shield Adjust the maxTemp to something sane (since most parts have maxTemp values that are way too high) There are no parts that require a heat shield in the NASAMission parts (with the possible exception that maybe the LES part could use a weak 0.05 - 0.10 passive reflective shield) and there's code in the plugin that will check for insanely high maxTemp values and set them to the lower of half of maxTemp or ridiculousMaxTemp which is defined in the DeadlyReentry.cfg file (which, I think I didn't document this but I cut that in half from 2500 to 1250) In fact most parts out there for most mods have no DRE configs either but will do just fine without them.

Cygnus information is pretty sparse. You'd think Orbital would have a users manual like everyone else. This is as much as I've ever seen https://www.orbital.com/NewsInfo/MissionUpdates/Orb-1/files/Cygnus%20_overview.pdf the 'REA' is probably a reference to its attitude control. 32 = 8 quads? 4 fore and 4 aft? Propulsion: Dual-mode N2H4/MON-3 or N2H4, IHI Delta V engine (thrust 100 lbf.), 32 Rocket Engine Assembly (REAs, 6 lbf. thrust) Power: Two solar array wings on the service module (6 panels total, generating 3.5 kW of power)

You have to click Other Downloads to see all files.

Yes patches are cumulative. Order is important. I see multiple problems with your config I have not used the | operator but I don't think you are using it correctly. Pretty sure @PROPELLANT[XenonGas]|@PROPELLANT[ArgonGas]|@PROPELLANT[ElectricCharge] should be @PROPELLANT[XenonGas|ArgonGas|ElectricCharge] Also, minThrust and maxThrust are fields of the ModuleEngines, ModuleEnginesFX or ModuleEngineConfig modules. You're trying to modify something in the PART node and not any MODULE node. Your conditionals are looking for ModuleEngineConfigs so it you probably want this: (it's untested but it should work) (used :Final. It's not something you use alongside of other ordinal conditions like :BEFORE, :FOR or :AFTER) @PART [*]:NEEDS[RealismOverhaul]:HAS[@MODULE[ModuleEngineConfigs]:HAS[@CONFIG [*]:HAS[@PROPELLANT[XenonGas|ArgonGas|ElectricCharge]]]]:Final { @MODULE[ModuleEngineConfigs] { @CONFIG [*]:HAS[@PROPELLANT[XenonGas|ArgonGas|ElectricCharge]],* { @minThrust = 0 @maxThrust *= 100 } } }

Ordinarily I would deride you for seeking advice from an internet forum about how to deal with your friend, but this time I think I'll just tell you to ditch him. It's not going to work out at all.

Forum probably just spazzed out. I've had that happen to me where I only submitted one reply and it turned into multiples which then got merged into one post. (and yes, more information is required! Also welcome to the forum Mr Kerbol. Please read the guidelines on submitting issues: How To Get Support (READ FIRST))

Just to be sure: Which Deadly Reentry multiplier are you referring to exactly? Is this the Deadly Reentry 6.2.1 beta? Are any parts being destroyed or are they all separating cleanly without part destruction? I took apart the Eve pressure curve data in the Unity curve editor and it looks fine. Temperature curve does have a bit of a spike/fluctuation from 96-100 km which would affect density. I don't know how severe an effect that would actually inflict in FAR but the potential is there I suppose. If you don't mind some config editing, try replacing Eve's temperature curve with the following and see if you still have trouble. (smoothed out the area from 96-100 km. If that was based on real data then now... it's not. Or maybe there was an error in that data, I have no idea. But this smooths out the spike) key = 0 462.15 0 -7.71 key = 2 446.73 -7.71 -7.71 key = 4 431.31 -7.71 -7.71 key = 6 415.89 -7.71 -7.71 key = 8 400.47 -7.71 -7.71 key = 10 385.05 -7.71 -7.75 key = 12 369.55 -7.75 -7.75 key = 14 354.05 -7.75 -7.75 key = 16 338.55 -7.75 -7.75 key = 18 323.05 -7.75 -7.75 key = 20 307.55 -7.75 -8.38 key = 22 290.79 -8.38 -8.38 key = 24 274.03 -8.38 -8.38 key = 26 257.27 -8.38 -8.38 key = 28 240.51 -8.38 -8.38 key = 30 223.75 -8.38 -7.93 key = 32 207.89 -7.93 -7.93 key = 34 192.03 -7.93 -7.93 key = 36 176.17 -7.93 -7.93 key = 38 160.31 -7.93 -7.93 key = 40 144.45 -7.93 -6.71 key = 42 131.03 -6.71 -6.71 key = 44 117.61 -6.71 -6.71 key = 46 104.19 -6.71 -6.71 key = 48 90.77 -6.71 -6.71 key = 50 77.35 -6.71 -8.77 key = 52 59.81 -8.77 -8.77 key = 54 42.27 -8.77 -8.77 key = 56 24.73 -8.77 -8.77 key = 58 7.19 -8.77 -8.77 key = 60 -10.35 -8.77 -3.3 key = 62 -16.95 -3.3 -3.3 key = 64 -23.55 -3.3 -3.3 key = 66 -30.15 -3.3 -3.3 key = 68 -36.75 -3.3 -3.3 key = 70 -43.35 -3.3 -3.27 key = 72 -49.89 -3.27 -3.27 key = 74 -56.43 -3.27 -3.27 key = 76 -62.97 -3.27 -3.27 key = 78 -69.51 -3.27 -3.27 key = 80 -76.05 -3.27 -2.77 key = 82 -81.59 -2.77 -2.77 key = 84 -87.13 -2.77 -2.77 key = 86 -92.67 -2.77 -2.77 key = 88 -98.21 -2.77 -2.77 key = 90 -103.75 -2.77 0.45 key = 92 -102.85 0.45 0.45 key = 94 -101.95 0.45 0.45 key = 95.9916 -100.9254 0.4959106 0.4959106 key = 98.00589 -100.1489 0.1907349 0.1907349 key = 99.97812 -100.3879 -0.4959106 -0.4959106 key = 102 -102.43 -1.59 -1.59 key = 104 -105.61 -1.59 -1.59 key = 106 -108.79 -1.59 -1.59 key = 108 -111.97 -1.59 -1.59 key = 110 -115.15 -1.59 0.1 key = 112 -114.95 0.1 0.1 key = 114 -114.75 0.1 0.1 key = 116 -114.55 0.1 0.1 key = 118 -114.35 0.1 0.1 key = 120 -114.15 0.1 0.78 key = 122 -112.59 0.78 0.78 key = 124 -111.03 0.78 0.78 key = 126 -109.47 0.78 0.78 key = 128 -107.91 0.78 0.78 key = 130 -106.35 0.78 0.94 key = 132 -104.47 0.94 0.94 key = 134 -102.59 0.94 0.94 key = 136 -100.71 0.94 0.94 key = 138 -98.83 0.94 0.94

Interesting, I would have put it the opposite: It's Isp is too high for the density of its propellants

It's already armed and should deploy when it reaches its deployment criteria. I know in a normal reentry that that part of RC is working properly because I have in the past cut my drogue chute and let the craft freefall the rest of the way to main chute deployment altitude or deployment pressure (depending on how it was configured at the time). I don't THINK that aerobraking then leaving the atmosphere should have affected that. Or have you actually tried it and it wasn't working in the second reentry?

I think you're confused about a few things. IRL, propellants are seldom mixed like that. That would be, what? A 16-1 mix ratio by mass? 5-1 is more likely. Other mix ratios are used as well. (see http://www.braeunig.us/space/propel.htm) And KSP uses volume in its engine mix ratio configuration and not mass. But, that aside, I think his main concern is when it's in operating as a jet and not when it's in closed cycle mode.

This mod lets you tweak aspects of a variety of different parts, including individual axes of a reaction wheel part. http://forum.kerbalspaceprogram.com/threads/64711-0-25-TweakableEverything-1-5-For-all-your-part-tweaking-needs That's unhelpful and inappropriate GregroxMun. It's none of your business how he plays. If you don't want to help him, fine, don't help him, but don't post useless replies. It's his sandbox, let him play how he wants.

Perhaps at one time you had a config that was inserting a decoupler into the part. I have such a config that is always in my tweaks folder. It not only adds real decouplers to interstage parts but to the other fairing base parts as well. Also adds a command module so each stage equipped with one can be controlled independently.

This is actually a problem that is more common than a lot of modders seem to realize. The problem being that events often fire more than one time (as many as 3-4 times) and only one of those events is legitimate. The others often (but not always) contain invalid data (i.e. null references to objects). Apparently this is not always a problem, but when it is, it halts execution of remaining event notification for plugins or stock code that needed that event. Other times it can do worse things like halting vessel loading or entire scene loading. (sometimes manifests itself as not all of the vessel loading in or not all of it being physicalized and/or parts of the vesssel being left behind in orbit only to reappear when going on rails)

There's no question anywhere in that post. Also, need logs. How do you think your problem is going to get fixed without them? Animated Decoupler is me and I need logs because I have no idea what's happening to you, Hunt or kerbanot without them. (did you see the post directly before yours?)

Why not send me some log files (output_log.txt or player.log depending on OS) so I can take a look

Ok, so basically the two interstage parts are having a ****ing contest while they each try to prove who has the bigger fairing....