Gotmachine
-
Posts
706 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Gotmachine
-
-
39 minutes ago, R-T-B said:
honestly, just use the profiler.
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.
-
7 hours ago, dok_377 said:
But not really a problem of the mod, the game's SAS is not very good with them either, they just wobble all over the place.
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.16 hours ago, JollyGreenGI said:Is there a way to invert the pitch controls?
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.
22 hours ago, Krazy1 said:Is a workaround like giving science credit at the beginning of the scan possible? Or somehow disabling the check for movement?
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
-
3 hours ago, Scottmm78 said:
When run together KCF causes LRTR tech tree icons to disappear.
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
-
4 hours ago, dok_377 said:
Would it be possible to have a mode that keeps the marker level relative to the surface so it could be utilized for planes? Right now it's drifting upwards over time, so planes can't fly level using it.
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 lockkey) 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.cfgfile (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
GameDatafolder of your KSP installation -
Delete any existing
FlyByWireSASModefolder in yourGameDatafolder -
Copy the
FlyByWireSASModefolder found in the archive into yourGameDatafolder
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
-
Go to the GitHub release page and download the file named
-
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. -
11 hours ago, DeadJohn said:
For example, lets say someone made a 2.5m part but incorrectly gave it a 3.75m node. Such parts cause drag issues when connected to regular 2.5m parts.
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. -
2 hours ago, stk2008 said:
its very odd though as long as I stay below 150m i can have 50+ FPS constantly no matter where I fly or how fast but as soon as I hit 150 and above FPS drops.
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.
-
10 hours ago, stk2008 said:
Sorry to keep posting this but any one got any ideas on this
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. -
3 hours ago, AmanitaVerna said:
The problem appears to be the IMGUIOptimization option. Setting it to false makes the problem go away.
Thanks for reporting. This should be fixed in the just released KSPCF 1.32.1
-
From the mentioned tweakscale thread :
6 hours ago, Lisias said:Suggesting that SolarSailNavigator is not loaded. But apparently it was!!!
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.1 hour ago, JonnyOThan said:The stock GetSubclassesOfParentClass function will break if any DLL throws an exception from GetTypes. KSPCF happens to *use* this function in one of its other patches.
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 :Quote[WRN 15:24:04.746] [KSPCF] A ReflectionTypeLoadException thrown by Assembly.GetTypes() has been handled by KSP Community Fixes. This is usually harmless, but indicates that the "SolarSailNavigator" plugin failed to load (location: "GameData\SolarSailNavigator\Plugins\SolarSailNavigator.dll")
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.1 hour ago, Lisias said:Ideally, KSPCF should print a nice message telling the thing could not be patched, instead of throwing a nasty exception that would trigger something on the flimsy KSP's loading system, making things harder to diagnose.
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.
-
4 minutes ago, matthias123 said:
for the bug i got this
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.Locationto 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).
Is there any performance fixing mod?
in KSP1 Mods Discussions
Posted · Edited by 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.