Jump to content

Gotmachine

Members
  • Posts

    689
  • Joined

Reputation

1,374 Excellent

3 Followers

Recent Profile Visitors

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

  1. 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. 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.
  3. 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.
  4. Thanks for reporting. This should be fixed in the just released KSPCF 1.32.1
  5. 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
  6. @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.
  7. 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 :
  8. 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).
  9. @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.
  10. 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.
  11. 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.
  12. I just tried with a replica of your setup, and everything seems to be working as expected : I'm not sure what could be happening, especially since KSPCF doesn't touch RCS stuff directly, and very little else that could somehow end up causing such an issue. There is nothing else I can do if I can't reproduce it, so I need more information. At the very least could you provide a download link to your KSP.log ? And if you're playing mostly stock, can you also provide your savegame where this issue can be reproduced (persistent.sfs file in the "saves\yourgamename\" folder) ? For easier/automated bug reporting, I'd suggest using : No, but at a few exceptions all patches can be individually disabled, as mentioned in the OP : Individual patches can be enabled or disabled by editing the Settings.cfg file. To make sure your changes persist when the mod is updated, it is recommended to make them in a ModuleManager patch. Open the Extras\KSPCF_UserSettings.cfg.extra file in a text editor for further instructions.
  13. Interplanetary is possible, within reason. However, Kerbalism was indeed balanced around "past and current" technological levels and mission profiles, which is what I warned you against. We consider landing Kerbals on Duna and sending them back more or less the ultimate achievement, just like putting foots on Mars would be in the real world. Stuff like the RDU or active radiation shields are mostly placeholder for people wanting to mess around, and everything is balanced around limiting the maximal mission time, crewed or uncrewed, to a dozen years or so (actually more like 5-6 years for manned). Servicing stuff with EVA Kerbals was never meant as a gameplay loop, just a stopgap measure in case of an unfortunate event. Yes, the way radiation is modeled has a bunch of shortcomings, and it could use a balance pass, but it mostly works for the intended scope. Sure, you can throw nuclear reactors or various future tech mods, and tweak settings to try to get past what the mod intends to be and do things like a grand tour, but as you noted, it's mostly an exercise in frustration, which is exactly why I warned you in the first place.
  14. Aside from the fact that switching from Unity to Unreal would basically mean restarting from scratch and require several years to just come back to where they are now, the whole idea that the game would be better by doing so is questionable at best. The various cutting edge stuff from Unreal (you mentionned nanite) is more or less useless for a game like KSP. The only significant dependency KSP has on the engine is rigidbody physics, and while it can be argued that the Chaos engine from Unreal might be a slightly better fit that PhysX in Unity, the best fit would actually be either a custom implementation, or at the very least a forked version of an off-the-shelf physics engine. Most technical (and performance) issues in KSP 1 or 2 comes from subpar technical solutions due to a lack of an adequate software engineering capacity given the scope and design requirements. The engine they are using is a minor factor. If they end up miraculously getting greenlighted for a large refactoring project, it's more likely to be a project revamping their core architecture issues in the light of the experience and feedback they acquired in the last years than a base engine switch.
  15. Terrain is just as empty anyway, this has nothing to do with scale, but everything to do with the lack of a proper high detail procedural terrain solution. Edit : there are many ways a larger scale improves immersion. In the end, it comes down to adequately scaling a given technology with what is supposed to achieve in the real world. It means larger rockets and contraptions in general, more incentive to do complex missions with stuff like orbital assembly and resupplying, more incentive to actually have off-world bases and stations. Once you have understood the basics of rocket building and orbital/interplanetary navigation, it's way too easy to go anywhere and do everything in KSP. To me, expanding the scale of the Kerbal system to something like 1/4 and revamping it with new places would have been much more in the spirit of KSP than expanding the scope to science fiction interstellar technologies. There are 80 planets, moons and other bodies with larger than the KSP Mun radius in the solar system, countless asteroids and comets, with tons of unique features, including ones that could have actually meant something in terms of gameplay. I know it isn't a popular opinion, but while KSP 1 was briliant at defining a new sub-genre, a lot of the justifications for many of its technical and design decisions didn't have much validity anymore 10 years latter and should have been questioned when making a sequel, instead of taking everything KSP 1 did and just envisioning that sequel as a big DLC.
×
×
  • Create New...