Shadow Wolf TJC

It's been a while since I last posted an update, but I think I'm currently going to be on hiatus for an indefinite period of time, until interest in KSP comes back to me again. However, I did already perform another test with the tech tree, and I have some results: 1: Even after updating Skyhawk's stock tech tree patch to account for items found within the Community Tech Tree in addition to the stock tech tree, I was still noticing that some items remained within Community Tech Tree nodes (which I'd assumed were supposed to be cleared out fully, and then deleted). Perhaps some other mods were still trying to add techs to stock and/or Community Tech Tree nodes late in patching? Possible solution: Perhaps it's not enough to change tech tree nodes before Module Manager loads the other files? Perhaps an additional round of tech-tree patching, this time around the end of patching, would also be needed? 2: I've also noticed that some mods, such as the Flying Saucers mod, were also adding their own tech nodes. Possible solution: These kinds of mods that add in their own tech nodes may need their own mod-specific patches which either move all those techs to one or more of Skyhawk's own tech tree nodes, or alternatively, said tech nodes may instead be kept around, with Skyhawk only changing some of their prerequisites. 3: I've noticed that some mods had scripting that would create duplicates of existing parts that had certain tweaks, such as engines that were burning a different type of fuel, or intakes that, instead of sucking in regular old oxygen (from planets such as Kerbin or Laythe), could only suck in air from certain planets (like Eve or Jool), and were not being moved to more proper tech nodes by Skyhawk, which seemed to rely extensively upon moving individual parts to their proper tech nodes. Possible solution: I was already thinking about adding in some further patching that, instead of manually moving individual parts to their proper tech nodes within the Skyhawk tech tree, would've auto-detected parts with specific functions (such as being an engine, a probe, a battery, a fuel tank, etc.), and like with the stock tech tree auto-adjustment patching, would've automatically sorted them to specific tech nodes. However, I also have reason to believe that such a feature would've also possibly worked on these auto-added parts? I don't know when I'll come back to KSP, so I hope that others would be able to try out these kinds of changes on my behalf.

IMO, being able to land ANYWHERE on the homeworld safely instead of back at the KSC would've gone against the spirit of this mod's focus on reusable spaceplanes by making these missions little different from the stock game missions, where a traditional rocket design would've likewise sufficed, with a command pod that would've been designed to be jettisoned and land back into the water or on the surface without any form of guidance. It was for these reasons why I opted to modify those missions, plus the interplanetary missions, with objectives to land the command vehicle back at the KSC safe and sound, either as a spaceplane or as a SpaceX-styled tailsitting lander.

While looking at StockScienceSupport.cfg to get a feel for how I'm going to tackle the Community Tech Tree's integration, I realized that the whole thing was, besides being organized based on tier and a top-to-bottom order on the stock tech tree, a largely disorganized mess. (I would've rather preferred to order everything based on category, such as construction, communications, or probes for example.) In addition to integrating the Community Tech Tree with Skyhawk Science System in a way that made as much sense as possible, I also ended up basically restructuring the Stock Tech Tree integration in a way so as to accomplish the following goals: So that the early half of the tech tree, up to around tier 8 or 9, would be almost guaranteed to contain at least 1 part from stock KSP + expansions, mostly by spacing out the techs better, while the latter half would've been better serviced by integrating the Community Tech Tree within it. So that the tech tree would be better capable of handling whichever new parts modders add, that would require either the Stock Tech Tree, or the more expanded Community Tech Tree, namely by rearranging it based on best guesses as to which tech nodes modders would most likely want to add their parts in order for them to be balanced in both Science and Career modes. So that the tech tree could be further refined in a later round of patching to better sort categories of parts into their designated tech tree branches (such as moving solar panels, radiators, communicators/relays, and probes from, say, the electrical tech tree branch, into their respective tech tree branches). So that Skyhawk Science System wouldn't need to be as dependent on Bluedog Design Bureau as it is claimed to be (according to CKAN), and could instead opt to mark BDB as a strong recommendation instead of as a dependency. Although this revised tech tree is just a rough draft for now (with oodles of comments thrown in), and although it's been designed to expect a later round of patching to better sort parts into their proper tech tree branches (which I'll need to figure out a way to accomplish said feat), I've decided to give everyone a sneak peek of it by letting them download it from here.

Those few snippets may not have been of apparent help to you, but to me personally, they were enough for me to find out WHERE the problem was located. Nowhere in my hundreds-of-MB-sized .log file (admittedly due to stress-testing my KSP game by having so many mods installed, though regardless, since you had taken too long to come up with a reply, that .log file was, alas, most likely overwritten in a later session) would I necessarily know WHAT the problem was specifically, let alone HOW to fix said problem. All I had learned was WHERE the problem originated from, and like the eager programmer that I was (though admittedly, I'm new to KSP modding, though not to modding in general), I had gone out to do the following: According to those snippets that I had provided from my .log file, I immediately realized that it was a problem with one of the contracts, so I checked to see which mod had any contracts named "KerbinOrbitalTelescopeDeployment" and "MunOrbitalTelescopeDeployment", and I quickly found that both originated from within this mod here, within the file directory "MunSeeker/ZZZ_RadioTelescope/MunSeeker_ZZZ_RadioTelescope_Contracts.cfg" to be more specific. Once I had found out where the problematic contracts were located, I did a bit of routine digging, with the variables "targetBody" and "Orbit" as my leads, and soon enough, I noticed that targetBody was set to either "Kerbin" or "Mun", both of which would've obviously ceased to exist if using a system replacer mod like RSS. (Note that I was also dealing with other contract mods that were bugging out at the same time, including Planes with Purposes, Oddiseo Corp Contracts, and Research Bodies, and as it turns out, they too weren't designed to deal with stock system replacement mods either.) For RSS, I had initially opted to simply replace any instances of "Kerbin" with "Earth", and any instances of "Mun" with "Moon", though that was meant only as a temporary solution until I could figure out a way to replace those via patching. However, I had later discovered that, if "HomeWorld()" was used in place of "Kerbin", and if "HomeWorld().Children().First()" was used in place of "Mun" (thank you History of Spaceflight for providing me with examples of contracts that would work, even when using a system replacer mod), then perhaps even those patches wouldn't have been as necessary. In short, I recommend the following changes to "MunSeeker_ZZZ_RadioTelescope_Contracts.cfg": Replace any instances of "Kerbin" with "HomeWorld()", and any instances of "Mun" with "HomeWorld().Children().First()", except within descriptions If you wish to dynamically reference Kerbin, Mun, or any other celestial body within in-game text descriptions, regardless of which solar system the player is starting out on, then what you could do is, instead, replace any instances of "Kerbin" and "Mun" with "@/targetBody". Though I've probably lost the .log file, I've instead decided to provide a modified version of "MunSeeker_ZZZ_RadioTelescope_Contracts.cfg", which can be downloaded here.

Well, I finally took a look at the tech tree with Skyhawk Science System installed, along with multiple other mods, including the following: KSP Interstellar Extended Blueshift ESLD Jump Beacons Stockalike Station Parts Expansion Redux Far Future Technologies Flying Saucers Cryogenic Engines Cryo Tanks CryoEngines Extensions HabTech2 TAC Life Support Rusty Star Rockets Sandcastle Near Future Solar, Propulsion, and Electrical Nehemiah Engineering Orbital Science AtomicTech Inc. Junkyards Kerbal Atomics Pathfinder Kerbal Planetary Base Systems USI Kolonization Systems Airships Photon Sailor Silly Photon Drives Firespitter Keridian Dynamics SCANsat Procedural Parts Procedural Fairings Modular Rocket Systems Tweakscale Unlimited And many more... Most notably, Bluedog Design Bureau, the mod that was claimed to be a dependency of Skyhawk Science System, was not among any of the mods that were installed. Guess what happened? Although a handful of early tech tree nodes were empty (which could be automatically removed if using the Hide Empty Tech Tree Nodes mod), the Skyhawk tech tree seemed perfectly fine without Bluedog Design Bureau installed, as I had expected. Thanks to StockScienceSupport.cfg, Skyhawk Science System was already doing a good job at reassigning the stock KSP's parts' tech requirements, along with numerous other parts that likewise depended upon the stock tech tree, including the procedural parts mods, plus the Cryogenic Engines and Cryo Tanks mods, which Skyhawk Science System included specific mod support for. Nonetheless, there were some issues encountered regarding the tech tree, particularly when it comes to dealing with mods that are either dependent on the Community Tech Tree mod (such as KSP Interstellar Expanded) and/or make their own changes to the stock tech tree (such as Flying Saucers). For starters, I'm disappointed that Skyhawk Science System never bothered to include support for the Community Tech Tree mod, not even something basic like it had for the stock tech tree. That kind of basic support would've likely saved the developers a bunch of work needing to add support to certain mods, like KSP Interstellar Expanded (not to mention that it would've likely made a bunch of specific mod patches that Skyhawk Science System redundant). I'm currently working on a few fixes regarding compatability with the Community Tech Tree mod, and by extension, any mods that would require it as a dependency (especially KSP Interstellar Extended). Hopefully, they'll be ready for upload.

@Aelfhe1m Oh? So there's no need to keep that variable around after KSP has been successfully loaded? Alrighty then. I'll also add in the cleanup code.

Small update: I've been taking a bit of a break in-between KSP playtesting sessions installing a bunch of mods, getting crashes to desktop, uninstalling said mods until the game could load again, and watching YouTube videos in the meantime, but I think I've figured out what was causing these kinds of errors to keep popping up within my .log files: [WRN 04:37:28.696] PartLoader Warning: Variable SSS_Tier not found in Part As it turns out, it stems from the Skyhawk Science System mod, and I suspect that it's due to a lack of a failsafe within ScienceTiers.cfg. To remedy this, I've opted to add such a failsafe of my own: @PART[*]:FIRST[zzzSkyhawkScienceSystem] { %SSS_Tier = 0 } Afterwards, I've opted to replace any instances of this below the failsafe: %SSS_Tier with this: @SSS_Tier so that SSS_Tier values could be overridden as needed. I hope to do more testing later on to see if these changes would work as intended.

Besides myself, I'm sure plenty of others would've been eager to see something like that. Oh, and speaking of system replacers, I've been thinking about how one might successfully develop a mod that would've restored the Kerbolar System to its vanilla glory, even with other system replacement mods like Galileo's Planet Pack present. For now, here's what I believe one would've needed to consider: This mod would've likely needed to have been loaded after all of the other system replacement mods had been loaded, yet ideally, would've also been loaded before such mods that would've made various changes or additions to the stock Kerbolar System as, say, E.V.E., Scatterer, various mods that require Kerbal Konstructs (such as Launch Sites Appended or Kerbin Side Remastered), any universe-wide rescale mods designed to resize the stock Kerbolar System, plus other modded celestial bodies (such as any of these old configs for the old Sigma Dimensions mod), or such planet packs as OPM, MPE, QuackPack, Sentar Expansion, or Revamped Eeloo to name a few. The option to make Kerbin the home world once more instead of whichever planet is supposed to replace the home world. Perhaps the Kerbolar System would've been made to revolve around either whichever star system would've replaced it, or around a supermassive black hole, which other community-developed star systems, including the ones from the system replacer mods, would've also been made to revolve around, in order to serve as the center of a galaxy or star cluster? (Then again, perhaps both options could've been made possible, with, say, the former option being the default option due to how simpler it would've been to design, whereas the latter option would've been better suited towards a more ambitious project, that would've used patching to build upon former option?) Although I believe the first three design considerations should've likely been enough for many (if not the majority) of the system replacer mods out there, it might not necessarily work as smoothly when dealing with system replacers that change the whole Kerbolar System whilst keeping all of the original names, such as JNSQ for example. Under such circumstances would mod-specific patches be needed to be able to keep those modded stock-planet-alternatives along with the stock planets themselves, such as renaming these modded planets to, say, their original names backwards (such as, say, "Nibrek" in place of "Kerbin" for example), or adding a tag next to their name (such as, say, "JNSQ's Kerbin" for example). That's all that I can think of at the moment for designing such a mod that would've addressed this bothersome common trend of modders designing their own planet packs to replace the stock Kerbolar System, making all of these system replacer mods mutually-exclusive as a result of such sloppy quick-and-dirty and/or self-centered mod design practices. (Personally, I'm surprised to find that such a mod hadn't been made as of yet.)

@rrty44 Could you specify what kind of radiation needs to be researched exactly? Otherwise, you'll just have to make do with some mod suggestions based on certain assumptions that I'll be making. For example, I'm aware that both Bluedog Design Bureau and FASA add Geiger Counters that can be used to gather science, much like thermometers, barometers, or crew reports. However, if you want to broaden your radiation scans to include not only harmful ionizing radiation (like alpha, beta, and gamma radiation), but also spectral radiation, like infrared, ultraviolet, x-ray, and radio waves for example, then in addition to BDB having you covered once again, I'd also suggest taking a look at Tantares. Oh, but if you're just looking for science experiment data files for other mods to use, then I'd recommend checking out Skyhawk Science System. (Oh, but CKAN lists BDB as a dependency for Skyhawk Science System, perhaps even an unwarranted, unnecessary dependency that, IMO, should've been listed as a recommendation instead.) Oh, and if you find BDB, FASA, Tantares, or any other parts mods to be too big for your liking (especially BDB, which is over 2 GB in size), then ask yourself this: Who's there to stop you from surgically pruning your downloaded mods of unwanted parts? (BDB was apparently designed to have folders full of parts pruned if the mod is too big for your needs. Personally, I'd only want to keep the science experiments, probes (which come with science experiments on them), and engines, and discard the rest.)

@Jcklemme After some further digging on CKAN, I've spotted a few extra mods that you might also want to take a look at: Birth of Time Planet Pack (Non-Homeworld-Switching Config) Ethereal Frigus: A Planet Between Duna and Dres ExtraKerbin Moons FOMALHAUT Gene's Star Remaster (Possibly Outdated?) Heracleitus Jeb Far Away Kerbal Galaxy Revamped (Quite Possibly Outdated!) Kerbol's Humble Neighbouring Stars Kronkus Magica and Hornet Planet Pack Mirrotist System Muniant Neidon Plus Oberon: Moon of Jool Revamped Eeloo: New Moons and Atmosphere Sentar Expansion (Very Old, but Not Necessarily Outdated) Starlight Systems Pack Strange New Worlds The Third Mun The Vulture System Titania: A New Moon for Kerbin Trent: Moon of Eeloo Valor Planet Pack Revived Veen: Moon of Eve Xamion: A Planet Far Beyond Eeloo Xen's Planet Collection Revived Hopefully, none of these would conflict (too much) with anything else within your long list of mods that add to the stock Kerbolar System (or the stock system itself). I'll also throw in an extra mod, though I have my doubts about its compatability: Linbol System Rebirth Oh, and I've just lodged a stern complaint against the development team behind GEP to finally add support for the latest version of Scatterer (or at least delist it as a conflicting mod on CKAN). It's been long overdue that that antiquated planet pack do some work to remain relevant alongside later-developed, yet more finely-designed, mods like Kcalbeloh. Oh, and besides, when manually installed outside of CKAN, it looks like GEP would've worked alright with the latest updated versions of Scatterer anyways, as hinted at within this post.

I'm getting awfully tired of having to choose between this old classic of a mod or a bunch of other mods that work with the latest versions of Scatterer. Therefore, I humbly sternly, with great concern for this mod's future, request demand insist that this mod finally update its planets to be able to work with the latest versions of Scatterer (even if it might involve porting over older Scatterer functionality to the mod itself for use on its own planets only), including on CKAN (which still lists modern versions of Scatterer as a conflicting mod), or else I fear that this mod would have to be passed up (that, or I'd have to request a patch that would make it compatable with the latest versions of Scatterer).

@Jcklemme Quite the impressive selection! I'm hard-pressed to recommend any additional planet packs to complement all of the others here. Perhaps Corelian, Dreskiller Base, and Grannus Expansion Pack could all be considered?

Correction: Not necessarily all interstellar system mods are fully compatable with mods like OPM, MPE, or QuackPack, especially when they force the Kerbol system to orbit another celestial body, which takes the star of Kerbol's place as the "Sun" in the data files. @MYKori_Rosales Like I've stated before, be on the lookout for any mods that would also force the Kerbolar System to orbit any other celestial body (such as a supermassive black hole, like the one featured within the Kcalbeloh mod), ESPECIALLY when they do so by making another celestial body (usually within the mod, such as the titular black hole named Kcalbeloh) take the Kerbolar System's sun's place in the data file, and may or may not bother adding a custom star named Kerbol in order to move the vanilla KSP planets (plus some other supported mods' planets, such as from the Outer Planets Mod in Kcalbeloh's case) in orbit around this new star. If you notice that some celestial bodies that were supposed to be orbiting within the Kerbolar System (whether it's vanilla planets like Kerbin, Eve, Duna, or Jool, OPM planets like Sarnus, Urlum, or Neidon, QuackPack planets like Blas, Jot, or Cind, or MPE planetoids like Crokslev, Edas, Ervo, Geito, Havous, LintMikey, Mracksis, Soden, Vant, or Zore) are not orbiting within the Kerbolar system, and you notice that the star of Kerbol is orbiting something else, then chances are that at least one of your interstellar planet packs (such as Kcalbeloh, the Event Horizon Planet Pack, or some other mod(s) that add(s) 1 or more new star systems (especially supermassive black holes) to explore alongside the Kerbolar System) might be at fault for unwarranted messing with the structure of the Kerbolar system.

I don't know how to upload to GitHub, so I hope that uploading the mod here instead would be acceptable.

A bit of a forewarning: As of now, the mod doesn't seem to be compatable with any mods that replace the stock Kerbolar system, such as Galileo Planets Pack or Real Solar System. To remedy this, for starters, I'd recommend replacing any instances of "Kerbin" with "HomeWorld()" (and also find ways to replace the other planetary bodies, such as the Mun and Duna, in an adaptable way), so that the contract configurator mod can auto-detect where the homeworld is located (along with other nearby challenge-appropriate worlds). If you'd like, I could try uploading my mod changes onto the cloud for others to download and see for themselves (especially if they have Real Solar System installed).

A bit of a forewarning: As of now, the mod doesn't seem to be compatable with any mods that replace the stock Kerbolar system, such as Galileo Planets Pack or Real Solar System. To remedy this, for starters, I'd recommend replacing any instances of "Kerbin" with "HomeWorld()" (and also find ways to replace the other planetary bodies, such as the Mun and Duna, in an adaptable way), so that the contract configurator mod can auto-detect where the homeworld is located (along with other nearby challenge-appropriate worlds). If you'd like, I could try uploading my mod changes onto the cloud for others to download and see for themselves (especially if they have Real Solar System installed).

I do know of at least one mod that adds parts that allow for remote power transmission via microwaves, and that'd be KSP Interstellar Expanded, which adds power-beaming and power-receiving parts.

Seems like this mod isn't compatable with system replacement mods like Galileo's Planet Pack or Real Solar System. I've opted to fix the issue for myself (at least with Real Solar System installed), but perhaps a bit of redevelopment is in order to be able to better work with system-replacement mods in general? Oh, and here's a small snippet that I found within my .log file, which was how I had found this issue in the 1st place: [LOG 19:00:59.976] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'KerbinOrbitalTelescopeDeployment' [ERR 19:00:59.982] ContractConfigurator.ExpressionParser.DataNode: CONTRACT_TYPE 'KerbinOrbitalTelescopeDeployment': targetBody: The field 'title' is required in for data node values where 'requiredValue' is true. Alternatively, the attribute 'hidden' can be set to true (but be careful - this can cause player confusion if all lines for the contract type show as 'Met' and the contract isn't generating). [ERR 19:00:59.984] ContractConfigurator.OrbitFactory: CONTRACT_TYPE 'KerbinOrbitalTelescopeDeployment', PARAMETER 'LKO' of type 'Orbit': targetBody for ContractConfigurator.OrbitFactory must be specified. [ERR 19:01:00.002] ContractConfigurator.OrbitRequirement: CONTRACT_TYPE 'KerbinOrbitalTelescopeDeployment', REQUIREMENT 'Orbit' of type 'Orbit': targetBody for ContractConfigurator.OrbitRequirement must be specified. [WRN 19:01:00.002] ContractConfigurator.ContractType: CONTRACT_TYPE 'KerbinOrbitalTelescopeDeployment': unexpected attribute 'displayName' found, ignored. [WRN 19:01:00.002] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'KerbinOrbitalTelescopeDeployment' [LOG 19:01:00.009] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'MunOrbitalTelescopeDeployment' [ERR 19:01:00.015] ContractConfigurator.OrbitFactory: CONTRACT_TYPE 'MunOrbitalTelescopeDeployment', PARAMETER 'Mun' of type 'Orbit': targetBody for ContractConfigurator.OrbitFactory must be specified. [ERR 19:01:00.057] ContractConfigurator.OrbitRequirement: CONTRACT_TYPE 'MunOrbitalTelescopeDeployment', REQUIREMENT 'Orbit' of type 'Orbit': targetBody for ContractConfigurator.OrbitRequirement must be specified. [WRN 19:01:00.059] ContractConfigurator.ContractType: CONTRACT_TYPE 'MunOrbitalTelescopeDeployment': unexpected attribute 'displayName' found, ignored. [WRN 19:01:00.059] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'MunOrbitalTelescopeDeployment'

I've lately been trying this mod out with the Real Solar System mod, though it doesn't look like it was made for system replacement mods in general. To fix this, I'd recommend replacing any instances with Kerbin with HomeWorld(), so that the mod would be able to better adapt towards any other mods that replace the Kerbals' homeworld of Kerbin with another world. Alternatively, other modders could opt to replace any instances of Kerbin (or other celestial bodies) with other planet packs' homeworld via patching, but that's not as ideal as making the mod more flexible and adaptable. Edit: After further digging, I've discovered a little file called database.cfg, which seems to possess the names of numerous bodies within the Kerbolar system. I reckon that the file was designed with patchability in mind, where modders could develop patches that add the names of various celestial bodies from other mods to be discovered at game start on various difficulties (such as Sarnus, Urlum, and Neidon from the Outer Planets Mod), and in the case of system replacement mods, possibly remove Kerbin and the other planets and moons from the list in order to be replaced with the names of their mod's homeworld plus neighboring celestial bodies (such as Earth, the Moon, and their neighboring planets and moons from the Real Solar System mod). Edit #2: Oh, if anyone was curious as to how I managed to spot this issue, here's a small snippet of my .log file (while I had Real Solar System installed): [LOG 19:01:00.092] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'RB_ResearchBody' [LOG 19:01:00.119] [INFO] ContractConfigurator.ContractType: Successfully loaded CONTRACT_TYPE 'RB_ResearchBody' [LOG 19:01:00.150] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'RB_SearchSkies' [LOG 19:01:00.157] [INFO] ContractConfigurator.ContractType: Successfully loaded CONTRACT_TYPE 'RB_SearchSkies' [LOG 19:01:00.161] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'RB_TelescopeResearchBody' [ERR 19:01:00.166] ContractConfigurator.OrbitFactory: CONTRACT_TYPE 'RB_TelescopeResearchBody', PARAMETER 'Orbit' of type 'Orbit': targetBody for ContractConfigurator.OrbitFactory must be specified. [WRN 19:01:00.170] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'RB_TelescopeResearchBody' [LOG 19:01:00.175] [INFO] ContractConfigurator.ContractType: Loading CONTRACT_TYPE: 'RB_TeleScopeSearchSkies' [ERR 19:01:00.179] ContractConfigurator.OrbitFactory: CONTRACT_TYPE 'RB_TeleScopeSearchSkies', PARAMETER 'Orbit' of type 'Orbit': targetBody for ContractConfigurator.OrbitFactory must be specified. [WRN 19:01:00.183] ContractConfigurator.ContractType: Errors encountered while trying to load CONTRACT_TYPE 'RB_TeleScopeSearchSkies' It seems these bugged-out contracts were set to use Kerbin as a reference, which was why they bug out whenever Kerbin is removed and replaced with a different homeworld. I recommend replacing any instances of "Kerbin" with "HomeWorld()" to fix this issue, so that it wouldn't happen whenever Kerbin is replaced with a different homeworld through mods like Galileo Planets Pack or Real Solar System. Edit: Replaced all instances of "Homeworld()" with "HomeWorld()", since in scripting, case matters. (Note the capitalization of the letter "W".) My mistake.

Looks interesting. That also reminds me of a project that I've worked on starting a month or two ago, and while it looks to be in a workable build, I haven't yet bothered to publish it on CKAN (partly due to inexperience with uploading mods, but also partly due to concerns about violating some kind of licensing agreements). The project in question? Trying to adapt the old Planes with Purposes mod for Real Solar System (and potentially other planet packs that replace the stock Kerbol system, and move the Kerbals' homeworld to another planet, such as the Galileo Planets Pack), though due to dissatisfaction with how the mod was structured, I ended up adding a bunch of text meant to help players in designing their aircraft/spacecraft to be, say, more controllable in flight under various conditions (such as at high altitude, or when travelling at high supersonic speeds), and making the contracts easier in some cases (such as allowing for more non-air-breathing engines for spaceplane design) and harder in others (such as requiring players to land back at KSC safely instead of anywhere on the homeworld).

After taking a brief look, it seems like the tech tree doesn't have any new nodes, which is a bit disappointing, at least for me personally. Nonetheless, I have no real complaints (especially since I have yet to try out Kerbalism myself, since I'm still new to modding for KSP in general). I am curious as to if you have plans to publish your mod on CKAN.

I WAS already planning on rolling back my modlist back to when it was last playable as a last resort, and then reinstalling mods until problems would pop up again. Unfortunately, it has pretty much come to this. What little I was able to find out was that something within my mod list was not playing nicely with the modded nuclear reactor parts, since the game didn't crash when I uninstalled all of the mods that added nuclear reactors (including Near Future Electrical, Kerbal Atomics, and AtomicTech). However, I managed to find a different crash-inducing bug, and this one seems to affect a broader amount of parts. Well, back to the long and laborious task of isolating those problematic crash-inducing mods... Edit: And here's the new log that I uploaded, compressed down to a 3.8MB .rar file from a 136.7MB .txt file. Note the fatal error that I've highlighted below: Now I don't know which mod is trying to look for a so-called 'LH2' tank, but I intend to find it, and if possible, fix it, and if not, leave it out. Edit #2: Mod rollback successful. My mod list has been shrunken down from approximately 700+ mods to more like approximately 300 mods, my GameData folder may have shrunk down from at least 15GB to around 9GB, and my latest .log file (which can be downloaded here) is smaller, though still pretty large at 67MB, but the game now loads to the title screen successfully without any game-crashing bugs occurring. Further testing is being done now. I'll update once I've found something new.

Sounds interesting. I'd be interested in taking a look at it if at all possible.

I'm still at a loss as to which of my mods are causing the game to crash from errors like these. In particular, whereas I'm certain that rationalBuoyancy and rationalPressure could be traced to the Rational Hydrodynamics mod, I'm at a loss as to which mods would be responsible for trying to read the following variables that are missing from various parts: lpgLF lpg SSS_Tier I've become so lost that I've started resorting towards blindly uninstalling batches of mods in the hopes that at least one of those mods would've been responsible for causing these game crashes when loading, and reinstalling mods when they weren't showing signs of improving the situation. Edit: Also, I've ruled out Near Future Electrical as being responsible, since I've found that various other mods' parts, such as Ablative Airbrake and Kerbal Atomics, are being affected.

Alas, CTT also shares the same flaw with Skyhawk in that FTL technologies aren't adequately represented based on how balanced vs how game-breaking they are, though in CTT's case, there's no representation towards FTL technologies at all. Just the vague and generic Unified Field Theory and Ultra High Energy Physics nodes are likely used for such sci-fi FTL technologies as those represented in BlueShift. Not to my very limited knowledge, though I'd imagine that these sci-fi experiments would've yielded far more science than what's normally given in stock KSP, and yet, would've only been enough science points to help unlock the next tier of FTL technologies (provided that enough biomes at enough planets were visited), though not necessarily the tier afterwards. Take a look at the base science values found in the base KSP game (science caps are in parentheses): Crew Report: 5 EVA Report: 8 Mystery Goo: 10 (13) Surface Sample: 30 (40) Materials Study: 25 (32) Temperature Scan: 8 Pressure Scan: 12 Seismic Scan: 20 (22) Gravity Scan: 20 (22) Atmospheric Analysis: 20 (24) Infrared Telescope: 15 (22) Magnetometer Report: 45 EVA Science Experiment: 25 Asteroid Sample: 60 (70) Short-Period Comet Sample: 90 (100) Intermediate-Period Comet Sample: 135 (150) Long-Period Comet Sample: 270 (300) Interstellar Comet Sample: 900 (1000) Of course, countless other factors would need to be considered, including the data scales provided by being on different planets (with harder-to-reach planets typically yielding greater science rewards), or on different biomes on planets, or while on the surface, splashed down in liquid, flying through an atmosphere, or in high or low orbit above the planet, how much mass each science experiment possesses, how expensive each science experiment part is, which situations the experiment can be used on (such as seismometers only being useful while landed, while atmospheric analyzers only being useful within an atmosphere), whether the science experiments would need a Scientist to reset the experiment, and so on and so forth. However, there does seem to be a trend for science experiments that can only be carried out by more expensive, more high-tech, and more massive parts, such as Magnetometers, Gravioli Scanners, Surface Samples, and Materials Studies, all yielding more science gains than such cheap science experiments as mere Crew Reports, EVA Reports, Temperature Scans, Pressure Scans, and Mystery Goo Observations. Of course, Comet Samples, especially the Interstellar ones, blow everything else out of the water due to how rare they are, how difficult they are to reach, and how massive they are, making them far, FAR more difficult to redirect for different science experiments around different planets than they are to reach. If we were to continue with this trend, plus also adding in ever-larger energy costs (such as requiring a whole miniature black hole's worth of power for, say, powering up an Alcubierre Warp Drive), whilst also keeping in mind the kinds of science scaling that these extrasolar celestial bodies would likely possess that would make even Moho, Eve, and Eeloo seem uninteresting in comparison, then perhaps the following values for these kinds of sci-fi experiments would be adequate (assuming that each new FTL tech tier would double the amount of celestial bodies that could be reached in a reasonably-short period of time, and could also be within communication range, and that each new tier of FTL tech would require roughly 5-10x the amount of science as the previous tier)? Tachyon Scan: 100 Gravimetric Scan: 500 Wormhole Experiment: 5,000 Hyperspace Experiment: 100,000 Quantum Field Experiment: 4,000,000 Warp Field Experiment: 320,000,000 That kind of exponential approach is what some other games with science systems might take to better push the player into settling for a larger base, empire, etc., and for getting used to everything within a tier of the technology tree before the game would consider the player ready to move on to the next tier. (Some games that I've played before that have done this include Autonauts, Factorio, Satisfactory, Dyson Sphere Program, and even a few old-school grand strategy games like Civilization, Master of Orion, and Galactic Civilizations.) Of course, these values could be toned down by ALOT, and/or at certain places, if you'd rather like to keep giving the player incentives towards continuing with all of the lower-tech science experiments.