Starwaster

Sorry, I thought we were talking about valid config nodes, not ones that are purposefully crippled (at any stage in the patching process) and there are certainly better ways of dealing with such situations. Same as #1 except not purposefully done; such a config has a more serious problem than whether or not it can be successfully targeted by a Module Manager patch given the issues it would have in the game.

Is it at least in a higher research node?

If a PART exists then it has a name. It's possible to encounter some node like stores that don't have names, PART isn't one of them being a named config node Also, if FOR[someModName] doesn't actually exist as a mod, the use of it as an execution pass will also result in :NEEDS[someModName] being met just as though someModName were installed, even if it is not installed.

Specific information was asked for and not provided; your video does not provide it nor have you provided the information in your posts. The Ascent Guidance window isn't even close to what Sarbian said. Specific suggestions have been made and no followup posts from you have acknowledged those suggestions nor have you indicated you tried the suggestions nor have you provided feedback as to the results from carrying out those suggestions.

@FreeThinker @garwel @kcs123 Guys, discussion as to if IFS needs fixing or has been fixed or will be fixed or how to fix... please do that in IFS' thread.

No that's not why it's not there. You have errors in config files that Module Manager is trying to process and as a result of those errors it does not write out a cache file. [ModuleManager] ModuleManager: 21801 patches applied, found <color=orange>2 errors</color> 1 error related to GameData/InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups.cfg 1 error related to GameData/WarpPlugin/Patches/RemoteTechFix.cfg [ModuleManager] Error - more than one pass specifier on a node: InterstellarFuelSwitch/PatchManager/ActiveMMPatches/CDT7Setups/@PART[CDT????|IfsWrapper*]:HAS[@RESOURCE[LiterVolume]]:AFTER[InterstellarFuelSwitch]:FOR[InterstellarFuelSwitch] [ModuleManager] Error - more than one pass specifier on a node: WarpPlugin/Patches/RemoteTechFix/@PART[computerCore]:FOR[WarpPlugin]:FINAL

ModuleManager.ConfigCache file is in your GameData folder (the value of that file is it tells me at a glance what changes have been made to a particular part's configs or to your physics globals or anything else that relies on config files. The log file will let me track down what is responsible for those changes)

A large part of change in MJ behavior is due to physics changes. Bricks of any variety are not going to fly the same way as they did before. Drag used to have the same impact on every part regardless of how much larger the part was and regardless of its mass. Now drag is affected by size and mass. (greater drag on larger parts but and more massive parts are affected by drag to a lesser degree) You can try to compensate by introducing changes in MJ but the bottom line is that well designed craft will ALWAYS outperform poorly designed craft and MJ will be able to fly well designed craft better than it can poorly designed craft. Garbage In - Garbage Out.

You're not giving me enough information to even take a guess at it. ModuleManager.ConfigCache and output_log.txt file (or player.log if Linux/Mac)

@custume Actually I think MJ flew that monstrosity surprisingly well. You might improve matters somewhat by enabling differential throttle (look in MJ's Options) and setting Gimbal limit to 25% (experiment with it; try adjusting up or down from 25% if needed) But honestly, you are asking the autopilot to fly an odd design with ascent guidance which expects a more conventional design and it did a pretty good job of it

Stock radiators will cool those parts. (only valid in RO because the default overcoolFactor is too high to allow cooling at cryogenic temperatures). However: they do not function at all during analytic mode which happens when you time warp faster than 100x Heat Pumps mod (once part of Real Fuels until it was removed from the mod because of reasons) will also provide cryogenic cooling and are somewhat more effective during analytic mode then the stock radiator system - but not entirely so.

I too like to flirt with high AoA, but changing it mid-ascent can definitely increase the risk of flipping... best to set it prior to launch. That generally ensures that AoA will change gradually and MJ can handle the adjustments with greater ease. Other caveats to be aware of are increased drag and increased surface heating as the craft goes supersonic.

I think part of the problem you're describing is more an issue of perception than it is a technical issue. The fact that your ablator is ablating at a low temperature is not a problem. That is how ablators work. The process is called pyrolysis and it begins at a relatively low temperature. The material used in Apollo's heat shield (AVCOAT 5026/39) started pyrolyzing at 500 Kelvin which is where both stock and DRE begin as well. Loss was due to erosion of the char layer. (the stock heat shield supports charring but it's only enabled by mods like Realism Overhaul) The issue with steep reentries vs shallow reentries has been discussed as recently as the page your post appears on; look further up the page for the reentry corridor image I posted. To recap what has been discussed previously, very shallow reentries involve lower heating peaks but longer duration heat loads and low g-forces. Steep reentries have higher heating peaks but lower duration heat loading and high g-forces. So, yes, even though your steep reentry involves higher temperatures you're hitting the dense part of the atmosphere and slowing down a lot sooner and therefore using less of your heat shield. So, I'm not seeing a problem with the two specific issues you raise (shield ablating away at low temperatures and steep reentries depleting less of your shield than shallow reentries) That said, different scaled systems require special attention to both the global physics settings and the heat shield pyrolysis numbers. DRE adjusts the shield if Real Solar System or Kerbol 10x are detected but no other star system scales are handled and the physics globals are left alone. So your specific 2x mod needs to take care of those. That's the responsibility of the modder in charge of that mod.

Because compatibility has nothing whatsoever to do with whether or not a bug exists in the release. Instead of smartassery maybe you should report the bug and then let stupid_chris decide whether or not it actually IS a bug that you found.

well I was getting ready to post about release and I go into the thread I see that question so I couldn't resist. Actually the update for 1.3.0 had been posted like almost a day before but I'd been giving it time to show up on CKAN. If I'd done them both simultaneously, I'm not sure but I think only the latest might have turned up.

I'm unlikely to add anything like ocean going ship parts at all.

Understand that even that isn't guaranteed, but this late in development, having gone to production, it's very unlikely that the part format is going to change where it actually breaks things. (though there have been the occasional exceptions, such as a certain inflatable habitat mod whose torus habitat has been known to break physics and crash the game in recent KSP updates - but that's due to it mesh rather than due to config file format)

I dunno, maybe never. Or... maybe right now.... Change Log: (both DRE 7.6.1 and 7.6.2 for KSP 1.3.0 and 1.3.1 respectively) Deadly Reentry v7.6.2 https://github.com/Starwaster/DeadlyReentry/tree/v7.6.2 Recompiled for KSP 1.3.1 Adjusted heat shield lossConst and pyrolysisLossFactor for improved survivability. Deadly Reentry v7.6.1 https://github.com/Starwaster/DeadlyReentry/tree/v7.6.1 Recompiled for KSP 1.3.0 Rescaled tempRatio for inner kerbal temps. Lower limit = 317K and upper = 322 (scalding) - Clamped to 0-1 for sound volume. Unclamped for fear reaction animation Fixed Kerbals not spawning with correct inner temp. Fixed Kerbals not healing at *fixedDeltaTime Updated files for main DeadlyReentry.cfg, Scaled up star systems support. (may not be adequate for all custom star systems. This is REALLY something that should be handled by those star system mods) Updated RealChute settings Moved inflatable configs into their own file Fixed 15m HIAD mass (what, like YOU were never off by three orders of magnitude???) Updated categories Disable overheating destruction. (Parts still burn up due to stock heating) skinMaxTemp wasn't being handled during temperature rebalancing. NaN detection changed to use Double.isNaN instead of comparing to Double.NaN

Yes but the Rockomax is a Cryogenic type

First: I suggest you do NOT implement your new resource by editing other mod files. Sooner or later they will be updated and your changes will be erased forcing you to reimplement them all over again. Instead you should create your own resource config file for the basic resource definition. For the tanks you should patch them using a Module Manager patch. Your resource definition file and your patch files should live in a single folder that you can back up and move around (such as to new KSP installations when you update KSP) If the new resource is to be cryogenic then it should not (at this time) have an hsp value. For the tank definition patches see the example below where the new resource is called deltaWeeResource (the example assumes a like named RESOURCE_DEFINITION) @TANK_DEFINITION[Default] { TANK { name = deltaWeeResource mass = 0.000012 utilization = 1 fillable = True amount = 0.0 maxAmount = 0.0 } } That patch adds a new tank to the Default tank type that can be filled with the deltaWeeResource. In the game every default tank can now be configured with that resource. You would need to do the same with every other tank type that you want to be able to contain the resource. (i.e. Cryogenic, Structural, Fuselage, etc etc)

It's fixed in the next update. I thought I had already pushed that out but looking at it, there were other changes that I wanted to wait on apparently.

Ok details. I need details about your reentry. I need to know how fast you're coming in when you first hit the atmosphere and I need to know your orbital parameters prior to reentry (ap/pe) And I need your output_log.txt file and your ModuleManager.ConfigCache file

It's most likely being hidden by RP0 and I assume the other radiators (duplicates of the stock radiators but using HP instead) are the same

In the Community Resource Pack, DepletedFuel is NO_FLOW and transfer = NONE. The reason why that was done is because the depleted fuel in the fuel rods is just the percentage of the rods that is no longer fissile. It's not a separate component to be removed or moved around. The entire fuel rod assembly would have to be removed. IRL that's certainly a thing when you want to reprocess your nuclear fuel, but no mechanism was ever put in place for doing so except maybe in a few nuclear specific mods.

No don't think so