Jump to content

Gotmachine

Members
  • Posts

    690
  • Joined

Everything posted by Gotmachine

  1. The answer is that they didn't kept the "physics on". The only thing preventing running at arbitrary timewarp speeds with engines burning in KSP 1 is that joint/RB physics are unstable at large timesteps. There is no additional computational cost to running at large timewarp speeds. The game engine is still running at 50 ticks/second, which mean that at 1x timewarp, each tick is 1/50 = 0.02s. To accelerate time (ie, timewarp), you instead pass a higher elapsed time (the "timestep") for each tick. For example, if each tick is 0.08s, that gives you 4x timewarp. If you pass 20s, that gives you 1000x timewarp. The underlying difficulty is that whatever subsystem runs in each tick must behave consistently whatever timestep you feed it. In KSP 1, most systems are actually designed to accept that. However, RB/joint physics simulation stability is heavily timestep dependent, that's why vessels have a higher probablity of experiencing instabilities in phys-warp in KSP 1. KSP 2 isn't different in that regard, what they did is just disable physics when timewarping, and are directly summing the forces resulting from engine thrust to compute the frame displacement (ie, the vessel acceleration).
  2. Well, as I said, please provide a save that reproduce it and I will take a look. I was just pondering that while there are cases where the oscillation issue can be a result of interactions between the SAS, it's control point and the controlled attitude control providers, the underlying root issue has very little to do with that and can be reproduced with a vessel that doesn't has any SAS nor any attitude control providers, it's an inherent instability of the physics simulation KSP uses.
  3. To expand a bit, I'd say that changing the reference transform point (ie, "control from here") has indeed a direct effect on the SAS behavior for attitude control providers (reaction wheels, rcs, gimbals, control surfaces). The conditions for a feedback effect where the SAS enter a self-reinforcing "shake inducing" loop are indeed primarily dependent on the position of the reference transform, the general rules being that when the reference transform is far away from the attitude control providers, the refrence transform momentum has a greater chance to be in an opposite direction as the attitude control provider at any given time due to ongoing or pre-existing oscillation effects. After looking a bit into it, I'm very doubtful there is an actual bug where for a single vessel, some components would be referring to different reference transforms. However, without doing any testing, I'd say there is decent probability for the reference transform to be reset to the root part in some circumstances, like docking. And in the case of docking, it's likely the root part of the combined vessels will be located at some "far end", which might be a not-so-great place as far as the above feedback effect is concerned. The thing is, by setting manually a different reference transform, you're acting knowingly on the root issue, with all the mighty analysis power of your brain. Turning that into an algorithmic rule is likely difficult, might simply not work (the fact that you're acting manually with a delay after the feedback loop has started might play a great role in why it actually works), and is also likely to have other unwanted side effects.
  4. I wouldn't be as confident as you, but I don't want to dismiss your findings either. What I need to make your report actionable is a reproduction setup, meaning a save file made in a stock (non-modded) game that I can open to reproduce the "Kraken Death Shake" and your fix on my side.
  5. V1.28.0 is out : New KSP bugfix : ReRootPreserveSurfaceAttach [KSP 1.8.0 - 1.12.5], disable the stock behavior of altering surface attachment nodes on re-rooting, a questionable QoL feature that doesn't work correctly, leading to permanently borked attachement nodes. New performance patch : DisableHiddenPortraits [KSP 1.8.0 - 1.12.5], prevent non-visible crew portraits from being rendered after a switch back from the map view (and other cases), causing a significant perf hit when there are many kerbals in the vessel. New performance/bugfix patch : DragCubeGeneration [KSP 1.12.0 - 1.12.5], faster and more reliable implementation of drag cube generation. Improves overall loading times (both game load and scene/vessel/ship load times), prevent occasional lag spikes (in the editor mostly) and fix some issues causing incorrect drag cubes to be generated (notable examples are the stock inflatable heat shield, the 1.25m and 2.5m nose cones and the Mainsail shroud). Note that by design, this patch results in a small deviation from the stock behavior for buyoancy, aerodynamics and thermodynamics, as the generated drag cubes will be slightly different. New API/modding patch : BetterDDSSupport [KSP 1.12.3 - 1.12.5] (actually part of the FastLoader patch), implement compatibility with the DXT10/DXGI specification, and support of loading additional texture formats : BC4 : single channel (R) compressed 4 bpp BC5 : 2 channels (RG) compressed 8 bpp BC6H : 3 channels (RGB) compressed 8 bpp with HDR color range (Not available on MacOS) BC7 : 4 channels (RGBA) compressed 8 bpp (Not available on MacOS) R16G16B16A16 : 4 channels (RGBA) uncompressed 64 bpp R16_FLOAT / R32_FLOAT : single channel (R) uncompressed 16/32 bpp R16G16_FLOAT / R32G32_FLOAT : 2 channels (RG) uncompressed 32/64 bpp R16G16B16A16_FLOAT / R32G32B32A32_FLOAT : 4 channels (RGBA) uncompressed 64/128 bpp DisableManeuverTool : added MM-patcheable flags to set the default enabled state of the maneuver tool or to forcefully disable it, see Settings.cfg.
  6. Not this again. The addon posting rules are terms of service for the forums, they have not relationship whatsoever to what you and can't do with the game itself. Aside from that, the truth is that modding doesn't have any legal framework whatsoever. The EULA doesn't say anything, and there are no laws in any country that are clearly applicable on the matter. The only rule is that every time you hear someone say that X is legal/allowed or illegal/disallowed in the context of modding, it has no legal basis whatsoever and it's guaranteed to be an arbitrary rule rooted in someone personal opinion. And this apply even to developers, publishers and their legal teams, which are blindly copypasting the exact same sentence in every software agreement since 4 decades. Still the above sentence does contain "You shall not modify the Software, in whole or in part". How this should be interpreted in the context of modding is anyone's guess. I personally think it means modding in general is not allowed, but your interpretation has just as much legal value as mine : none. And until someone decide to go in front of a court to ask a judge, nobody has the answer, and even so, it would be an answer for that specific case, under the legal framework of that specific country. Said otherwise, enjoy modding whatever you want however you want, try to not harm the interests of anyone in the process, and everything will be fine.
  7. There never really was an SDK for KSP 1 either, excepted for PartTools, which is just an Unity exporter plugin for the KSP wrapper over the Unity asset format. And KSP 1 being so modding friendly was in a large part an accidental side effect of early architectural choices (as well as a natural consequence of KSP being an Unity game). And while Squad definitely put some attention to avoid actively harming moddability and took care of building/refactoring the codebase in ways that would be extensible (especially around 1.0-1.3), most of those architectural choices were to their own benefit as well. The API and constructs that KSP 1 modders are relying on are with almost no exception the actual internals of the game. And on the topic of EULA violation, there is absolutely no indication of what is allowed or not as far as the EULA is concerned (be it for KSP 1 or 2), and if you actually read the EULA in the strictest sense, modding isn't allowed at all.
  8. You can go mixed bag, but it's a quite delicate setup even if you plan your design around it. No. KSP game logic is heavily tied to parts, and involves physics engine queries all the time. That would be a nightmare to put put together and maintain. Modules are actually part components, nothing more. They tried to decouple their core logic from the Unity GameObjects / Monobehaviors with some sort of MVC pattern, but in practice there is very high level of coupling between everything. Well, all I can say is that I peeped long enough into said code to be quite doubtful of that. hahahahahahahahahahahaha deep breath hahahahahahahahaha They more or less already do that anyway, for various reasons, but mostly because of the floating origin. While PhysX actually has support for a floating origin, the Unity wrapper doesn't expose it, so they already are repositioning everything manually at regular intervals (and tracking the position of everything independently as well). As I said, there is actually not that much relying on the physics engine in KSP (be it 1 or 2). It's used for a bunch of spatial queries, applying their independently computed thrust/atmospheric forces to the jointed rigidbodies and getting the frame velocity out of it, terrain and inter-vessel collisions, and that's it for the most part. The only thing that I can think of that would require them to roll out a significant new subsystem is the wheels/suspensions because currently they are relying on a third party asset dependent on the Unity PhysX wrapper. This is still is a major undertaking, but I would estimate on the same order of magnitude as swapping everything from using the built-in render pipeline to the HDRP pipeline, which they have apparently decided to do. The difference is that swapping the rendering pipeline is part of a necessary refactor to address the huge issues they have with rendering performance, while swapping the physics engine wouldn't bring much benefit as long as they stick with the idea that the un-physical KSP 1 behavior of part connections is a design requirement. And arguably, if they somehow have the good idea to throw it away and actually think about something that make sense from a game design perspective, there are other approaches in terms of physics that are better fitted to create elements of structural integrity gameplay, in the realm of beam / soft-body solvers.
  9. That's not gonna happen. The GameObject entity/component is a fully OOP driven framework, whereas DOTS/Entities is a fully data-oriented paradigm with no support whatsoever for classes or reference types, and completely different workflows. There is absolutely no conversion path possible without scrapping 100% of the existing game logic codebase, and doing an insane amount of rewiring for the rest. Beside, they don't have to use the built-in PhysX or Havoc integration, it's perfectly possible to use any physics engine from Unity, they "just" have to build the interop layer for it. It's relatively common to have Unity games plugging into C++ libraries for specific stuff (there is even an example in the KSP modding scene, the n-body integrator of Principia is written as a C++ library). This would be vastly more doable than rewritting the whole game with the DOTS stack (and I would argue that DOTS Physics might actually be a better fit than Havoc in that case), especially since KSP 2 (at least currently without robotics) is using a relatively narrow subset of features (edit : actually, a major pain point would wheels and landing legs, those would require a lot of work instead of just being a thin wrapper over VPP). Still, that would be a major undertaking, and the potential benefits are low, so I don't see how they can justify diverting dev resources to such an endeavor while they are still struggling to deliver a playable and commercially viable game. And on a side note, while *some* issues of KSP 1/2 physics can be traced down to limitations of PhysX that would be alleviated in Havoc, a lot of them are purely on the KSP side, and some of them are *conceptual* issues rather than technical issues.
  10. Send your log, but kopernicus.components.dll is an old dll from a Kopernicus version at least 4 years old that doesn't even support KSP 1.8 or newer, so either you need to update/reinstall Kopernicus, or you're using a KSP version older than 1.8, which KSPCF doesn't support.
  11. V1.27.0 is out : New performance patch : LocalizerPerf [KSP 1.8.0 - 1.12.5] Faster and minimal-allocation replacements for the Localizer.Format() methods, can provide significant speedup for GUI-heavy mods using localized strings. FastLoader : Faster implementation of the stock translateLoadedNodes method, can reduce loading time by up to 30 seconds in a heavily modded install (thanks to @siimav for spotting this). LandingGearLights : fixed the patch not applying to the smaller LY-10 landing gear (thanks to @JonnyOThan). Fixed issue #98 : ConfigNodePerf patch ignoring the last key/value pair when parsing a node-less, values only input. Notably fix a compatibility issue with the SimpleConstruction mod causing missing vessel construction costs.
  12. Yep, the stock transfer math is not very reliable, not to say outright broken. It can also fail in rather catastrophic ways that can cause stutters or even a total freeze of the game, that's why KSPCF gives the ability to disable the stock maneuver planner (which share the same transfer analysis code, and runs in the background even if you don't touch it). I personally don't have the will to work on this, mainly because the modding ecosystem already has plenty of mature alternatives, but if someone is willing, contributions are welcome. That patch indeed can't be disabled from the settings because it runs right on game launch, before ModuleManager patches are applied, and the KSPCF settings are meant to be altered from a MM patch. This being said, having a separate config file/switch to disable this specific patch is doable. Can you give specific repro steps for that ? Because engine shrouds state is correctly carried over when reverting to VAB and in other situations on my end.
  13. "Data mining" indeed. Funny how that expression is being freely used since KSP 2 is out when any mention of what this really mean has been the subject of a moderator crusade for years. But yeah, in many ways, this is KSP 1 2.0 : the "breaking backward compatibility is allowed" update. They took KSP 1, incrementally refactored the codebase taking advantage of modern Unity advancement where relevant (asset loading with addressables, json serialization, PBR...), shuffled a few things around to allow the "thrust under warp" feature, gave it a visual facelift, and that's it for the most part. The reason most people somewhat familiar with the KSP 1 codebase (or just game/software engineers) are disappointed is because it's just that : a very cautious refactor that didn't even try to address the core issues of KSP 1. And given how much resources they were given by T2/PD, KSP 2 could have been so much more. The reasons those resources got wasted are not very clear (project leadership issues ? scope creep ? wrong priorities ?), but what is very clear is that they underestimated how critical and difficult engineering a game like KSP is, and thought they could avoid the whole issue by being conservative and copypasting the KSP 1 implementations, falling into the trap that those implementations had massive and fundamental issues to begin with. If KSP 2 has been delayed 3 times for 2 years, and likely won't deliver a feature-complete 1.0 before at least a year, and was released as EA as a hot buggy mess, it's because advancement on the software engineering and codebase is lagging years behind the rest. Planet and parts art assets are ready, including assets for unreleased features. Sound design is complete and very polished. Even the UI is an relatively good place. The codebase by contrast looks like it has gone through dozens of iterations and is barely out of prototyping. There are many parts of it that feel like the first quick-and-dirty-get-it-somewhat-functional implementation, others feel like they spent months on the drawing board trying to make it extra fancy, some parts are straight-up copypasted from KSP 1, and the overall code quality is very, very uneven. KSP 1 is often qualified as a huge mess of spaghetti code, and they clearly spent a lot of time refactoring the whole thing with a textbook Model-View-Controller pattern. Unfortunately, textbook patterns don't make good games, features and performance does. And KSP 2 doesn't address any of the long standing issues of the KSP 1 core features, nor its performance issues. They will never get better performance than KSP 1 in terms of part count being a CPU bottleneck. They made things even worse in that regard, for many reasons, but mainly because now all parts on all vessels (instead of just the active vessel in KSP 1) contribute to the CPU bottleneck. Their core architecture doesn't implement, and unless they have that huge refactor already in the works, will never be able to implement any of the usual patterns that could have alleviated that issue (multithreading, data-oriented programming). Their MVC pattern does nothing to help on that end, and TBH, the level of coupling between everything is already making the MVC pattern mostly pointless. The aerodynamics and buoyancy integrators are still based on the objectively terrible per-part drag cube system. That system is intrinsically inconsistent, not especially good from a performance PoV, and requires handling tons of corner cases all around the codebase. The joint/RB physics are still based on the PhysX integrator, which is simply totally inadequate for the task, not only in terms of simulation stability and achieving gameplay intent, but also in terms of performance because they are forced to implement tons of extremely hacky workarounds to make it work in ways it doesn't support. The resource (ie, fuel) query/processing system they have put together is a counter-example, they did actually reimplement it differently than in KSP 1. But interestingly, it manages to not address any of the long standing issues of its KSP 1 counterpart, while having abysmal performance compared to the KSP 1 implementation. The awful global GameEvents internal messaging system ? They kept it with a pointless facelift, not fixing the conceptual flaw that the thing is uselessly broadcasting messages to every entity in the world, and also managed to make it slower... One example of something they are rethinking from scratch is the thermodynamics. With resource processing, this will be the only major departure from the KSP 1 core subsystems, it will be interesting to see how this pan out when they finally manage to release it. Some people are speculating that they are working on some large refactors in parallel branches, and this is indeed how development works. But with every patch and feature that get released, the cost of merging such refactors becomes exponentially higher, and given that they are likely under huge pressure to get the 1.0 features out in less than a multi-year timeframe, I wouldn't bet on such refactors ever happening. There are a few things that are better than in KSP 1. People have noticed that for the most part, long loading times are gone, but this is mostly just a side effect of the game not being limited by constraints that existed 12 years ago in Unity. There are areas where they rewrote things with some success. While they did a very questionable job with the terrain texturing shader (which is a huge GPU bottleneck), their rewrite of the PQS mesh generation subsystem is one of the few thing that is objectively good. There are small improvements here and there. I'm personally very unimpressed by the overall UI/UX, but most people seem to like what they did here, and this is an area where they can easily improve, contrary to other more core aspects. To temper my words, unless the game gets canned because of low sales, them failing to deliver the 1.0 features in a reasonable timeframe, or a bit of both, I still think they will end up with a quite clunky, but somewhat enjoyable game that will achieve its high level goals, just like KSP 1 did. It's just that in many ways, and specifically those where KSP 1 was at it's worst, KSP 2 is just as bad, and that leaves a bitter taste for a specific population of long time KSP 1 players and modders. Okay, big off-topic rant.
  14. "Good" depends on your definition of "good". Here you mean "high performance". But Unity never was about performance, it's good for plenty of reasons, and performance isn't (or at least wasn't until recently) one of them. Yet it's hard to argue against its massive success, and things exists for a reason. Most if it is due to it being the most productive engine for putting small to mid sized games out of the pipeline as quick as possible. You can get a game (and not only a game, but any 2D/3D application) done in Unity with less man-hours, and less skilled man-hours than with any other option out there. And Unity's primary market is mobile games and various other "I need a 2D/3D frontend" applications, an area where you just need to the thing to run, and ideally to run on several target platforms with minimal additional investment. In those markets, it doesn't need to be pretty, it doesn't need to be optimized, it just need the smallest possible concept-to-product cost. That's also why Unity is quite a success in the indie games scene. But over the years, in trying to address every possible platform and every possible market, Unity has become capable of doing everything, but it is good at nothing. It's the jack-of-all-trades of the game engines, but the foundations are starting to seriously lag behind the state of the art. And they have acknowledged that. They have many multi-year ongoing foundational improvements in the pipeline, many of them are specifically about addressing historic performance limitations. SRP, UITK, DOTS, Burst, Jobs, Unity Physics, moving away from Mono to the modern .NET ecosytem, all those combined will probably put back Unity in the game, so to speak. There is definitely a lot of frustration and valid criticism as to how long all those ongoing changes are taking to come to fruition. They tried to do all that incrementally, sometimes with a lack of focus, and with the goal of maintaining as much backward compatibility as possible, which also stem from the fact that again, a large share of the Unity market is devs relying on being able to make their next product by reusing 80% of existing assets and workflows. There was some recent acknowledgment of those mistakes, and it seems they are slowly changing how they are handling those projects, but as you said, it's a multi-billion corporation where things have quite a bit of inertia. Arguably, KSP 2 development started in the wrong timeframe, where none of those newer options were in a stable enough state to rely on them in production (although many games did with quite some sucess in the same timeframe). Not that it really matters anyway, given that for the most part, KSP 2 is just a mild refactor of the KSP 1 codebase, so I doubt that it would have changed anything.
  15. I'm quite skeptical about the results in the first video. Stock KSP with a craft that simple should be getting a solid 150+ FPS on a 5800X3D, not 80 FPS. For me (on a 5800X3D), launching a stock Dynawing (~150 parts) results in 280-290 FPS average during launch, 330-340 FPS in space and with ~100 parts on reentry, still getting 160-170 FPS. And I doubt the craft in the video is actually more than 50-60 parts, so something is not right with the setup, like some driver enforced VSync. The Unity/Mono pair is certainly part of the reason why things are scaling that way. KSP, and to an even greater extent modded KSP is also far from doing things in an optimized way. It's a game whose foundations are built on Unity 4 from 12 years ago. As for KSP 2, it's quite pointless to even try to assess it's performance at this point. The thing is coded like a C# desktop application, with absolutely zero regard to even the most basic guidelines on to how to use C# correctly in the context of Unity. The thing is spitting 2-3MB of GC allocations per frame, and thta's only the tip of the iceberg. But to some extent, it's perfectly understandable to have some types of games benefit from a large L3 cache. Factorio is a not entirely, but still mostly single-threaded game, which is quite renowned for being a very optimized codebase using a lot of low level optimizations, especially in terms of memory packing. Yet it benefits massively from the additional L3 cache on a 5800X3D, simply because by nature, it's "main" in-memory data set is huge, to the point that a 5800X3D beat a 13900K by a whooping 30%, despite its raw IPC being roughly 50% less...
  16. This was on discord in private channels, so I can't link you, but one people made automated benchmarks, executing a predefined launch sequence in the same savegame, and monitoring frame times with a custom plugin, all that in a relatively heavily modded game. He compared a 6600K @ 4.4Ghz with a 5800X3D. Average frame time was 73 vs 124 FPS in bench 1, 45 vs 89 FPS in bench 2 . 1% lows were 50% better in bench 1, and actually 15% lower in bench 2, which isn't surprising given that KSP has a chronic issue with some specific heavy loads / cache rebuilds kicking in at semi-regular intervals with a relatively high frequency. I've personally got very similar results in much less rigorous testing both in stock and in a mildly modded game, comparing a [email protected] Ghz and a 5800X3D.
  17. That couldn't be further from reality. I haven't tested anything in KSP 2, but I can say with certainty that the architecture is very similar to KSP 1. It's a huge single-threaded C# codebase calling in a lot of mostly static, scattered, and large memory allocations. Which is why a huge L3 cache does literal wonders, because suddenly all those "not-hot" but still "grabbed-many-times-every-frame" memory allocations are in the L3 cache instead of requiring a round trip to RAM. I can personally confirm that KSP 1 gets a huge performance increase from the 5800X3D compared to an mildy overclocked 6700K. For reference a 6700K has per core L1/L2/L3 cache of 64KB/256KB/2MB vs 64KB/512KB/96MB for the 5800X3D. In terms of raw IPC (with the overclock on the 6700K), the 5800X3D is only 15-25% better (tested with a variety of single threaded benchmarks, including some mildly cache sensitive ones). Yet the effective throughput increase in terms of frame time in KSP 1 is 70-90%. This has also been confirmed by other people having doing some (quite rigorous) benchmarking in KSP 1 with a 5800X3D, and is in-line with the results in other games where size of the data set accessed every frame in quite large. Edit : All this being said, to compare apples to apples, compared to intel 12th/13th gen or to the Ryzen 7XXX series, the 5800X3D is lagging behind quite a lot in terms of raw IPC and frequency, and all those newer gen CPUs (including intel ones) have massively increased L2/L3 caches compared to a 6700K, so the comparative benefit of the extra L3 cache of the *X3D (including the new 7*X3D series) is likely much less dramatic than the above results. For example, in Cities: Skyline (another mainly single-threaded Unity/C# game with very similar bottlenecks as KSP), the 5800X3D only provide a 10-20% frame time increase over a 5800X (non-3D). The 5800X is essentially the same CPU, but with a per-core cache of 64KB/512KB/32MB (vs 96MB for the X3D), but it is clocked a bit higher. What this demonstrate is that increasing cache size is very beneficial when you go from a case where this is a major bottleneck in a memory-access intensive game, but past the point where you can fit most of the frequently used data set in the cache, increasing cache size stops yielding significant perf improvements. A 6700K with 256KB/2MB of L2/L3 cache per core is vastly bottlenecked in those cases, but the difference between 512Kb/32MB and 512KB/96MB is much less significant, and a similar reasoning applies to Intel 12/13th gen where the per core L2/L3 cache sizes vary from 1MB/20MB on mid/low-tier models to 2MB/33MB on mid/high tier models.
  18. LOD techniques are needed when you start having too much stuff being rendered, and this becomes a bottleneck for the GPU. In KSP, as far as parts are concerned, you're pretty much guaranteed to hit a CPU bottleneck far before even a quite low end GPU will be breaking a sweat. So no, KSP doesn't implement a LOD system for parts, and it doesn't need to... It does however implement a relatively complex LOD system for rendering (and generating) the celestial bodies terrain, the PQS system.
  19. Well, the only low hanging fruit is the resource request system. It's one of the main part-count sensitive performance hog, and the current implementation is very, very inefficient. This is a relatively easy refactor that would have a massive impact, at least if they actually rewrite it with performance first in mind, unlike just patching a few surface issues like they did in the 0.1.1 patch. But aside from that, they don't have a lot of options. To give a basic example, in KSP 1, the game doesn't care if your commsat has enough EC generation capacity to keep up with the probe core EC consumption. As long as there was some battery left when you switch away, you're good. KSP 2 in contrast always do the math of actually generating and consuming EC, even if the vessel is out of physics range. This is arguably a very nice feature, but they totally failed to build adequate foundations for it to work from a performance perspective, and it will likely get worse once they start adding gameplay elements like heat management and more complex resource chains, because those will be even more demanding from a performance perspective. Realistically, I don't see them rewriting the whole thing to parallelize it or to take a data-oriented approach. This is a high effort, high impact refactor of a huge proportion of the codebase that would block their ability to implement any other feature until this is done. And the required effort gets higher for each feature that get added, so unless this happen very soon, this has no chance of ever happening. What is in the realm of what can happen is them rate-limiting the thing so only a few vessels are ticked every frame. This would still require some non-trivial refactoring, but this is the only way they can prevent the general issue that the game performance ceiling is directly proportional to the total part count. They could also implement some sort of "on rail" state where they don't tick at all some "less important" vessels (ie, non-controllable debris). They might actually be doing this already, but I didn't see it when I looked.
  20. 1. Kopernicus 2. Very marginal gains, unlikely to make any visible/significant difference in practice.
  21. The KSP "API" or codebase isn't really the problem. Arguably the modding community could have come with better tools/workflows in some areas. But ultimately, it's just that the manpower to come up with more polished/ambitious gameplay mods is lacking (again, at the exception of RP1). The KSP modding scene is just not as big and dynamic as it was in the KSP 0.9-1.7 era, and remaining modders have somewhat given up on the idea of extending/reworking the KSP gameplay/features.
  22. Would you be so kind as to provide said KSP.log files and, ideally, links or additional context on the original reports ?
  23. Ok, that's weird. Try to disable the "LostSoundAfterSceneSwitch" KSPCF patch, but I'm a bit skeptical the issue is directly caused by KSPCF. Please provide your KSP.log, that would be a starting point. Can you give a broad estimation of when you had that bug ? The information would at least allow me to clear out that this isn't due to something I did in the few last days KSPCF updates. [snip] Problem preemptively solved !
  24. Coming up with a *stable* and somewhat enjoyable modded KSP install can indeed be quite the challenge. You won't find any "how to guide", because everyone has different desires in term of what combination of mods they want. I'd say that the only controlled, beginner friendly modded ecosystem is RO/RP1. It's by far the most actively maintained, and the team actively work to ensure that the core and supported mods work well together and provide a good user experience. But in the general modding jungle, things can indeed get ugly. My recommendations would be : - Avoid any mod that isn't somewhat actively maintained and explicitly updated for the latest major KSP version (1.12.x), and stick to the widely used "quality" mods. - Don't go overboard with how many mods you try to combine, especially the big mods, and don't try to combine mods that have some overlapping in functionality / purpose - Some "big mods" are doing things in a way that tend to cut them from the general ecosystem. Examples of such mods are Kerbalism or KSPIE. Those are two mods that work relatively well "alone", but have tons of compatibility issues with many other mods. But I share the feeling that the KSP 1 modding scene has somewhat failed to deliver a polished experience, at least on the "going beyond the stock gameplay" side. I'm still profoundly dissatisfied with the modded career mode experience. There are good ideas here and there, but nobody managed to consolidate them in a polished and well integrated way. The best effort is again RP1, but its focus on realism isn't for everyone. Anyway, if you want some personal recommendations : - For the planet pack, either JNSQ (a re-imagination and expansion of the stock system) or KSRSS (1/4 sized real solar system). Both provide great and somewhat up-to-date visuals and the 2.5x scale is a perfect balance for stock-sized parts to get that feeling of "real rockets" instead of "toy rockets". - For additional parts, restock/restock+ and the near future suite (and various other part mods by Nertea). This provide everything you can possible need with minimal overlap, and with great integration, as well as some relatively polished gameplay mechanisms. The only thing that is somewhat missing is surface base parts, which can well covered by Planetside Exploration Technologies - For progression mods, I would always recommend Strategia and the most well known Contract Configurator packs, which while not a game-changer, at least turn the mess that are the stock strategy and contract system in something vaguely coherent. I'm not a fan of the various tech tree mods beyond CTT, I think the whole "get science points to unlock parts" gameplay loop is boring and broken anyway, and alternate tech trees invariably come with tons of compatibility and balance issues. - For life support, ISRU and offworld base building mods, that's where things start to become real messy. There is the USI LS/MKS option, which is somewhat complete and relatively well integrated with the various part mods, but I personally find the thing shallow, cumbersome and frustrating to play with as well as somehwat buggy. Kerbalism has great life support and science progression mechanisms, but its resource and ISRU systems are incomplete, it's reliability system is annoying, its radiation system is quite limiting and it is a bit buggy and has major incompatibilities with other mods. TAC-LS is cumbersome and buggy. For LS, Snacks is... somewhat decent if you want something simple. Offworld rocket building can be covered by EPL, which is... lets say functional. - There are some mods attempting to implement whole new gameplay mechanisms like KCT, ScrapYard or Bureaucracy. I personally find them poorly thought and poorly implemented, and they come with their own caveats in terms of bugs and incompatibilities. - I'm personally staying away from anything "interstellar". That doesn't add much in terms of gameplay and the large distances are causing various bugs. In terms of parts and "technologies" to get there, KSPIE is a hot and buggy mess, and FFT are just overpowered engines that don't really create much additional gameplay considerations.
  25. Well, don't take it wrong, but I don't want to waste time investigating issues that aren't caused by KSPCF in the first place. So do you both confirm that you saw that issue happening when KSP Community Fixes *isn't* installed ? And please provide your KSP.log when reporting an issue. Spike88 : Hard to say what exactly is causing the app launcher issue from your log, as your log is showing errors coming from tons of different stuff, but nothing obviously related to KSPCF.
×
×
  • Create New...