Gotmachine

I don't see anything really abnormal in your screenshot. PF handle fairings as separate parts for each side, so the drag is applied to those separate parts. The equivalent stock fairing would have a single arrow pointing down from the center of the fairing base instead of two arrows pointing down from the sides, and the net effect in terms of drag would be the same (but being inside the other parts, the center arrow isn't visible, which I guess is the source of your confusion). This being said, the way PF handle fairings with separate parts for each side doesn't work very well as soon as the fairing isn't perfectly aligned with the airstream. The KSP drag cube based aerodynamics simulation doesn't have a full notion of one part hiding another. It does to some extent, but the rules are such that what happens can differ significantly from what you would logically expect as soon as you get out of simple stacks of same-diameter parts. So with those two fairing sides being separate parts, a sideway airstream will result in KSP thinking the inside of one of the two fairing side is exposed to the airstream, effectively doubling the amount of drag applied to the overall fairing compared to what you would expect. See a quick example : https://imgur.com/a/skBwKMI This is unfortunate, but I'd say that many similar discrepancies exist even in stock. They are definitely a lot more common in the modding ecosystem, as modders tend to do stuff in terms of what they want to achieve in terms of looks and functionality, and not so much in terms of what the game is capable of doing technically, which is quite limited in the specific case of aerodynamics. As for PF, the solution would be for it generate a drag cube out of a render of the assembled fairing sides (and base), and to apply that drag cube to the fairing base, the side parts having effectively no drag cube at all. But that would require a custom drag cube rendering system, as the stock (or KSPCF) API can't be used that way, they expect a single part. I guess KSPCF could provide a more flexible API for doing that if someone is interested. And on a final note, this is the main reason why FAR (usually) does a much a better job at being consistent and predictable no matter what contraption you throw at it, because it uses the actual shape of the whole vessel instead of doing things on a per part basis, allowing it to avoid many of those complex inter-part occlusion difficulties.

Well, I won't derail this thread with offtopic talk much more, if you want to discuss this further, please post in KSPCF thread. But shortly, yes, there are differences, either for specific parts where stock is producing utterly wrong drag cubes, or typically (very) small parts, as stock is accounting for the bump map (making those parts a little more draggy than what they should be) and KSPCF don't. KSPCF drag cube values will also have "floating point error" differences compared to stock ones, but this is the case in stock too when running the game on different machines/OS, the overall technique is numerically unstable anyway. Either way, apart from the very few parts where KSPCF is fixing actual bugs where stock is generating wrong drag cubes, the differences are tiny and indistinguishable in the final behavior, as there are *tons* of much larger approximations in the overall KSP aerodynamics implementation. For more in depth information on what KSPCF is doing, you can read https://github.com/KSPModdingLibs/KSPCommunityFixes/pull/139 and https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/137

KSPCF doesn't calculate drag any differently than stock.

Thanks to everyone for reporting the issues (and sorry, I hope nobody lost anything !). 1.36.0 RC2 is now available, with fixes for the following issues : Fixed a bug in the FloatingOriginPerf implementation, resulting in vessels being teleported half randomly. Fixed a bug in the FlightIntegratorPerf implementation, resulting in garbage drag values being generated during flight. Fixed (harmless) accidental deactivation of the DragCubegeneration patch. Good catch. The patch has been depreciated/removed as it has been integrated in the more general UpgradeBugs patch. We forgot to remove it from the readme.

A KSPCF release was long overdue, but contributors didn't stop cooking, so there are a lot of new patches and changes for the next version. The new patches are modifying many stock core subsystems, consequently, the chances of introducing new bugs or incompatibilities with the modding ecosystem is larger than usual, so this update hasn't been pushed to CKAN or to KSP-AVC users yet, and is available as pre-release that you can manually install. If you try this pre-release version, please report any issue or weird behavior either in the github issue tracker, or here on the forums, alongside with your KSP.log. You can also report if you tried this update and everything is working fine, this actually helps too ! Once we feel these changes have been tested enough, we will push them on the usual release channels. Required and must be downloaded separately : HarmonyKSP : Download - Homepage - Available on CKAN ModuleManager : Download - Forum post - Available on CKAN Installation Go to the GitHub release page and download the file named KSPCommunityFixes_x.x.x.zip Open the downloaded *.zip archive Open the GameData folder of your KSP installation Delete any existing KSPCommunityFixes folder in your GameData folder Copy the KSPCommunityFixes folder found in the archive into your GameData folder Changes in this version This update notably brings many flight scene performance improvements, here are some benchmarks : Ryzen 5800X3D, 32 GB DDR4 @ 3600 MHz, Radeon RX 7600XT @ 720p, average and 1% low FPS over 1000 frames. Note that these benchmarks are done in a brand new, non-modded sandbox save. Figures will likely be less pretty in a real career and/or modded game. Acapello (152 parts stock default craft) Situation Stock (avg) KSPCF (avg) Improv. Stock (1%) KSPCF (1%) Improv. Launchpad 222 246 11% 153 193 26% Launch @ 3000m 195 247 27% 121 149 23% Kerbin low orbit 240 292 22% 149 164 10% 450 parts exploration vehicle launcher (KerbalX link) Situation Stock (avg) KSPCF (avg) Improv. Stock (1% ) KSPCF (1%) Improv. Launchpad 46 73 59% 40 63 58% Launch @ 3000m 35 58 66% 29 48 66% Kerbin low orbit 46 91 98% 39 63 62% User facing changes New KSP performance patch : FasterPartFindTransform [KSP 1.12.3 - 1.12.5] : Faster, and minimal GC alloc relacements for the Part FindModelTransform* and FindHeirarchyTransform* methods. New KSP performance patch : ForceSyncSceneSwitch [KSP 1.12.0 - 1.12.5] : Forces all scene transitions to happen synchronously. Benefits scene transition time by reducing asset cleanup run count from 3 to 1 (contributed by @siimav). New KSP performance patches : this update introduce a collection of patches intended to fix various performance bottlenecks mainly relevant in high part count situations. See PR #257 and PR #256 : ModuleDockingNodeFindOtherNodesFaster : Faster lookup of other docking nodes. CollisionEnhancerFastUpdate : Optimization of the CollisionEnhancer component (responsible for part to terrain collision detection). PartSystemsFastUpdate : Optimization of various flight scene auxiliary subsystems : temperature gauges, highlighter, strut position tracking... MinorPerfTweaks : Various small performance patches (volume normalizer, eva module checks) FlightIntegratorPerf : General micro-optimization of FlightIntegrator and VesselPrecalculate, components in charge of most of heavy lifting for newtonian physics as well as atmospheric and thermal physics. FloatingOriginPerf : General micro-optimization of floating origin shifts. Main benefit is in large particle count situations (ie, launches with many engines) but this helps a bit in other cases as well. New KSP bufix : DragCubeLoadException [KSP 1.8.0 - 1.12.5] : Fix loading of drag cubes without a name failing with an IndexOutOfRangeException (contributed by @Nazfib). New KSP bufix : TimeWarpBodyCollision [KSP 1.12.0 - 1.12.5] : Fix timewarp rate not always being limited on SOI transistions, sometimes resulting in failure to detect an encounter/collision with the body in the next SOI (contributed by @JonnyOThan). New modding API improvement : KSPFieldEnumDesc [KSP 1.12.2 - 1.12.5] : Disabled by default, you can enable it with a MM patch. Adds display name and localization support for enum KSPFields. To use add Description attribute to the field (contributed by @siimav). PAWStockGroups : Added PAW groups for generators, making the UI less confusing when multiple generators are present (contributed by @yalov). Internal changes Patching now always run as the first ModuleManagerPostLoad callback, ensuring other callbacks can benefit from the patches (contributed by @al2me6). Small internal refactor of the patching infrastructure for less verbose patch declaration. Introduced a new "override" patch type, basically an automatic transpiler allowing to replace a method body with another. This has a little less overhead than a prefix doing the same thing, and allow for other patches (including non-KSPCF ones) to prefix the patched method as usual.

This is actually intended behavior, Kerbalism adds additional rules concerning antenna combinability and the resulting data rate. To quote the Kerbalism wiki : It is indeed a bit problematic in practice as this require additional micromanagement, but mainly because the only way to disable an antenna is to retract it, and many antennas aren't retractable.

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.

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.