CoriW

@severedsolo - Glad I could write a good novel for you to read lol! While I'm not necessarily an expert in coding or anything in particular, I will admit that I tend to not be the most patient person around and thus I've learned to do many things in order to tweak, fix, or update things when needed instead of having to rely on others to do so for me, as I hate asking people to do things without giving anything in return. So that being said, I'm glad I could help with figuring out the problem and coming to a solution for it. Regarding the PR on Github, it took me awhile just to figure out how to get the source code into an editor to tinker with it in the first place and recompile it for testing. So if I can figure out how to actually do a PR I will submit the changes but I've just had a look at it now and I'm a bit lost, so I will need to do some more research. (Also have a lot of stuff going on IRL at the moment so I'm unsure if I'll have the time or not to get around to it.) That being said, if you're interested at all, the changes I made were actually relatively small and if I can't figure out the PR thing I could just message you with the code changes I made and you could make the modifications to the mod and post an update. DM me if you're interested in that. (Or perhaps you could help me figure out how to do a PR lol) As for the insights into why it hung, that's some good information and makes a lot of sense. I remember when I was initially looking through the code I seen the bits that handle the UT to Date String stuff and suspected that had something to do with it, but didn't look much further into it and just started implementing the stuff to remove and replace the SolarDayLength checking. Thanks so much for clarifying it and letting me know I was on the right track. The completionTime being Infinity rather than 0 was a strange oddity, but it's probably better it happened that way since if it was crashing upon savegame load instead of when I clicked the button, I may have had a harder and longer road figuring out what the actual problem was, definitely better it happened that way in the end lol.

So I finally got around to playing with this mod... Beautiful.

Just curious, what is the intended "course of it's life", since you say it will officially lose support in just under 3 months time? 5 installations seems fairly optimistic for such a short timeframe taking into consideration that you've stated it took a year and a half to create this pack. Unless the currently unreleased installations are all either partially complete already, or are intended to be relatively small updates compared to the size of the initial release? Not being a downer or anything this question just popped into my head as I was reading the post.

Hello everybody.. Just a bit of an update from my few posts above, we were able to pinpoint a bug that causes some problems related to having your homeworld on a planet which is not orbiting the sun, it is being looked into by the Kopernicus devs to see if anything can possibly be done to correct the issue, aside from that I discovered some very obvious incompatibilities related to tidally locked homeworlds in combination with some other mods like Bureaucracy and Kronometer. Now that being said, if anyone here uses Kcalbeloh along with it's HomeSwitch feature and also uses the Bureaucracy mod, you're going to absolutely need the modified DLL I've provided over in the Bureaucracy thread or else it can cause game crashing issues. Now of course I wouldn't have only posted in this thread about something not related to this mod, as the second thing I've done can be used whether you're using Bureaucracy or not. For anyone who uses Kcalbeloh's HomeSwitch feature, I have created a modified version of the Kronometer mod which allows setting custom day and year lengths for your HomeWorld. Normally the Kronometer mod suffers the same mod incompatibilities which I mentioned above with tidally locked homeworlds, however with my modified version of Kronometer you can bypass the code that causes the bug by manually setting these numbers. Both the Bureaucracy and Kronometer modified DLL's are provided over in the Bureaucracy thread for anyone who is interested. EDIT: If anyone is curious the settings I'm using for Efil as my homeworld is a day length of 52857 and a year length of 70940632 (the year length is set to the orbital period of the parent body (Anehta) since it's the one that actually orbits the star)

Hey everyone, so I felt that since it's been several days since my previous novel of a post and the progress I have made with the issue.. That it would be okay to make another post. I have been able to use the source code for the Bureaucracy mod and modify it to have a couple new settings which can work around the issues of having a homeworld which is not orbiting the Sun, basically these new settings allow you to set a custom day length (in seconds) and a custom year length (in seconds) instead of having Bureaucracy automatically set these values based on the solar day length and orbital period of the homeworld. So in my particular situation (having a homeworld which is a tidally locked moon of a gas giant) the game was crashing when I clicked the Bureaucracy button because it was trying to automatically set the day length based on the solar day which wasn't able to be pulled properly because the homeworld is tidally locked. So my attempt to make the planet not tidally locked was to just set it's rotation period to it's orbital period, which prevented the crashing but due to a bug it made the planet rotate much faster than intended. So now that I have modified the Bureaucracy mod to accept custom day and year lengths, I am now able to leave the homeworld tidally locked and simply specify in the Bureaucracy settings what the day and year lengths should be, thus Bureaucracy doesn't crash the game and my homeworld rotates normally. (It also allows interested options like setting the length of a year to the orbital period of my homeworlds PARENT body instead of my homeworlds orbital period, since it is just a moon after all.) Now that's just my particular use case, but this could come in useful to anyone who encounters issues due to a tidally locked homeworld. Seeing as this mod is posted under an MIT license I am freely able to provide this modified DLL to anyone who wants or needs it. You may download it with the link below. One thing I will note is that by default I have the set the length of a day and year for Kerbin, if you have a different homeworld (which is the only reason you'll need this modified DLL.. Then make sure you change the settings to match the day and year length of your homeworld) LINK: Mod_Bureaucracy_v2.zip (NOTE: THIS DOWNLOAD ONLY CONTAINS A .DLL FILE, YOU MUST DOWNLOAD BUREAUCRACY FIRST AND THEN OVERWRITE THE EXISTING DLL WITH THE ONE PROVIDED IN THIS DOWNLOAD.) On another note, one problem with this solution is that you end up with the in-game clock not actually matching the length of your days.. for example my homeworlds day length in "Kerbin" time is 2 days, 2 hours, 40 minutes, and 56 seconds, however since Bureaucracy reads that amount of time as 1 day for my homeworld, that means that Bureaucracy says my next budget is on day 30 however in "Kerbin" time and on the clock in the top left corner the next budget actually occurs on day 73. At first I figured that this could potentially be solved by the Kronometer mod, however I quickly discovered that the "useHomeDay" and "useHomeYear" settings were also plagued with incompatibility with tidally locked homeworlds due to the solar day issue.. So I've gone ahead and used the source code for the Kronometer mod and modify it to have a couple new settings as well in which you can set custom day lengths and custom year lengths (in seconds). This way, if you're using both my modified version of Bureaucracy as well as my modified version of Kronometer and you set the day lengths and year lengths to be the same in both mods as your homeworld, what happens is that Bureaucracy measures one day as the actual rotation of your tidally locked homeworld (in my case 1 day is 14 hours, 40 minutes, 56 seconds) and Kronometer actually changed the clock in the corner to display that a day actually takes that same 14 hours, 40 minutes, 56 seconds to pass, and the same thing applies for the length of a year for both Bureaucracy and Kronometer. (in my case with the year being the orbital period of the parent gas giant, that is 1342 days, 1 hour, 48 minutes, 57 seconds) Luckily Kronometer is also posted under an MIT license, so I am freely able to provide the modified DLL to anyone who wants or needs it. You may download it with the link below. One thing I have to note with the Kronometer settings, is that in order for the custom day and year length settings to apply, you must also enable the "useHomeDay" and "useHomeYear" settings. (change them to True) LINK: Mod_Kronometer_v1.zip (NOTE: THIS DOWNLOAD ONLY CONTAINS A .DLL FILE, YOU MUST DOWNLOAD KRONOMETER FIRST (LGG VERSION) AND THEN OVERWRITE THE EXISTING DLL WITH THE ONE PROVIDED IN THIS DOWNLOAD.) LINK TO LGG VERSION OF KRONOMETER FOR KSP 1.12: https://github.com/linuxgurugamer/Kronometer/releases/tag/1.12.0.2 Also in the Kronometer modified DLL I did also add another setting that may be useful to anyone with a tidally locked world, by default if Kronometer detects a tidally locked world it will try and set the year length to equal the day length, however if your homeworld is a moon of another planet you may not want this to happen, and may want to use the length of the parent bodies orbit as the year length. In this case simply enable the "tidalOverride" setting and this will prevent Kronometer from trying to modify your year length. Lastly AND VERY IMPORTANTLY I will note that while I have made these modifications to fix problems within my own game and have decided to share them as a good gesture for anyone else having similar issues with mod compatibility, I am not interested in taking over or continuing any mods or maintaining anything for the long term. If you use my DLL's and something breaks, you can DM me (don't post here as it may be considered off topic) and I may try and help fix the issue. But I must stress these modified DLL's are USE AT YOUR OWN RISK, they shouldn't have any problems as I am going to be using them in my own game, but if you intend to use them on an existing save for example, I strongly recommend backing up your save. You have been warned. EDIT: Was just doing some testing... Definitely something interesting seeing a year be this long...

Hey, so I've just gone ahead and thrown together a new install with just Bureaucracy, Beyond Home and it's dependencies. It appears to work properly with that setup so it must be something unique to how Kcalbeloh is switching the homeworld that is different from how Beyond Home does it? I'll have to poke around later when I have a bit more time but maybe compare how Beyond Home does the HomeSwitch to how Kcalbeloh does the HomeSwitch, perhaps there's something different between them. EDIT: Also just tested Kcalbeloh with HomeSwitch set to Suluco instead of Efil, same issue.

Hey so I'm having a problem between this mod and the Bureaucracy mod and I'm unsure whether it has to do with this mod or that one, but it's a problem that occurs only when using the HomeSwitch option in Kcalbeloh.

@severedsolo Hey I have a question, not sure if you're still around or not.. But I have a fairly extensive modlist (almost 200 mods) and I had installed a planet pack (Kcalbeloh System) and did a playthrough and everything worked fine, no problems (with any of my mods). Then I decided to enable the option within the Kcalbeloh System mod to use it as a system replacer instead of an addition, which also switches the homeworld to one of it's planets (which internally it keeps the name "Kerbin") and now when I load up the game and get to the space center, when I click on the Bureaucracy button the game immediately freezes and stops responding, then if I click anything it just crashes. The logs don't throw any errors or anything, it's like the log stops the moment I click the Bureaucracy button. Any ideas what could cause something like this? Just because my modlist is so extensive, I figured I'd ask if there's anything obvious could be causing that issue, but if needed I can tear apart my install to see if I can figure out the problem. Perhaps testing it on an install that only has Bureaucracy + Kcalbeloh (SystemReplacer) will be in order. EDIT: Okay so I decided to do a basic install with just Bureaucracy, Kcalbeloh and it's dependencies.. Plus the dependencies for it's dependencies. Then I went ahead and without changes any settings in Kcalbeloh System (so that stock planets are kept, Kerbin is default homeworld) I loaded up the game to see if I could click the Bureaucracy button and I could! After this I closed the game, changed the settings to set Efil in the Kcalbeloh system as my homeworld and to remove the Kerbol System and replace it with the Kcalbeloh system. At this point I reloaded the game and started up the game, it took me to the space center and I attempted to click the Bureaucracy button. The game immediately froze (though I could still hear sound) and I waited for awhile and it just hung there frozen, I clicked again and it crashed. The log file does not appear to have any useful information in it regarding the crash (it's like when the game freezes, the log just stops logging. LINK: THE KSP.LOG FILE LINK: THE PLAYER.LOG FILE KSP Version: 1.12.3 OS: Windows 10 Not sure if this is a Bureaucracy problem or a Kcalbeloh problem or both so I'll also tag @Jason Kerman here as well. EDIT: I've also just verified it does not seem to matter whether RemoveKerbolSystem is True or False in the Kcalbeloh settings, this problem seems to occur only when I have Efil set as my homeworld. (Haven't tested the other selectable homeworld in the pack but I'm assuming this is an issue somehow with the original Kerbin not being the homeworld. IMPORTANT UPDATE Okay so... I think I've potentially found the issue. Even though the log file didn't have any errors when the freeze/crash happens, I decided to open the log and filter for Bureaucracy anyways to see if it was loading correctly and to my surprise I stumbled upon this line.. [LOG 19:32:41.608] [Bureaucracy]: Next Budget at Infinity Now obviously the next budget being at infinity is a problem.. Presumably the problem that causes the issue when the button is clicked and it tries to open the Menu. So the next step was to make sure the settings were correct and then check how exactly it used those settings. Checking my Bureaucracy settings file, I found the "TimeBetweenBudgetsDays" to be set at 30, this seemed fine. Then I went to check the Bureaucracy Wiki, specifically the "Settings" section and found the following line of interest; Now notice the brackets.. "automatically adjusted to your Homeworlds day length" .. That struck me as possibly relevant, as Efil is orbiting close to a gas giant and Suluco close to a star, upon checking the config files for both planets I found that both were tidally locked. So now I had to see how that would actually affect the "automatically adjusted" calculation in Bureaucracy and so I went and checked the source code for the mod, where I found this line of code. BudgetManager.Instance.NextBudget = new BudgetEvent(Planetarium.GetUniversalTime()+TimeBetweenBudgets*FlightGlobals.GetHomeBody().solarDayLength, BudgetManager.Instance, true); Now let's note here.. It takes the current time, then adds the time between budgets which is set to 30 days... Then... it multiplies that by the "solarDayLength" of the homeworld... So what exactly is the solar day length of a tidally locked planet anyways? The first thing I did was open the Kcalbeloh config for a planet that was not tidally locked, in this case "Ahtpan" and found it had a set "rotationPeriod" of 46870... and then upon checking the Kcalbeloh configs for both Efil and Suluco I found that while "tidallyLocked" was set to True, there wasn't actually and "rotationPeriod" set. (Perhaps it being tidally locked overrides the rotation period anyways?) I also noticed the absence of anything resembling "solarDayLength". So my next step was to check the actual Kopernicus log files for the homeworld, in the current test this is Suluco and in the "SulucoHome.Body.log" file I found this line. [LOG 19:32:21]: solarDayLength = 0 BINGO! If we take the calculation Bureaucracy uses to calculate the next budget cycle, we find that it's taking the universal time, then adds the 30 days from the settings, then multiplies it by... 0. This of course results in the next budget being set to... 0. Apparently when loaded this then simply acts as "Infinity" as shown in the KSP log file above. I presume that clicking the button triggers it to check for the next budget cycle and thus the game freezes because it can't figure it out. So now I had to figure out how to make a tidally locked planet still function as a tidally locked planet without being a tidally locked planet. So I figured, why not just set "tidallyLocked" to false and then add a "rotationPeriod" which precisely matches the Orbital Period of the planet / moon. So I installed Kerbal Engineer Redux and looked at the Orbital Period for Efil, which was 2 days, 2 hours, 40 minutes, 56.806 seconds, converted that into seconds (52,856.806 seconds) and then went into the "EfilHome.cfg" file for HomeSwitch and set "tidallyLocked" to false and "rotationPeriod" to 52856.806 . When loading the game, I now get this in the KSP log. [LOG 20:39:14.042] [Bureaucracy]: Next Budget at 1585704.17999999 And with that... I can now click the Bureaucracy button and Efil will rotate as if it were tidally locked. In theory. EDIT: Okay so while the game is not crashing now, I've just noticed that for some reason even with Efil's rotation period set to 52856.806, which should be 2 days, 2 hours, 40 minutes, 56.806 seconds... It's actually rotating once every 20 minutes, 18 seconds. Not sure what's causing that. Also the auto-alarm for the next budget is set to 73 days, while in the budget windows it says 30 years 44 days.. yikes. EDIT: For anyone wondering what the issue was with the rotation time mentioned in the last edit, it turns out that this has to do with a bug which is related to having a homeworld that is not orbiting the "Sun". This bug is now being looked into (not by me) to see if there is a potential fix which can be implemented into Kopernicus to correct this issue.

Oh that's a good point, I hadn't done much testing aside from just opening the game to see if anything visually interfered with anything else.. Further testing will be in order. I also considered only reducing the distances to 0.75x or 0.6x and seeing if the icons still drift. Will do some testing later today and see if it actually works properly or not. It is unfortunate that we have the issue of the icon drift in the first place but I don't believe there is really anything else that could be done about it other than moving the homeworld closer to center. EDIT: I've found an alternative solution which doesn't require moving anything around. I play with the Waypoint Manager mod, and with it you are able to both create custom waypoints as well as remove the stock waypoints. Fortunately the custom waypoints are not subject to the same drift as the stock ones.

Hey there again, apologies for the double post but I have a contribution again. So after downloading and installing the new Alpha version of HomeSwitch, before messing around with it I wanted to create a ModuleManager patch for Research Bodies that could automatically detect your Kcalbeloh System Settings (HomeSwitch, Wormholes, and RemoveKerbolSystem) and adjust the Research Bodies configuration accordingly.. However after almost the entire day of messing around with it I have determined that it doesn't appear that Research Bodies configs were made in a way that can be modified or interacted with by ModuleManager, unfortunately. Or if there is, I can't figure out how to do it. So as an alternative, I've put together a ZIP folder that has a folder structure in it that allows users to click through which options they want and be presented with a GameData folder with the Research Bodies configuration for their game which they can simply drop into and merge with their GameData folder. Now I need to clarify that I do not expect this will be added into the Kcalbeloh mod files as it would make the installation process longer and more involved than a simple drag and drop like it is now, but I am providing this file anyways for anyone who wants it. Currently the alpha download of the Kcalbeloh System version 1.0.2 only includes the ResearchBodies configuration for Wormholes = True, HomeSwitch = False, RemoveKerbolSystem = False. LINK: Kcalbeloh_ResearchBodies_Options.zip EDIT: Also, if anyone is annoyed by the icons for the KSC and other launch sites on Kerbin either drifting or floating away from the planet, I've made a quick config that will simply half the SemiMajor Axis of the stars. (Maelg, Sunorc, Aralc System) Note that this will only work if you are using the new HomeSwitch and have RemoveKerbinSystem set to TRUE, otherwise Kcalbeloh will still be too far away from Kerbol and this will not fix it, however if you have RemoveKerbinSystem set to False and are having this issue, adjusting the "DistanceFactor" in the Kcalbeloh System Settings file may help reduce it.

I'm not super familiar with discord. I have it but never use it, where would I find your discord server?

Hey again.. So even though I just found this mod today, I use Final Frontier and so I felt compelled to do something about it. After somewhere in the realm of 6 or so hours of modifying, compiling, and exporting a whopping 588 unique images... I now have a collection of ribbons that you can simply drop into your GameData folder which will enable Final Frontier functionality for the Kcalbeloh System. (And yes, it was very tedious and my wrist is a bit sore from all the clicking lol) LINK: Kcalbeloh_FinalFrontierV3.zip

@Jason Kerman Quick question, does homeswitch remove the stock planets / kerbol? If not, how would I go about making it do so? EDIT: Random side note I've written up a config for this mod for Research Bodies. Haven't tested yet but it should work, if you want to include it in a future release go for it.

Just going to note that if you do use Near Future Electrical and do not opt to install the "NFElectricalRTGPatch" from the Extras folder, then the above patch is unnecessary as Near Future Electrical won't replace stock RTG modules to begin with, and by default the Near Future Electrical RTG even uses the basic "ModuleGenerator" by default. That being said I'm not sure if CKAN will install Near Future Electrical's RTG patch by default or not as I don't use it. Perhaps I'm a dinosaur but I still install mods manually. EDIT: On a side note, I just went ahead and did some patching for the mods that I use, figured I'd share the config for anyone else who wants it. It has patches for the Stock RTG, NearFutureElectrical RTG, RLA Stockalike RTG, Stock LV-N Nuclear Engine, Kerbal Atomics Nuclear Engines, and Missing History Engines... Also it does check for the presence of the NearFutureElectrical decaying RTG module just in case you've accidentally installed it. Also just going to note I haven't tested these patches yet, though they should work, use at your own risk. I'll edit the config if I find any problems with it. Oh and if anyone does use it, I haven't balance tested anything either I just put in numbers for efficiency and volume that sounded good based on the possibly misguided assumption that larger RTG's and nuclear engines would be more slightly more efficient and hold more, where as smaller RTG's and nuclear engines would be slightly less efficient and hold less.

Is this compatible with Parallax 2.0? Not adding in fancy scatters and stuff but from my understanding the mod has to have a config to be compatible. @Lt_Duckweed

Would this be compatible with an existing save? I started a new save last week and didn't stumble upon this mod until later on. @Lt_Duckweed

Just a heads up for anyone who uses the Probes Before Crew mod and it's bundled contract pack, Bureaucracy's contract interceptor does not properly detect and modify the contracts starting with the first Mun contract and everything beyond that. To get it to properly intercept and modify the contracts, I had to go into the Probes Before Crew contract configs and remove the rewards from the individual contract parameters, combine them, and add them back in as rewards for completing the entire contract. Just thought I would post that here so that anyone using these mods together will know to correct the issue prior to any contracts being generated incorrectly.

Just going to drop this here, my efforts at attempting to work out compatibility between System Heat and Rational Resources.

Currently putting together a modlist after a long hiatus from the game... Just took a quick peek at the configs for System Heat as well as Rational Resources to see what's up. Note I haven't even touched anything to do with this game for a couple years atleast, so I may be a bit rusty but I think I figured out whats going on. It appears that System Heat completely renames the "ModuleResourceHarvester" modules on drills to a different "ModuleSystemHeatHarvester" and then when Rational Resources attempts to copy the "ModuleResourceHarvester" module for it's various resource gathering modules, the base module it's trying to copy simply doesn't exist as it has been renamed. This explains why the drills don't produce any resources since the modules to produce them do not exist. The solution to this problem in a way that would make the mods play nicely together from what I can tell would be to ensure that the MM configs for Rational Resources which handle creating these "ModuleResourceHarvester" nodes is loaded BEFORE the MM config for System Heat is loaded and renames the Modules. That way all of the resource harvesting modules would be in place for the drilling functionality and System Heat would have the Modules renamed to it's module "ModuleSystemHeatHarvester" for it's purposes. The relevant files appear to be "GameData\RationalResourcesCompanion\CRP\Opt-in_DrillOMatics.cfg" from Rational Resources. "Extras\SystemHeatHarvesters\Squad\SystemHeatDrill.cfg" from System Heat. "Extras\SystemHeatHarvesters\PlanetaryBaseInc\Drills.cfg" from System Heat. (Note Rational Resources does not appear to yet have configs for Drills from Planetary Base Inc.) "Extras\SystemHeatHarvesters\genericHarvesters.cfg" from System Heat. Note this is what I've gathered after about 10 minutes of digging around, if there are further interactions with Rational Resources which require the Modules continue to retain the original "ModuleResourceHarvester" name then the mods would be rendered incompatible unless that could be changed. But based on what I've seen so far, my suggestion above will likely fix the compatibility problem. Note that this also only concerns Drills and does not touch on any of the other resource gathering parts if there are other incompatibilities between these mods. That all being said, I'm still deciding if I want to put forth the effort to make some compatibility patches for these mods in order to use them together, or if I just want to drop one of the mods from my list. Depending on the time I have available I may or may not return with some configs, but at least I've found a part of the compatibility problem and made it known. @JadeOfMaar EDIT: Adding onto the above, it appears that the "Extras\SystemHeatHarvesters\genericHarvesters.cfg" file from System Heat may have some unwanted interactions with AtmoScoops as they utilize the "ModuleResourceHarvester" module and consume ElectricCharge as an input resource which fits the criteria for System Heat to make it generate heat using it's new module... But then, in the AtmoScoops module it also specifies "GeneratesHeat = False" which in theory should prevent System Heat from making it generate heat, but that also depends on whether System Heat's custom module obeys that line or not. Will have to dig a bit deeper. EDIT: Hmm, oddly enough it actually seems like it would be easier to make System Heat compatible with Rational Resources than it would be to make Rational Resources compatible with system heat. This is because System Heat swaps out a bunch of stock modules for custom modules, but not in the way of deleting the original modules and replacing them with completely new ones, but instead just renaming the module to use a modified version of the original. For example for "ModuleResourceHarvester" it simply renames the module to "ModuleSystemHeatHarvester" and then removes some of the un-needed bits (for it's purposes) from the module and adds in some stuff that it uses instead. On the flip side, Rational Resources seems to leave the modules generally intact, but relies heavily on copying the existing modules as well as modifying a few. However it does not change the names of the modules, those remain stock. As a result of these interactions, it becomes an issue of this; You can modify the modules and then convert them to custom ones, but you cannot convert them to custom ones and then modify the new custom modules. Well.. You could, but it would be much more involved. The easiest solution I am seeing is to actually just ensure that ALL System Heat patches are loaded AFTER Rational Resources ones. This way Rational Resources is able to do all of it's modifications to the stock modules BEFORE System Heat hijacks them and converts them to it's custom modules, and they will still retain the modifications made by Rational Resources even after being converted. Originally (above) I had stated that the solution was to get Rational Resources to load before System Heat, but there are significantly more patches within Rational Resources that would need to be modified to accommodate this, whereas to modify System Heat to load after Rational Resources takes significantly less effort. So far with my limited memory of how module manager works (as mentioned I've been on hiatus for awhile, I'm pretty rusty on this stuff) it seems to me that in theory all that needs to be done is every patch inside of the "Extras\SystemHeatConverters" and "Extras\SystemHeatHarvesters" folders within the System Heat mod simply need to have :LAST added to the end of the patch to ensure that all of those patches are loaded after everything related to Rational Resources. (Note this doesn't apply to the "genericConverters.cfg" and "genericHarvesters.cfg" files as these patches already use :FINAL which is loaded after :LAST patches. Now that being said I'm not up to date on best practices with module manager so please if anybody thinks this is an inadvisable solution, let me know. EDIT: I've linked to a download of the modified Module Manager patches for System Heat intended for use with Rational Resources below. Please note that these patches should work in theory, but I have yet to test them personally due to time, they were created based on everything outlined in this post. Use at your own risk. Sharing these modified configs under System Heats original MIT License LINK (10/14/2022 10:00PM EST, Discovered that LAST is mutually exclusive with FOR. It is now corrected.) EDIT: Also here's a bonus.. Compatibility file for Planetary Base Inc Drills and ISRU for Rational Resources. Drop it into "GameData\RationalResourcesCompanion\" folder. 00_PlanetaryBaseInc_Opt-in.cfg

Okay, I didn't have any luck getting it to work on 1.7.3 with the newest KS3P.

Use Leatherneck's recompile from page 25 of this thread, works fine for me on 1.7.3.

Seeing the same thing here as well.. Not at the computer at the moment but will get more info and logs tomorrow.

Question, for the KS3P config is it the "DefaultConfig.cfg" file that I'm supposed to replace with it?

@physicsnerd @DR_RDR @Sharp12 @SilverState @Sir Mortimer Okay so regarding the issue with the Kerbalism and SSPX gravity rings not appearing in the VAB, I've done some digging and found the culprit to the problem and have come up with a solution. The first thing I did was look at the config files for all of the missing parts and ensure that all of them had researchable tech nodes and categories set in the VAB, which all checked out. After that I opened up the Module Manager cache file and searched for the configs for the parts in there.. Suspiciously it said that all of their categories were set to "none". Upon seeing this I figured some patch somewhere was doing this and I opened up the Module Manager log and searched for any patches applied to those parts (I have 178 mods so this took awhile). After looking through each and every patch that touched those parts I found only a single patch even mentioned the category.. And set it to "none".. The cultprit patch is one which comes with Kerbalism itself, located in the file "GameData\Kerbalism\Support\CCK.cfg". Within that file, there is the following.. // @PART:HAS[@MODULE[GravityRing]]:NEEDS[CommunityCategoryKit]:AFTER[zzzKerbalism] // { // %tags = #$tags$ cck-lifesupport // } @PART:HAS[@MODULE[GravityRing]]:NEEDS[CommunityCategoryKit,!FilterExtensions]:AFTER[zzzKerbalism] { %category = none } As you can clearly see, if you have Community Category Kit installed, which is a dependency for several other mods, but don't have Filter Extensions installed (which is why some people found the fix was to install Filter Extensions mentioned earlier in this thread) the patch will then proceed to set the category of all parts containing the module "GravityRing" to "none", but not set the tags required to put those parts in a CCK category which results in the parts vanishing from all VAB tabs. There are two ways to then fix this problem, the first option is to simply uncomment the commented out patch which will result in the parts using the CCK category, or the second option is to comment out the second patch which will result in the category of the parts remaining unedited, leaving the parts in their original categories. For those who want a quick copy paste, here you go. // @PART:HAS[@MODULE[GravityRing]]:NEEDS[CommunityCategoryKit]:AFTER[zzzKerbalism] // { // %tags = #$tags$ cck-lifesupport // } // @PART:HAS[@MODULE[GravityRing]]:NEEDS[CommunityCategoryKit,!FilterExtensions]:AFTER[zzzKerbalism] // { // %category = none // } I'd submit a request of some sort on Github but I have no idea how any of that works as I've only ever downloaded stuff off there.

Noticed this as well.. Any known fix? If not I'll perhaps do some digging tomorrow.