Gotmachine

Well, if you keep having issues with KSP-Recall (which I assume you got only because of TweakScale), notice that there is a new fork of TweakScale dubbed "TweakScale Rescaled". It is basically a ground up rewrite of that mod that consequently doesn't need the KSP-Recall thing to work, is way less buggy, and has a few nice QoL addtions.

Hard to say what is going on. I see 3 potential issues : 1. There are a few plugins erroring out in minor ways, but for whatever reason DeepFreeze is having a really bad time. I don't see any obvious link between that and your issue, but I would still recommend removing it, as playing with unstable plugins isn't a good idea in general. 2. It seems you have updated some plugins between the last time you used that save. There are tons of module index reordering happening when you're loading your vessels, caused by the "Refunding" module from the KSP-Recall plugin to have been removed, I guess following some update. This can potentially cause some data loss that could in theory cause weird issues like you're having, but it's difficult to establish a relation with your specific issue. (On a side note, for whatever reason, you have some MM patch trying to put a non-existent "TestPersistentId" from KSP-Recall module on every part, not much of an issue, but there is something weird happening with that plugin in your install) 3. What seems to happen is something applying unrealistic temperatures before the vessel is even fully loaded, as things are starting to explode before the flight integrator has a chance to apply the initial analytic temperature to your vessel. This could be due to some game loop interleaving problem caused by heavy CPU load on scene switches that didn't happen previously. If I understood your previous posts correctly, the issue doesn't always happen, which is a hallmark of such problems. If that isn't already the case, I would suggest reducing the "max physics delta-time per frame" main menu setting to its minimum value of 0.03, which can help with such issues. Assuming you still have a backup of your save from before the problem started to appear, I would suggest installing KSPCommunityFixes, which has some mitigation fixes for issues 2 and 3, as well as allowing a lower 0.02 "max physics delta-time per frame" value, which is guaranteed to eliminate every problem linked to game loop interleaving. It might not help at all, but it's worth a try. Note that in general, similar issues as yours (vessel overheating on load) aren't unheard of in unmodded KSP, especially when converters, drills and radiators are involved, so you might "just" be hitting that stock bug for whatever reason. It would be nice to be able to reproduce it with a minimal setup in terms of installed mods, as TBH, externally diagnosing such issues in heavily modded installs is near impossible, even more when mods were installed manually and not through CKAN.

A 1.4 GB ksp.log is a sure sign that there is something very wrong and that can at least help identify which one of your billions of mods you should remove. Just zip the file before uploading it.

To answers a few of the last posts, Kerbalism hasn't been in active development since many years now, there are only minor contributions from passing people being released once or twice a year, many of them being specific to the RO/RP1 fork. Kerbalism is a special mod in the sense that it has its own ecosystem that by default isn't compatible with the way some things are done in stock, especially in regard to everything science related, and everything producing and consuming resources. For that last aspect in particular, Kerbalism require explicit support for other mods, and due to the lack of maintenance, this support is now often partially or totally out of date, leading to various issues with resource usage in timewarp or in the background. Regardless of those maintenance related issues, there are some mods that never were really supported and likely never won't, especially large mods that also implement their own ecosystem significantly extending or deviating from the stock paradigms and scope. This notably include the MKS/USI ecosystem, KSPIE, some WBI mods, and some of the Nertea mods like NFE, NFP and FFT. Even when there are some support patches for those mods, that support is partial and often comes with large caveats. The scope of Kerbalism never really extended to goals, constraints and hardware beyond what spaceflight is currently at in the real world. Outside of technical issues, there are more fundamental ones in that Kerbalism tries to implement some aspects of spaceflight that are mostly ignored in stock and that represent huge challenges in reality. Many of those challenges are largely unsolved problems in the real world and potential future solutions are not really represented (outside of a few silly hacks like the RDU and active shield, which were late additions done due to popular demand). Overall, Kerbalism simply isn't tuned for mission profiles involving long lasting outer space human presence, and neither for the technologies that would allow them. All this to say that in the current state of things, Kerbalism is best played in a lightly modded environment, and for a game style close to the real world current technological level and potential mission profiles. It's definitely possible to play with whatever mods you want, but that will often result in a not very polished, buggy and in my opinion, frustrating experience.

AFAIK from my knowledge of the stock drag cube occlusion code, this isn't true. Inter-part drag occlusion is based on the config defined or runtime generated surface area of the connected parts drag cubes, node size / bulkhead profile doesn't matter at all.

In the end the cases where the performance overhead is lower are exceptions, you're gonna experience the lower FPS in the vast majority of situations. I'm not the best expert of the subject, but If I'm not mistaken, the reason this is needed is because the piece of code causing the performance overhead is required to prevent non-physical loss of velocity (which would notably cause orbital decay). You could argue that you don't care about such small physics inaccuracies when flying a plane, but in the end, that piece of code is required in most situations, and trying to do weird heuristics to prevent it from running in some corner cases is gonna cause more issues and frustration than anything. Also note that this performance overhead actually *does* happen anyway, as long as you're moving. The code just runs less often than every frame, so the tradeoff for a better average FPS figure is a more stuttery, unstable framerate, which isn't so great either.

Such performance variations are usually due to the floating origin / krakensbane changing engagement modes on various altitude / speed thresholds. Not much can be done about it, this is a structural consequence to how KSP handle floating point precision limits.

Thanks for reporting. This should be fixed in the just released KSPCF 1.32.1

From the mentioned tweakscale thread : It was loaded, and failed to load correctly, likely because it was a pre-1.8 plugin compiled against the v2.0 of the .NET Framework, there is nothing wrong with what KSPCF is reporting. Loading an assembly can fail for a variety of reasons, usually either a missing dependency or a dependency version mismatch. When this happen, the assembly will still be loaded in the AppDomain (and KSP will report it as such), but trying to access it (such as calling `GetTypes()` on it) or use its code will usually fail. Nope, it won't thanks to KSPCF. If you look at the log, there is no exception thrown, just a [WRN]. Due to above mentioned behavior (exception thrown on calling GetTypes() on an assembly that failed to load), and to prevent plugins that are calling that method (which a common thing to do when doing some type checking on loaded assemblies) from breaking as a side effect, KSPCF actually handle that exception correctly, inform the user on screen during loading, and in the logs : As for the other exceptions (in Kerbalism and KerbalEngineer), loading a plugin compiled against the wrong framework version will cause all sort of nonsensical issues, this isn't a situation that can be recovered from. We all remember way too well how the pre-1.8 MiniAVC bundled in tons of other mods broke the whole ecosystem when 1.8 dropped, this is the same issue here. It doesn't throw any exception, prints a nice message, and makes things easier to diagnose. @Comrad_501 fixed his install by doing what KSPCF was suggesting : remove the outdated SolarSailNavigator plugin. Edit : this being said, I agree the wording of the log entry, especially the "This is usually harmless" might not be the best choice (this only appear in the logs, the on screen message is more straightforward). The fact is that in most cases, a ReflectionTypeLoadException on GetType() is due to a missing dependency, and in that case is indeed harmless for the mod calling it, as long as the exception is try catched (which is why KSPCF automatically try catch it for everyone). However, in the case of a .Net framework version mismatch, this definitely has unpredictable, and generally game-breaking consequences. I will try to look into detecting that specific case and adapting the error messages in the logs and on screen. See https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/168

@Lathari This happens because you installed the StuckOnLoadingPartUpgradesFix mod, which is depreciated, useless in KSP 1.12.3+, and conflicts with mods using Harmony (such as KSPCF), I'm surprised you aren't getting more issues. This is somewhat my mistake, I forgot to mark that mod as depreciated. To uninstall it, in the KSP root folder, delete the "BepInEx" folder, the "doorstop_config.ini" file and the "winhttp.dll" file.

The issue is with Kopernicus Expansion. It uses a library (RunSharp) that is built against the .NET v2.0 runtime, and consequently can't be used on KSP 1.8 and newer (KSP switched to the v4.0 .NET runtime in KSP 1.8). I would suggest bringing that to the Kopernicus Expansion thread :

v1.31.1 bugfix release is out : DragCubeGeneration : Actually enable patch by default, I somehow failed to push that change in the last release (Thanks @dok_377 for reporting) ReflectionTypeLoadExceptionHandler : Fixed the exception handler itself throwing an exception in a corner case situation where a dynamic assembly is loaded, causing a call to Assembly.Location to throw (Thanks @Lisias for reporting). @matthias123@Comrad_501 If you grab that updated version, assuming the issue in your KSP install is actually an assembly that failed to load, KSPCF should tell you during loading what what plugin is the root cause of your issue , like in the above screenshot (you can also check your KSP.log for `ReflectionTypeLoadException` entries).

@Comrad_501 So, I have no idea from which mod your actual issue comes from, but the root cause of your problem is a plugin failing to load, either because it is missing some dependency, or because it is build against an older version of KSP. When such a plugin fails to load in such a way, it actually still is registered in the list of loaded assemblies, but most calls to it or about its metadata will fail in unpredictable ways. Notably, this can can issues when another plugin tries to get information about that assembly metadata. Specifically, a call to `Assembly.GetTypes()` on such an assembly will fail with a `ReflectionTypeLoadException`, see official API docs. This is a relatively well know failure mode in the modded KSP ecosystem, which is why plugins usually wrap such calls in a try/catch block to handle this gracefully. However, some plugins may be forgetting to do so, so as a part of its fixes, KSPCommunityFixes automatically intercept that exception, handle it gracefully (so only the problematic plugin are affected, not others), and present it to end users in a clear way during loading, so they are aware that some plugin is failing to load, for example like this : However, the reason you got directed here is because the KSPCF handler for that error actually has a bug where it will in turn throw an exception when it tries to handle that original exception, in a corner case scenario involving dynamic assemblies. From the end user point of view, this doesn't change much, as an unhandled exception would have occurred either way if KSPCF wasn't installed. This being said, KSPCF obviously fails at its purpose of providing extra correction for that error (that, again, would have happened anyway if KSPCF wasn't present), so I've pushed a fix, and will try to make a release with it soon.

Sounds like you are using an outdated mod packing MiniAVC, a version checking tool that is known to cause such issues in recent (1.8+) KSP versions. Try searching your GameData folder and subfolders for a file named "MiniAVC.dll" and delete it (won't do any harm in any case). But any mod packing that tool is likely vastly outdated and should probably not be used at all. Edit : For some weird reason, you have alternate versions of System.XML and System.Core in the KerbalKonstruct mod folder. That shouldn't be the case, and is definitely gonna cause a lot of issues. I do'nt know how you installed your mods, but I'd recommend starting over from a clean state.

Had some time to check your logs, and have done a bit of digging. Check out the github issue for details. The gist of the issue is your GPU driver crashing when instructed to load DXT5 DDS textures when those textures have a specific NPOT resolution. In your logs, it's crashing when loading : A 320 pixels height texture at level 1/4 mips, so 80 A 160 pixels height texture at level 1/2 mips, so 80 again I've found a bunch of reports from 2012-2015 era mac users having a similar issue in various games and applications, including KSP. To validate could you try, without KSPCF being installed, to just drop these 2 textures in your GameData folder, and try to launch the game at 1/2 and 1/4 texture resolution (TEXTURE_QUALITY = 1 and TEXTURE_QUALITY = 2) ? I suspect your game will crash as well, please send a log if it happens. The likely reason it happens when KSPCF is installed is because it tries to convert additional textures to the DDS format, and those textures have a tendency to use those problematic NPOT resolutions, but as far as I can tell this isn't directly caused by KSPCF. If I'm right, I don't think there is anything I can do to fix this, especially since it is happening on specific hardware, and likely a very specific hardware/software combination. I would suggest to check if the GPU drivers and OS are up-to-date. In other games/apps, people mention having this issue after updating OSX to a newer version.

I just tried with a replica of your setup, and everything seems to be working as expected : I'm not sure what could be happening, especially since KSPCF doesn't touch RCS stuff directly, and very little else that could somehow end up causing such an issue. There is nothing else I can do if I can't reproduce it, so I need more information. At the very least could you provide a download link to your KSP.log ? And if you're playing mostly stock, can you also provide your savegame where this issue can be reproduced (persistent.sfs file in the "saves\yourgamename\" folder) ? For easier/automated bug reporting, I'd suggest using : No, but at a few exceptions all patches can be individually disabled, as mentioned in the OP : Individual patches can be enabled or disabled by editing the Settings.cfg file. To make sure your changes persist when the mod is updated, it is recommended to make them in a ModuleManager patch. Open the Extras\KSPCF_UserSettings.cfg.extra file in a text editor for further instructions.

Interplanetary is possible, within reason. However, Kerbalism was indeed balanced around "past and current" technological levels and mission profiles, which is what I warned you against. We consider landing Kerbals on Duna and sending them back more or less the ultimate achievement, just like putting foots on Mars would be in the real world. Stuff like the RDU or active radiation shields are mostly placeholder for people wanting to mess around, and everything is balanced around limiting the maximal mission time, crewed or uncrewed, to a dozen years or so (actually more like 5-6 years for manned). Servicing stuff with EVA Kerbals was never meant as a gameplay loop, just a stopgap measure in case of an unfortunate event. Yes, the way radiation is modeled has a bunch of shortcomings, and it could use a balance pass, but it mostly works for the intended scope. Sure, you can throw nuclear reactors or various future tech mods, and tweak settings to try to get past what the mod intends to be and do things like a grand tour, but as you noted, it's mostly an exercise in frustration, which is exactly why I warned you in the first place.

Aside from the fact that switching from Unity to Unreal would basically mean restarting from scratch and require several years to just come back to where they are now, the whole idea that the game would be better by doing so is questionable at best. The various cutting edge stuff from Unreal (you mentionned nanite) is more or less useless for a game like KSP. The only significant dependency KSP has on the engine is rigidbody physics, and while it can be argued that the Chaos engine from Unreal might be a slightly better fit that PhysX in Unity, the best fit would actually be either a custom implementation, or at the very least a forked version of an off-the-shelf physics engine. Most technical (and performance) issues in KSP 1 or 2 comes from subpar technical solutions due to a lack of an adequate software engineering capacity given the scope and design requirements. The engine they are using is a minor factor. If they end up miraculously getting greenlighted for a large refactoring project, it's more likely to be a project revamping their core architecture issues in the light of the experience and feedback they acquired in the last years than a base engine switch.

Terrain is just as empty anyway, this has nothing to do with scale, but everything to do with the lack of a proper high detail procedural terrain solution. Edit : there are many ways a larger scale improves immersion. In the end, it comes down to adequately scaling a given technology with what is supposed to achieve in the real world. It means larger rockets and contraptions in general, more incentive to do complex missions with stuff like orbital assembly and resupplying, more incentive to actually have off-world bases and stations. Once you have understood the basics of rocket building and orbital/interplanetary navigation, it's way too easy to go anywhere and do everything in KSP. To me, expanding the scale of the Kerbal system to something like 1/4 and revamping it with new places would have been much more in the spirit of KSP than expanding the scope to science fiction interstellar technologies. There are 80 planets, moons and other bodies with larger than the KSP Mun radius in the solar system, countless asteroids and comets, with tons of unique features, including ones that could have actually meant something in terms of gameplay. I know it isn't a popular opinion, but while KSP 1 was briliant at defining a new sub-genre, a lot of the justifications for many of its technical and design decisions didn't have much validity anymore 10 years latter and should have been questioned when making a sequel, instead of taking everything KSP 1 did and just envisioning that sequel as a big DLC.

I agree real scale has some disadvantages. But 1/10th scale is really tiny, as highlighted by OP, and you can actually feel that in many ways. A lot of people have a very positive feedback with the 1/4 or 1/3 scales. I can't help to think that "we want to make you feel that space is big" decision that led to the interstellar scope in KSP 2 could (and maybe should) have been avoided by revisiting the stock scale (and system) instead.

People can't land on the Mun because they fail to either understand or put into practice concepts like staging, deltav, twr, gravity losses, orbital flight planning, node execution, suicide burns, attitude control... In many cases, the game is failing at teaching those concepts, or could have better tools to interact with them. But the scale of the bodies is a very minor factor, as long as the parts isp and density is decently balanced. Like many veteran KSP players having played with various non stock scales, I agree that the stock system scale gives a toy system feeling, which imo is detrimental as it destroy the sense of achievement. Space doesn't feel big, the rockets don't feel big.

The difference is very subtle and are likely related to minor difference in texture sampling settings/hardware from one card/driver to another. Aside from navball itself, look at how the UI dithering patterns and the ground in the background also have higher contrast on the radeon. It's more a design issue than a technical one, the interface in general has very low readability, making any such minor rendering differences much more visible. Such issues is what you get when trying to combine a pixelated style with small size, high density UI elements, and even worse when those UI elements are neither horizontally or vertically aligned.

There is a difference between "a bit" and interstellar travel, nuclear fusion, and metallic hydrogen.

Not really. Those are just that specific patch release notes. There are thousands of such changes between 2020.3.33 and 2022.3.5. From a modding perspective, the most relevant change is support for .NET Standard 2.1 and (almost) full support for C# 9.0, and support for stable/recent versions of UIToolkit. From the game perspective, likely related to their switch to the HDRP rendering backend, but also simply because updating the engine will be beneficial in the long run, and whatever this might break isn't a big deal while they still are in an unstable EA/beta stage. Plus 2020.3 isn't exactly renowned for its stability/polish anyway.

Logs are indeed needed, please upload them somewhere (dropbox, google drive...) and provide a download link. Mac OS X: Open Console, on the left side of the window there is a menu that says 'Reports'. Scroll down the list and find the one which says "Log Reports", click that. A list of files will be displayed in the top part of the window, in there will be Player.Log ( Files>~/Library/Logs>Unity>Player.log ). Right-click on it and select "Reveal in Finder".