Starwaster

Yeah, might want to put a nose cone in front, the one that has some shielding in it. (even 10% reflective is enough). Or fly a flight plan that's a few degrees off from prograde. Kind of an ugly solution but even a little bit will throw the ray off-center. One of these days I'd like to code up a replacement for both FAR and DRE's shielding checks. Something that checks once when the vessel is loaded in and sets payload parts to be shielded by recursing from the attachment node of the fairing base. No laggy raycasts or bounding boxes. Bind to the vessel modified event so if any parts detach, break, blow up, jettison, etc etc then check again. But it's a bit of a hassle to write up and I just haven't gotten around to it.

'Outdated' doesn't sound like a message that would come from RSS. Do you mean incompatible? You could get a message saying it was incompatible if you are using the wrong version of KSP. (the latest RSS is for KSP 0.25) You could also get a similar message if you try to use RSS with the 64 bit KSP Windows client. The current version of RSS will not run if it detects the 64 bit Windows client. Other operating systems are not affected.

DeadlyReentry does not affect aerodynamics. Unless you count drag settings on any of the chute parts. I did do some changes to the stock chutes and Real Chute parts and I think that did include drag, but I use the same parts and I haven't noticed a problem with it. If it is an issue though I can revert that part of it out. (drag wasn't even an important change, the patch to those parts mostly added weak heat shielding to make them more like the heat shielded nose cones) That part of the plugin only affects how atmospheric density is calculated (and with it, how much heat is transferred from the shockwave to the vessel parts). It doesn't affect fairings and how they shield parts at all. If it worked after switching to Legacy mode then that was coincidence. Whether or not fairing enclosed parts are considered shielded is determined in one of several ways FAR is checked to see if it thinks a part is shielded. If FAR is not installed, returns false or an error occurs when getting the shielded state then.. A ray is fired from the part along its flight path to a distance of 10 meters. If the ray hits anything at all (including parts that broke off or were jettisoned from the ship) then the part is considered shielded. (there is also a stock KSP property that is checked for a shielded state but nothing currently uses that property) So basically it comes down to either FAR or a raycast, and both can fail for various reasons. FAR because (as near as I can tell) it checks a box shaped area, and parts very close to the edges of the fairing can fall outside the box. The raycast can fail if it slips between the fairing parts, which can happen when it the part is dead center and the ray passes exactly along the long axis between the fairing front. I also suspect a problem with the colliders on the front part of the fairing. Finally, because the ray is 10 meters long, parts farther away from the fairing front than 10 meters will fail the raycast test. Honestly I have always had issues with the Procedural Fairing reliably passing the raycast test. FAR is more accurate and even it can fail as mentioned above. I once had plans to use the PF parts to make a Copernicus styled aeroshell for Duna/Mars reentry and that's when I noticed it had a problem. So what you're telling me isn't really news and it's not particular to this new version. You're only just now noticing it. Sorry See my reply to White Owl above. DRE does have its own method for determining shield state if FAR is not installed or if the FAR test fails, so it's not accurate to say that fairings do nothing if FAR isn't installed. (but as mentioned, both can fail)

Raptor has a config that modifies the PBION? That's news to me... and the stock ion engine has always consumed massive amounts of electricity. It's been that way because it's more powerful in terms of thrust than a real ion engine because nobody wants to spend the time to do a realistic ion engine burn which could take weeks or even months and the stock game doesn't allow engines to operate during non-physical warp. As to electricity storage it's that way for Realism Overhaul which scales electricity generation down. (kilowatts and joules)

Found and squashed error in the RealChute patches. Will be in next update or you can download the file here (right click and save as). (overwrite the existing file in the DeadlyReentry folder) https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-RealChutes.cfg

I use KAC with RSS and have not found it necessary to do any modifications to the timewarp settings....?

Did a pull request for JRA's Soviet fix. Also inserted a missing smiley face in my post above

I'll take your word for it; I don't use CrossfeedEnabler. Seems to much like magic to me

Be sure to provide feedback in the Deadly Reentry thread.

Best not be talking about my cat!

I was thinking more along the lines of radially mounted tanks

Nathan, what do you think about something like this for RCS / RCSFX in Real Fuels? It will make all RCS units behave like stock RCS treating their resources as STAGE_PRIORITY_FLOW (overriding the resource definition) @PART [*]:NEEDS[RealFuels]:HAS[@MODULE[ModuleRCS*]]:Final { @MODULE[ModuleRCS*],* { %resourceFlowMode = STAGE_PRIORITY_FLOW @PROPELLANT [*],* { %resourceFlowMode = STAGE_PRIORITY_FLOW } } @MODULE[ModuleEngineConfigs],* { @CONFIG [*],* { @PROPELLANT [*],* { %resourceFlowMode = STAGE_PRIORITY_FLOW } } } }

It's not just unstable, it's unsupported. There is literally nothing that can be done from a modder's perspective to correct it nor much that can be given in the way of advice. It's not even Squad's fault (though some argue that they shouldn't have released 64 bit version in the first place), it's a Unity's problem. Supposedly running 64 bit in OpenGL mode is more stable and that's the first and only bit of advice I have on the subject.

Even 7000 is ok. 1500 is ultra-conservative. FYI, in the latest beta and next release of DRE, all stock and the 4 RealChute parts have had their defaults patched to what should be safe altitudes for Kerbin. And, (this conversation really should be happening in DRE thread but you're not giving me a choice) no, it is NOT hardcoded. It is configurable in the DRE settings using parachuteMultiplier (higher numbers are safer). Latest beta has difficulty settings with Easy mode giving chutes twice the survivability. Please direct all future DRE related queries in the appropriate thread

So the pack's actual part.cfg file listed LiquidOxygen? That's annoying Was that from Bobcat's original thread or Dragon01's maintenance thread? And yes, please provide your updated file; I'll look it over and do a pull request for Nathan.

Because the file BobCat_RealEngines_kerofix.cfg is configuring the NK33 engine with LiquidOxygen. That resource name was deprecated and should not be used anywhere. However the aforementioned file was not updated until RF 8.1 NK33 was the sixth part to be processed in your log file and the first engine file processed. That's why you have five fairing parts and nothing else. It's plain as day in your log. It's not possible that you have RF 8.1 installed. Or you don't have it installed properly, which means deleting the existing RealFuels folder and installing from the 8.1 zip file. (I'd actually already mentioned this but then decided that the reply was too lengthy which is why you may notice it was edited and the edit reply was that I trimmed out the extraneous bits. Sigh. So much for extraneous) Edit: Excerpt from your log. Each part compilation is boldfaced. Notice 5 fairing parts are compiled. Then the NK33 Then a nullref exception. Basically the stock KSP at that point is doing a for or foreach loop as it iterates over every single part. It gets to the NK33 and BOOM! NULLREF! That stops the loop in its tracks and it is no longer compiling parts. If Squad were to encapsulate that part of their code in a TRY/CATCH construct then it would allow the loop to continue. Silently or with the error logged depending on what they did with the catch segment. And that is officially more time than I wanted to spend on this. Bottom line is that the NK33 is being configured with an outdated resource name and that's happening in a file from a version older than Real Fuels 8.1 Here, use this to replace your BobCat_RealEngines_kerofix.cfg file. That should do it.

Does the chute part itself physically detach?

Someone already made something like this. Can't find the thread. You'll have to search it out on your own.

Ok, I read over his message and nope, not seeing anything particularly rude there. He has no idea what your skill level and calling into question the possibility of user error is not uncalled for. You're overreacting.

Said it before and I'll say it again, too much speed at too low an altitude. But go get the Deadly Reentry beta 6.3.1 Set it to Hard mode. Although it results in more overall heating, it also cuts down atmospheric density in its calculations which will help you out in the lower atmosphere. I just launched a rocket with a starting TWR 3.6 (ASL), 'hydrolox', no payload, no heat shielded nosecone and maxTemp capped at 1250. (DRE 6.2.x has it at 2500) Sole purpose was to see what it could take before burning up and it survived its launch without burning off anything. Granted it was stock Kerbin and not RSS but I didn't feel like taking the time to switch over. Anyway, give it a try.

Managing air intakes is your friend. Open intakes contribute to drag. Closing them when not needed reduces drag.

Edit: Your RealFuels is out of date and you need to redownload. Delete the existing folder and then reinstall the latest version https://github.com/NathanKell/ModularFuelSystem/releases/tag/rf-v8.1

That's what you do when you're fixing things. You test the fixes. So basically you're complaining that I tested my solution? *I have to provide information on replication?* You were the one with the complaint about the part in the first place so that's your job. Not mine. Unbelievable. That's so incredibly off-base that I don't even know where to start with that? Why should I care what radiator you use or whether or not you get to have a new one? I'd ask where you're even coming from with that accusation but forget it. I'm done with you. I'm sorry I said anything at all to you. I apologize for that profusely.

No I haven't drafted anything yet (it's Easy by default? Ok sorry I thought I fixed that. Should be Normal by default) Keep in mind that these settings are still being worked on and may change. Easy: densityExponent = 0.9 (Reentry heating doesn't start until deeper in the atmosphere) crewGMin = 10 (Kerbals can withstand up to 10g before they are at risk. ) parachuteMultiplier = 0.5 (Parachutes are twice as durable so you can deploy them higher) Normal Is mostly the original default settings except that the density exponent has changed from 0.85 to 0.8 and the heatMultiplier = 20 (reduced from 25 to compensate for the extra heating.) Hard densityExponent = 0.6 (heating starts VERY early in reentry) heatMultiplier = 1 (typically this would be around 25) temperatureExponent = 1.55 (using this to control heat instead of heatMultiplier which is ignored by heatshield loss curve) useAlternateDensity = True (this is very easy to misuse and is only used by Hard level so that lower atmospheric heating isn't excessive)(density is greatly reduced) others: Dissipation Cap (If True, then heat shields will begin dissipating more and more heat as they approach destruction level) Legacy Aerothermodynamics (older heat model used. All planets have the same heating for a given velocity and atmospheric pressure)

Agreed, YMMV, not only according to your reentry profile but depending on craft design as well.