NathanKell

Apologies, I've been fairly busy the last few days. I've updated the OP to mention that if you are installing manually you should also grab Custom Prelaunch Checks, and I've also updated the Readme/frontpage on the git repo. However, I do not plan to include dependencies in release archives, as I would prefer for the release archives to just be the releases for this mod, rather than also including other mods as well. If for some reason CPLC is updated and KK is not, I don't want to be in the business of still having a release archive with an outdated mod in it (honestly, this is one reason I absolutely adore CKAN as a mod author, it means there aren't zip files floating around with outdated versions, or at least there are fewer of them. ) EDIT: in particular, I linked our Custom Prelaunch Checks repository's releases tab (i.e. the KSP-RO fork), rather than linking to the 1.8 version. It's reasonably likely we'll need to make edits going forward, so that's the live repo to grab it from. This is exactly what I mean about versioning, it's a right headache! For the similar reason re: busyness I haven't a chance to address the 1.12 issues; I had hoped I would have time this weekend but I'm doubtful I will. I'll be looking into it ASAP, and again apologies for the delay.

If there are any other fixes already done, please don't hesitate to PR them.

v13.3.0 * Fixed thrust axis (for ullage etc) to use KSP 1.2+ support for multiple thrust transforms. * Fully hide B9PS switcher in flight. * Fix some issues with tooltips. * Fix EntryCostModifiers not interacting correctly with PartUpgrades. * Use independent throttle, if active, when determining if an engine is throttled up. * No longer include dependent mods in the archive - CKAN installs them for you.

Sounds like incompatible mods--I recall that's the usual fail case on 1.12, so I'm guessing you're on 1.12. Note that right now RSS is blocked on CKAN for 1.12 due to ModularFlightIntegrator not being available, so I'd suggest downgrading to 1.11 meanwhile.

The issue is the C# object can be non-null but the underlying Unity object can be destroyed (i.e. freed in C++). Example: // For some gameobject foo MonoBehaviour comp = foo.AddComponent("ComponentType"); GameObject.Destroy(foo); bool isNull = comp == null; bool isNullCast = (object)comp == null; Now, isNull will be true, but isNullCast will be false. That's because you have a C# reference to the component, so GC doesn't clean it up, but Unity has freed the underlying (i.e. unmanaged C++) memory. This is the very reason for the speed increase from casting to object, namely that you shortcircuit Unity doing its extra work to see if the (Unity) object was destroyed. In some cases this can be safe enough, i.e. when you know that a component will either exist (and not be destroyed), or not exist at all; but if there is a chance of it having been destroyed, doing the casting is unsafe because you will not get the correct answer.

While, again, I would hope it's possible to combine forces rather than having both the upstream master and the fork around, when I get a chance I will do so. To be clear these are not RO specific bugs, but due to things such as casting GameObjects to object (which is dangerous since DRE is in the habit of operating during reentries when parts, and thus GameObjects, are destroyed), double-counting thermal fluxes and applying negative damage, and the like.

Then you maybe should ask in the thread for Raidernick's mods?

Yeah, uh, your problem is right there in the first sentence: RP-1 doesn't support science mode. Play it in career mode and cheat yourself lots of funds if you want to play in science mode.

Make sure you have updated to the latest Deadly Reentry (via CKAN). But yeah, there's a whole lot of stuff in your log that @kcs123ably dissected.

Difficulty settings->enable all part upgrades in sandbox. That will fix it.

Ugh. Sorry. Fixed. For some reason GitHub defaults to disabling that section.

There is indeed a message on the forum.

It's for general use, just like how Proc Parts and Proc Fairings are for general use, it's just we ended up maintaining them in the end. :] And yes, happy to look at whatever issues remain on KK. Please make an issue on the repo so we don't forget! That goes for you @ColdJas well, seems like you have a decent handle on the 1.12 issues.

Ah it's great that you're stepping back into more active development @Starwaster! I based the (re-)continuation of DRE's original repo on your having not updated since 1.8, and bugs remaining extant; I'm (as are the whole KSP-RO team) more than happy to combine efforts going forward, one active DRE going forward is far better than two.

In @Ger_space's absence, @AlphaAsh has given me (and the KSP-RO team) permission to continue Kerbal Konstructs and to redistribute the Kerbal Konstructs assets. Kerbal Konstructs New buildings and Launchsites This is the continuation of @Ger_space's work on @AlphaAsh's great mod, which provides the foundation to add new static objects to the worlds of KSP. This statics can also provide various functions like fuel tanks or office buildings, which provide an steady income or new Launchsites and Runways. Kerbal Konstructs provides the editor to create new bases and the tools to select new launchsites. It also provides a landing guide. Since Release 1.3 you can also edit the planets terrain, to create mountains, or flat areas where you want to place your bases. There is some Documentation in the wiki Screenshots: Installation: via CKAN. If you wish to install manually, download the latest release and also install the dependency Custom Prelaunch Checks. Source on GitHub License: Plugin is MIT, Assets are (most-)All Rights Reserved (see GitHub repository's front-page readme). This initial release not only provides compatibility with later versions of KSP, it also fixes a longstanding issue where KK broke modded (CustomBarnKit-using) careers. Special thanks to itsRyan/ryanc55 ( @iAMtheWALRUS) for fixing the issue!

What Deadly Reentry does: (especially with KSP's new handling of thermodynamics) Deadly Reentry balances part thermal properties (max temp values of skin and internal as well as various conduction properties: skin-skin, skin-internal, emission, etc) If parts get too hot then they may catch fire. (or begin to melt; depends on if they are logically flammable or not). This begins to happen at around 85% of its max temp. Some parts have had their max temp increased to compensate. Basically, think of the 85% mark as being a soft failure point leading to hard failure. As of DRE 7.6.0, this is implemented on a per area skin damage system (X+-, Y+-, Z+-). As the exterior is damaged, the interior becomes more exposed to direct reentry or supersonic heating. (the interior usally has less resistance against heating) Parts and Kerbals that experience excessive G forces for excessive periods of time may fail/die. Install via CKAN or Download latest version Source on GitHub ialdabaoth (who is awesome) created Deadly Reentry 2, based on r4m0n's Deadly Reentry; this is a continuation. This continues Starwaster's continuation of NathanKell's work on Deadly Reentry Continued. License remains CC-BY-SA as modified by ialdabaoth. Also included: Module Manager. See Module Manager thread for details and license and source: http://forum.kerbalspaceprogram.com/threads/55219 Module Manager is required for DREC to work. INSTALL INSTRUCTIONS: If you currently have Deadly Reentry installed, go to KSP/GameData/DeadlyReentry and delete everything (files and folders). Also delete any old versions of ModuleManager (modulemanager.dll for example) in your KSP/GameData folder. Merge the included GameData folder with your KSP/GameData folder USAGE INSTRUCTIONS: Be careful how you reenter. Make sure your craft has a heatshield (the Mk1 pod has a built-in heatshield, as do stock spaceplanes; the Mk1-2 needs a heat shield from the Thermal tab). For a low Kerbin orbit reentry, try for a periapsis of about 10-20km over Kerbin.

@linuxgurugamera CKAN install showed no issues, but I repackaged the archive on github so it ships the latest (4.2.1) ModuleManager, and therefore should be out-of-the-box compatible with KSP 1.12 even on manual installs. You are grabbing from the repo pointed at in CKAN - https://github.com/KSP-RO/DeadlyReentry/releases/latest - yes?

Sure! Let me update to the latest MM and rerelease when I get home. A CKAN install should not result in any compatibility warning however? Did you manually install or install via CKAN?

I'm glad that you enjoy RO, RSS, etc., but I ask that you please don't create modpack archives. Beyond them breaking the licenses of a number of required mods, they also cause support issues. Instead, please feel free to post the set of mods you use as a .ckan file, so anyone else can grab that file and install the set of mods you suggest.

Should work on 1.12 yes. Please post an issue on GitHub if you run into compatibility problems!

Procedural Parts allows you to procedurally generate a number of different parts in a range of sizes and shapes. The parts are fully tweakable with multiple options for customization of the shape, surface texture, and other parameters. The KSP-RO group is now maintaining Procedural Parts, with contributions from various members of that organization. Thanks to everyone currently contributing, and the legacy stretching all the way back to swamp_ig! Download - or install via CKAN! Report Bugs Source Features The features include Everything accessible by tweaking A broad range of shapes including cylinders, truncated cones, filleted cylinders, bezier cones. New part shapes are easy to develop and plug in, so cuboid / pill shaped / whatever else you want shaped will be able to be created. Most stuff configurable in the config file, including resources and fill ratios, tech levels, available shapes Diverse support for career mode - tank shapes, dimensions, and contents all limited by researched tech. This uses the stock Upgrades system, so if you are playing sandbox, make sure you choose to enable all upgrades in sandbox in your difficulty settings! All supplied parts are carefully designed to be as 'stock alike' as possible in their tech level requirements - You can't create a monster tank before you've discovered basic rocketry for example. Other mod support - tanks for RealFuels, Kethane, Extraplanetary Launchpads, etc. Fully recolarable via Textures Unlimited Plays nicely with Ferram Aerospace Research Multiple textures available for part surfaces. These are fully compatible with StretchySRB textures. A Module - TankContentSwitcher that can be applied to existing tanks (with say module manager) and allow their contents to be tweaked. Tweak any tank in the VAB into a Liquid fuel only or oxidizer tank. Parts available Tanks Different parts supplied for different 'groups' of fuels (Liquid fuels, SRBs, Monoprop, Xenon). The multiple part approach is to allow for tech limiting of sizes and volumes. SRBs Tweakable thrust (or burn time for real fuels). Tweak between a choice of two bells that are designed for surface or vacuum, with varying ISPs. Decoupler Tweakable diameters (with tech defined limits), ejection impulse, and can be in either decoupler or separator mode (again tech dependent). Structural Part Good for fuselage, adapters, whatever. Half as light as the equivalent tank. Batteries It's a bit rough and ready, but it works well enough. Nose Cone Specialized structural part for nose cones. The shape is limited to a smooth cone with a bounded ratio of diameter to length. Heat Shield Installation CKAN installation is preferred, but for a manual install download the latest release zip and merge its GameData with yours. Custom Textures and Texture Packs Procedural Parts is compatible with all texture packs for StretchySRBs. It's easy to roll your own texture packs too. Look for texture packs on CKAN, there are many awesome ones! Integration with Real Fuels and Modular Fuel Tanks Integration with Real Fuels and Modular Fuels Tanks is complete. Ensure you have Real Fuels version 6.1 or newer, and Modular Fuel Tanks 5.0.1 or newer. There's one or two bugs still to get through, stay tuned for updates on those two. For MFT, the existing tank types are turned into the corresponding MFT type. For RealFuels, there's an SRB which can be switched between low altitude and high altitude versions, plus a tank which can be switched between the various RF tank types. Acknowledgements ProceduralParts has an extended family tree StretchyTanks is the original module by the great Ancient Gammoner. StretchySRBs was created and updated by NathanKell and e-dog. ProceduralParts is a near complete re-write by Swamp Ig. ProceduralParts was then maintained by NathanKell, RadarManFromTheMoon, Starwaster, and TidalStream in succession. ProceduralParts is now maintained by the KSP-RO group, with contributions from many members. Also featuring Models by Tiberion Further textures by Chestburster and Dante80. Licence Remains as CC-BY-SA 3.0 Unported.

The issue was real and was apparently due, of all things, to a min and max value being flipped on a remap-range call, leading to negative damage being applied. No idea why that crashes KSP, but it seems to (but, annoyingly, only for some people--and clearly not for me or Starwaster). But thankfully (a) @Al2Me6got the crash, and (b) they were kind enough to be a guinea pig and test a bunch of different changes until we figured out what the issue was. In the process I fixed some other issues regardinig casting potentially-null Unity objects to base object and then either accessing them or trying to free them.

Sorry, I haven't patched stock stuff in literally half a decade at this point, if not more. Your best bet is asking on the Stock Configs thread.

v13.2.0 * Switch to showing effective tank volume, rather than liters at STP, of propellants in the autofill buttons. Solves the "autofill with 99% pressurant" UI bug. * Improve the value passed to MJ/KER regarding predicted residuals.

Please use MM patches to make the edits and just have a RealFuels dependency? Everything you'd want to edit, short of requiring recompiling the dll, you can patch with MM.