Gotmachine

Well, since we have decided to completely derail this thread... It's true that patching a method cause it to go trough a dynamic stub, which does induce an additional overhead. Not so much because of cache locality (that just isn't a relevant factor here), but simply because the dispatching is a bit less efficient. Somewhat fortunately depending on how you look at it, the Mono JIT used in Unity is quite outdated and isn't very smart and nor efficient to begin with, so that overhead isn't actually as significant as it would be in modern CoreCLR. Also, as you noted, in the case of prefixes/postfixes, an additional method call is inserted, but this isn't the case with a transpiler. We are well aware of those caveats, which is why we are careful not to patch hot path methods unless our replacements are optimizations that would in any case dwarf that overhead (a good example is the IMGUIOptimization fix). There are some cases where we decide that fixing a bug is worth a bit of extra overhead, but overall, we are patching very few methods that are called every frame. I have a hard time believing that could be measurable at the framerate level, but I could have missed something, and indeed, maybe there are platform specific shenanigans involved, as MacOS is notoriously badly supported by... well... everything that doesn't come from Apple.

Well, I wouldn't recommend using the Unity profiler for general performance profiling. The Unity profiler is mainly useful for doing targeted profiling and optimization, identifying specific issues (its deep profiling capabilities is quite useful for that), identifying sources of GC allocation pressure. It's a great tool for plugin developers, but not so much for end users. And a major issue with it is that using it require to turn your install into a development build, which has the side effect of disabling a lot of Mono and Unity optimizations. This not only has a significant impact on overall performance, but that impact is also very uneven depending on how much those disabled optimizations are applying to a specific code path. I've seen some cases of code running over three times slower in a development build, typically in tight managed loops or when doing a lot of specific unity API calls. That's the whole point of the "KSP Profiler" mod mentioned above : it can run in a normal unmodified install, is pretty straightforward to use and is inducing very minimal overhead.

I won't enter a whole debate about your claims, they are made from measurements done in vague and unreliable ways, especially the part about comparing the FPS curves while manually doing a scene switch and moving the camera. What you're doing is very far from a "controlled Test Bed with a deterministic Test Session". There are a million things that could affect the shape of those curves, and I very much doubt you're able to reproduce any of it consistently. The simple fact that your FPS is changing when you're moving the camera (ie, it is dropping when the KSC buildings enter into the viewport) means that you're GPU-bound, which is something the KSPCF has zero influence on. And a 1 FPS moving average difference is just noise, especially in a GPU bound scenario. That's why more advanced tools than a FPS counter are needed, because right now you have no idea what you're measuring. Concerning KSPCF, a few remarks : - In the specific test case you're using, there is nothing in KSPCF that can improve or degrade performance. - Most performance related tweaks in KSPCF are a targeted fix for a specific stock inefficiency. They can make a significant difference for the specific cases they apply to, but there is no silver bullet "game changer" performance tweak. - An important fix is getting ride of the stock (and mods) memory leaks, which is a very problematic cause of performance degradation (not to say outright crashes) over long play sessions. If you want to measure the difference KSPCF makes here, an easy way is to just repeatedly quickload the same (preferably large, 100+ parts) vessel a good 30-40 times and to check memory usage. Anyway, having some time to loose this morning, I grabbed the show FPS mod and did a few tests on my desktop (5800X3D / 6800XT). On a side note, that mod is crap, because in itself it adds a lot of overhead (3% to 5% frame time overhead), and that overhead grow significantly with how many points are shown on its graph, heavily skewing the results. Example of a case where the KSPCF optimizations are significant. The main optimization here are the PQS related ones. Not much difference however with the same vessel on the launchpad (a few KSPCF optimizations still kick in there, and they would be more visible on a lower spec machine, but in my case that doesn't change much) : And another more dynamic but not very scientific nor deterministic test just for fun. I rescaled and aligned the graphs to be able to compare the points. Not very conclusive, but KSPCF is consistently 5-10 FPS above stock, and there are fewer outliers. Likely a combination of the PQS and buoyancy optimizations. Also took the time to repeat your stratolauncher test on my pretty crappy laptop (that test is pointless on my desktop as it runs at 300+ FPS). The laptop has 8GB of low speed single channel DDR4, and a Pentium silver N5030, vastly slower than the I7-3720GM in your Mac, but with a better iGPU. Overall, I'd say this is a somewhat equivalent config. I did the tests with every graphic settings set to the minimum, and at a 720p resolution to avoid being GPU bound as much as possible, but that didn't help much, I'm still GPU bound in almost every situation. Anyway, here are the results, I'd say this is pretty much just as inconclusive as yours (you can ignore the instant / moving average FPS values in both screenshots, that was dipping because of the screenshot tool). The dip after the camera movement is simply the iGPU struggling with having the KSC buildings to render. I'm not sure why stock is below KSPCF before the camera movement, seems to be a GPU related limit too, but maybe there is some memory usage at play here as KSPCF is slightly reducing memory pressure. I'm not even sure this would reproduce consistently, there are just way too many factors at play here. I'd say that in general, without 100% automated and deterministic testing, and without specialized CPU, GPU and memory profiling tools, trying to identify the constraints on such low end machines is an exercise in futility. Especially on such laptop-style machines (the mac mini is in the same boat here) where control over frequencies is extremely limited, where the iGPU and CPU are sharing the same memory and thermal envelope and where background processes are fighting with the game over limited resources.

This plugin just instruct the stock SAS to follow a custom direction, so indeed all the usual caveats applies, the stock SAS just isn't well tuned for atmospheric flight and control surfaces. I made this plugin with mainly rocket launches and landings in mind, and while it can be used for controlling planes, this isn't a replacement for the more advanced autopilot mods. No, but I will try to remember to add the option.

New release : FastLoader : fixed the PNG loader behavior not being similar as in stock. It was wrongly generating mipmaps, notably resulting in NPOT textures not showing when texture quality wasn't set to full resolution (see issue #224). FastLoader : fixed cached PNG textures loading not using the data loaded by the threaded reader, but instead reading the file again synchronously (!). Unsurprisingly, fixing that is massively improving texture loading time. Thanks to @Scottmm78 for reporting the first issue. I will open an issue so I remember to take a look. It might be possible to bump a bit the "vessel moving" threshold.

The file is correctly found, that's not the issue. Okay, this has nothing to do with the path of the install, sorry for that. This is caused by having a lower than max global mipmap level active during loading. The workaround is to set "texture quality" to "full res" in the KSP main menu video settings (and given that you have quite decent hardware, you probably should anyway), then to restart the game. But I will investigate how to avoid that issue anyway.

Okay, thanks for checking. Turns out that I managed to reproduce it by running the game from the same path as you (ie, the steam directory). It somehow only happen in that case, and I'm frankly a bit puzzled about that. Will try to get to the bottom of this. In the meantime, I would guess you should probably be able to work around the issue by moving your KSP install elsewhere as well.

I have tried installing your mod list and I still can't reproduce the issue locally, so this doesn't seem to be a weird mod interaction either. It seems the disappearing icons are only the multiple-of-4-width/height ones, meaning those that aren't converted from PNG to DXT5. Which is something that stock does as well, the KSPCF optimization just is that those converted textures are saved on your disk to avoid having to convert them every time KSP is launched. So I'm a bit lost as to what could be happening on your end. Are you 100% sure that this happen both with the PNG caching optimization enabled and disabled ? Because when it is disabled, KSPCF really doesn't do anything very differently than stock. To be sure this isn't due to some interaction with another mod, could you try in a KSP install with only KSPCF (and its dependencies, MM and harmony) installed and this stripped down version of LRTR that only has the tech tree : https://github.com/KSPModdingLibs/KSPCommunityFixes/files/15209622/LRTR_KSPCF_Test.zip (please provide logs again with this) For reference, tracking your issue here : https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/224

I can't reproduce this. Can you reproduce it on your end and provide your KSP.log ?

@dok_377 Plane mode added in 1.2

That feels like a good idea, will try to add that additional mode.

FlyByWire SAS Mode This Kerbal Space Program plugin adds four new SAS modes and a new more relaxing way to control your vessel, especially useful for managing your gravity turns on launch : Modes Fly by wire When enabled, pitch and yaw WASD inputs don't control the vessel directly anymore, but instead control the position of a custom navball direction marker that the SAS will follow automatically. You can switch to precision mode (Caps lock key) for finer control. Fly by wire (plane mode) Identical to the fly by wire mode, but the navball marker stays at a constant position relative to the horizon. AntiParallel Available when a target is selected, will keep the vessel control part in the opposite orientation as the target. Quite useful for docking ! Parallel Available when a target is selected, will keep the vessel control part in the same orientation as the target. These new modes are available for pilots and probe cores at the same SAS level as the target and maneuver modes, but this is configurable in the settings.cfg file (doing that with a ModuleManager patch is recommended). Download and installation Compatible with KSP 1.12.3 to 1.12.5 - Available on CKAN Installation Go to the GitHub release page and download the file named FlyByWireSASMode_x.x.x.zip Open the downloaded *.zip archive Open the GameData folder of your KSP installation Delete any existing FlyByWireSASMode folder in your GameData folder Copy the FlyByWireSASMode folder found in the archive into your GameData folder License MIT Changelog 1.2.0 - 01/05/2024 Added plane mode Fixed a bug where the SAS would keep going toward the fly by wire direction after switching back to the stock stability assist mode. Put all icons in a single texture atlas 1.1.0 - 28/04/2024 Added parallel / antiparallel modes 1.0.0 - 27/04/2024 Initial release

The cache will improve overall runtime performance (ie, FPS), but don't expect loading times to be orders of magnitudes faster. Switching from a 6700K to a 5800X3D gave me triple the FPS, but maybe only 30-50% faster loading times.

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.