Gotmachine

I've submitted a fix for the issue on the PersistentRotation GitHub The changes need to be merged and released by @linuxgurugamer, and once that is done, the CKAN metadata must be updated to remove the mods being marked as conflicting.

Doesn't reproduce on a KSP 1.12.5 install with KSPCF 1.37.2 and ConformalDecals 0.2.14 There must be something that is specific to your install / modset. We can't investigate further without a full KSP.log. Edit : Found the root cause, this is actually caused by a bug in Shabby (a dependency of ConformalDecals), triggered when some specific other plugin is installed (likely kRPC). See https://github.com/KSPModdingLibs/Shabby/issues/21 Edit2 : Should now be fixed by updating Shabby to the latest release (0.4.1)

There was indeed such a bug in the 1.37.0 pre-release version, causing additional drag to be generated from various parts, notably wings and control surfaces. That bug is fixed in latter versions, updating should fix it.

KSPCF is being a bit over-cautious, as this isn't really an error. These messages are caused by mods using the KSP persistence API incorrectly, but this doesn't really have any side effect other than causing a tiny load time overhead that could be avoided. That error message has actually been around since a long time. I changed it from an error to a warning in the fix you mentioned and the 1.37.0 release, to avoid worrying users uselessly.

As I suspected, this is caused by the KSP Part Volume mod. For the bug to reproduce on stock ground parts, you need to enable the "Include stock parts" option in the main menu popup of that mod. The technical explanation is that KSP Part volume wrongly adds an extra ModuleCargoPart module to parts that already have a derived version of that module, any of those : - ModuleGroundPart - ModuleGroundSciencePart - ModuleGroundCommsPart - ModuleGroundExpControl - ModuleGroundExperiment Having that duplicate module is incorrect and make the inventory system freak out in all sort of ways. The issue affect all the stock DLC ground parts, and potentially any modded part implementing those stock modules (not sure there are any on the market, but still). @linuxgurugamer I've reported the issue on the KSP Part Volume github

The display issue is when the inventory UI still says you have 0.035t worth of inventory stuff after placing the dish. The real mass of the kerbal isn't affected. Did exactly what you said with the craft file you provided, that part and the next ones dont't reproduce for me, the mass is correct. I would suggest trying in a 100% stock install to rule out some mod being the culprit or not. Maybe post your modulemanager.configcache file, I would suspect some mod altering the stock config.

There are several inventory related bugs lingering around, I'm aware of a few of them. I can reproduce the part of the issue where the mass of the ground part is still applied to the Kerbal after placing it. This being said, it's only a UI/visual issue, under the hood the Kerbal mass is correctly updated, and moving stuff around the inventory fixes the UI not being up-to-date. However I can't reproduce the part of your issue where the ground part weight 4 tons upon picking it up again. Either there is something different on your KSP install, or there is some specific reproduction steps I missed.

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.