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 ?