Jump to content

Gotmachine

Members
  • Posts

    693
  • Joined

Reputation

1,381 Excellent

3 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Thanks for reporting. This should be fixed in the just released KSPCF 1.32.1
  9. From the mentioned tweakscale thread : 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. 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 : 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. 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
  10. @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.
  11. 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 :
  12. 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.Location to 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).
  13. @Comrad_501 So, I have no idea from which mod your actual issue comes from, but the root cause of your problem is a plugin failing to load, either because it is missing some dependency, or because it is build against an older version of KSP. When such a plugin fails to load in such a way, it actually still is registered in the list of loaded assemblies, but most calls to it or about its metadata will fail in unpredictable ways. Notably, this can can issues when another plugin tries to get information about that assembly metadata. Specifically, a call to `Assembly.GetTypes()` on such an assembly will fail with a `ReflectionTypeLoadException`, see official API docs. This is a relatively well know failure mode in the modded KSP ecosystem, which is why plugins usually wrap such calls in a try/catch block to handle this gracefully. However, some plugins may be forgetting to do so, so as a part of its fixes, KSPCommunityFixes automatically intercept that exception, handle it gracefully (so only the problematic plugin are affected, not others), and present it to end users in a clear way during loading, so they are aware that some plugin is failing to load, for example like this : However, the reason you got directed here is because the KSPCF handler for that error actually has a bug where it will in turn throw an exception when it tries to handle that original exception, in a corner case scenario involving dynamic assemblies. From the end user point of view, this doesn't change much, as an unhandled exception would have occurred either way if KSPCF wasn't installed. This being said, KSPCF obviously fails at its purpose of providing extra correction for that error (that, again, would have happened anyway if KSPCF wasn't present), so I've pushed a fix, and will try to make a release with it soon.
  14. Sounds like you are using an outdated mod packing MiniAVC, a version checking tool that is known to cause such issues in recent (1.8+) KSP versions. Try searching your GameData folder and subfolders for a file named "MiniAVC.dll" and delete it (won't do any harm in any case). But any mod packing that tool is likely vastly outdated and should probably not be used at all. Edit : For some weird reason, you have alternate versions of System.XML and System.Core in the KerbalKonstruct mod folder. That shouldn't be the case, and is definitely gonna cause a lot of issues. I do'nt know how you installed your mods, but I'd recommend starting over from a clean state.
  15. Had some time to check your logs, and have done a bit of digging. Check out the github issue for details. The gist of the issue is your GPU driver crashing when instructed to load DXT5 DDS textures when those textures have a specific NPOT resolution. In your logs, it's crashing when loading : A 320 pixels height texture at level 1/4 mips, so 80 A 160 pixels height texture at level 1/2 mips, so 80 again I've found a bunch of reports from 2012-2015 era mac users having a similar issue in various games and applications, including KSP. To validate could you try, without KSPCF being installed, to just drop these 2 textures in your GameData folder, and try to launch the game at 1/2 and 1/4 texture resolution (TEXTURE_QUALITY = 1 and TEXTURE_QUALITY = 2) ? I suspect your game will crash as well, please send a log if it happens. The likely reason it happens when KSPCF is installed is because it tries to convert additional textures to the DDS format, and those textures have a tendency to use those problematic NPOT resolutions, but as far as I can tell this isn't directly caused by KSPCF. If I'm right, I don't think there is anything I can do to fix this, especially since it is happening on specific hardware, and likely a very specific hardware/software combination. I would suggest to check if the GPU drivers and OS are up-to-date. In other games/apps, people mention having this issue after updating OSX to a newer version.
×
×
  • Create New...