Gotmachine

Well, in that respect, it's a total failure. While the overall UI takes a ton of screen real estate, many critical elements (text, icons) are tiny and barely readable. When you want to make an UI that work for all uses cases, you make it as uniform and space efficient as possible so it can be globally scaled up and down.

Yes, in an ideal world, KSP 2 would have a proper mod manager that define and handle packaging, semver, dependencies, metadata, etc. My little finger tells me we aren't in that world, and that we better handle all this by ourself. As for using an external / community maintained modding toolset / modloader / injector, there are several benefits at doing so, regardless of if the game if using the Mono or Il2CPP backend. But frankly, I don't see how they could possible have made the "KSP 2 will be more moddable than KSP 1" statement if the game is using IL2CPP. I know that personally, that would probably kill all motivation for me to develop mods for KSP 2.

Nope, that couldn't be further away from reality. I can say with 99% confidence now that KSP 2 is using the Unity vanilla PhysX joints implementation. Why so confident ? Because the floppy joints is a well known intrinsic limitation of that implementation, and all you can do is "spam more joints" workarounds, which KSP 1 does in two variants : - For stack nodes connections, it actually create multiple joints, usually 3 joints put 120° apart on a circle centered on the node. - Autostruts This is also what the KJR mod does. KJR is basically just a smarter and fully automatic autostrut implementation, spamming additional joints using some heuristics based on connected parts mass. The point is that floppy joints as they exist in KSP 1 and now KSP 2 are not a game design choice and never were. They are the result of using a physic engine that isn't designed to handle what KSP is trying to do with it, and that decision itself is the result of not enough skill/resources to implement an alternative.

We don't need anything from the devs to start modding KSP 2. There is a quite dynamic community and toolset ecosystem allowing to extensively mod any Unity game. The most popular/advanced of these tools is BepinEx. In fact, I would argue that given how overwhelmed Intercept seems to be with trying to put the game together, they should probably let the modding community handle everything on their own.

I'm excited about KSP 2 being a new thing !

@king of nowhereYou're missing the Harmony dependency.

KSP.log needed.

Nope. Managed exceptions happening in the UnityEngine.MonoBehaviour "message" methods (Awake, Start, FixedUpdate, Update, etc) are always catched. Same for the PartModule major virtual methods (OnAwake, OnStart, OnFixedUpdate, OnUpdate, etc), each individual call is wrapped in a try/catch block. Said otherwise, triggering an exception in those methods will only affect the problematic call, all subsequent calls on other objects will run as usual.

@R-T-B Moving the MapSO and ScatterDistribution patches to Kopernicus seems a sensible approach indeed. The ROCValidationOOR patch isn't Kopernicus specific, the stock bug can affect anyone defining custom ROC scatters, so it make sense to keep it in KSPCF. This being said, you could probably duplicate it in Kopernicus to avoid the KSPCF dependency, and disable either the KSPCF or Kopernicus patch when both mods are present. Let me know when/if you're doing that, but in any case I will probably wait a few months before removing the MapSO and ScatterDistribution patches from KSPCF, we can't really rely on people keeping both mods up-to-date immediately.

@DrKerbalMDThanks for reporting. This should be fixed in release 1.24.6 It's a bug, but this has no consequences in stock, and the KSPCF patch is causing the terrain to generate slightly differently at the poles on all stock bodies (not only Moho). For people installing KSPCF and having already landed stuff there, this is likely to wreak havoc. Technically, the stock bug is only an issue for planetary system modders wanting the terrain to generate as defined in their heightmaps, so my opinion is that the whole thing should be handled by Kopernicus. There is also the issue that the methods being patched are hot paths from a performance standpoint and the simple fact that KSPCF is patching them has a (small) effect on performance for no good reason for all players that don't have Kopernicus. Things are what they are and trying to revert the patch in KSPCF to move it to Kopernius is gonna be more trouble than anything, both for me, R-T-B and end users, so things are staying as they are. But this should serve as a reminder that KSPCF mission statement is to fix stock issues and that modded KSP issues should be handled by the mod in question, to avoid situations like this. The cases where a modding related patch make sense to be included in KSPCF are when : - The patch is at very low risk of altering the stock API behavior. - The patch can benefit to multiple mods, so implementing it in KSPCF prevent multiple mods to be fighting over its implementation.

KSP doesn't handle anything related to your monitor refresh rate. There are several software layers in between. Some driver settings will take precedence over the in-game settings. This being said, your issue is likely that the NVidia driver is configured to use GSync or adaptive sync , but somehow your monitor doesn't handle it correctly. Framerate in KSP does indeed jump all over the place because of various issues but mainly because it's a single-thread CPU bound game, and your Ryzen 9 5900HX isn't exactly shining on that front, far from it. The solution is likely to just disable GSync/Adaptative sync in the NVidia driver for KSP.

You don't need mods for that, you can just adjust the "science rewards" % setting in the stock difficulty settings.

New release : Kerbalism 3.17 for KSP 1.8.x to 1.12.x Fixed issue #811 : MP transferred to jetpack when going on EVA is not registered correctly (@gotmachine) Fixed issue #500 : Process dump settings aren't handled/persisted correctly (also fix #337 and #834) (@gotmachine) Fixed issue #833 : Ensure VesselData can always be created even if ProtoVessel is null (@gotmachine) Fixed issue #845 : Make isSerenityGroundController persistent to prevent loosing comms when vessel type is changed manually (@gotmachine) Tweaked automatic DataRateDampingExponent calculations so result in stock is ~6, matching original value in Kerbalism 3.14 (@gotmachine) Performance tweak : Prevent PartModule PAW update code from running when PAW isn't shown, provide very significant perf gains (-0.7ms / frame on a basic space station) (@gotmachine) Added stock cargo part support for Kerbalism parts (@OnlyLightMatters) SSPX support : Added greenhouse to aquaculture-375-1, changed cupola-greenhouse-125-1 from 1/90 to 1/6 of kerbalism greenhouse (@DangerNoodle9000) SSPX support : Tweaked analysis speed of some labs (@DangerNoodle9000) US2 support : Added support for sabatier reactor (@DangerNoodle9000) Science : Added back automatic conversion of all modded labs to the Kerbalism version (see issue #762) (@DangerNoodle9000) Added body/biome localization in a few additional places (@tinygrox) Improved zh-cn localization (@tinygrox) Improved ru localization (@deVDem) Added partial fr-fr localization (@vinix38) Thanks to @R-T-B for triggering my will to work on all this

@Vl3dSo... the issue is mainly that the Station Science mod is half implementing features that are half implemented in KSP itself. The PersistentIConfigNode KSPCF patch is providing an implementation for those missing stock features, but since the mod doesn't implement them correctly, things go quite wrong. To fix this, you can disable the PersistentIConfigNode patch, take a look at the KSPCommunityFixes\Extras\KSPCF_UserSettings.cfg.extra file for how to to that. This being said, while the station mod is the root cause, KSPCF should probably handle such errors more gracefully.

Could you provide the full KSP.log ?

Okay, should be fixed in KSPCF 1.24.2

Ok, I managed to reproduce the issue. I won't have a lot of time to investigate in the following days, but this is caused by the FastLoader patch, and it actually cause drag cubes in general to be semi-randomly wrongly generated. Specifically, this happen on all parts having multiple drag cubes defined, this include parachutes, but also animated parts such as the inflatable heatshield, deployable antennas, landing gears, etc. The FastLoader patch alter the part compilation to decouple it from framerate, but it seems some part of the drag cube computations actually require a frame to skipped. I suspect what require a frame skip is setting the part animation at the desired position for each drag cube, but it might be an issue with the aero texture not being updated immediately, this require further investigation. The reason it's semi-random is likely because the FastLoader patch still skip a frame occasionally to maintain ~30 FPS while loading. I'm opening a github issue to track this, will try to push a fix ASAP.

@rmaineThanks for the details. Still can't reproduce this, although I don't have a fresh KSP install on hand, will try again tomorrow. Do you have the DLCs installed ? This being said, this sounds like a config loading/parsing issue. The effective diameter as shown in the VAB is derived from the drag cube, and the FastLoader patch does alter the code path used in drag cube calculations while loading, so maybe there is something wrong there. Not sure this will help, but after reproducing the issue, could you open the PartDatabase.cfg file at the root of your KSP install and find the "parachuteSingle" block, then post it here ? Mine looks like this : PART { url = Squad/Parts/Utility/parachuteMk1/parachuteMk1/parachuteSingle DRAG_CUBE { cube = PACKED, 0.1571,0.656,0.4137, 0.1571,0.6565,0.4137, 0.2765,0.6425,0.3861, 0.2765,0.8648,0.1765, 0.1614,0.6568,0.6308, 0.1614,0.6703,0.669, 6.735E-06,0.1034,0.01848, 0.6307,0.3626,0.6124 cube = SEMIDEPLOYED, 7.477,0.2766,0.5834, 7.477,0.2766,0.5834, 0.5275,1.225,4.172, 0.5275,1.125,14.99, 7.54,0.276,0.5646, 7.54,0.2741,0.5325, 6.557E-07,8.838,1.147E-05, 0.826,17.83,0.821 cube = DEPLOYED, 72.79,7.57,4.943, 72.79,7.569,4.943, 52.78,8.574,4.172, 52.78,6.536,14.99, 73.5,7.494,4.551, 73.5,7.492,4.551, 6.676E-06,8.838,0.0001245, 8.26,17.83,8.21 } }

I can't reproduce this, tried a bunch of times in various configurations. Please provide exact reproduction steps. Assuming you're talking about the VAB part list tooltip, I don't see that either. The ChutePhantomSymmetry patch is quite simple and straightforward, I'm a bit skeptical it can cause such issues. Also, note that you don't need to downgrade to disable a specific patch, you can disable it with a config switch (take a look at the KSPCF_UserSettings.cfg.extra file for instructions).

Yes. 100% of the memory leaks are caused by issues in the KSP codebase, this has nothing to do with Unity. And most of those issues are either incompetence (like wrong usage of a finalizer) or just trivial mistakes. Either way they would have been quite easy to fix if someone decided to spend a few hours using some proper tools to diagnose them. And even if they didn't fix every case, they could have implemented some basic safety mechanisms that would have prevented 99% of the memory leaks, both in stock and in mods. This one was on Unity/Mono, and was mostly fixed with the 1.8 update when they upgraded to Unity 2017 and its incremental garbage collector. This being said, apart from a few specific issues, KSP is decently optimized in terms of GC pressure. The bulk of that issue has always been caused by mods.

There are massive memory leak issues in vanilla. See https://github.com/KSPModdingLibs/KSPCommunityFixes/issues/49

There is definitely a bug where a chute placed in symmetry is staged for deployment at the same time as the decoupler removing that symmetry. This will cause the chute to think it still used in symmetry, which combined with the "spread angle" setting will reduce the parachute drag. The effect is quite visible, the chutes will stay at an angle out of nowhere. Pretty sure this can't happen if the chutes aren't in a symmetry group. Will try to make a fix for next release.

I definitely don't have the background or experience to make definite statement like you do. I'm aware that PhysX 4 isn't capable of guaranteeing limits and drives in RB chains, but I'm relatively confident that neither are its competitors because it's not a flaw, it's still an inherent caracteristic of those solvers. I will take your word that the situation is so much better in other engines than PhysX, but yeah, KSP is a use case where you have a 50 kg docking port in-between two 500t chains, so that will never work well. My point is that the main issue here is a game design one. KSP 1 has jointed RB defined-by-function parts because that was the only sane way to make it happen in Unity in 2015 for a near-solo dev, and while I can't ignore that it bring some "fun factor", the only way to make it work functionally is to actually make joints near unbreakable and with absurdly high stiffness drives, to a point where those joints might as well be merged RBs. There is no user-facing "tweak the rocket structural strength" feature or gameplay, the knobs are all internal, and even if they weren't, they wouldn't make any sense to the player, because they don't make any sense from a physics standpoint either. With a bit of work, they could have built a hybrid approach, maybe with some soft-body solution, which would have been very appealing as it could be a common base implentation for the aerodynamic and thermal simulation. But, well, this wouldn't sell as much copies as interstellar gimmicks.

You are focusing a lot on collisions and spatial queries, but this is absolutely not a bottleneck even in KSP 1. The only perf issue is RB joints. Given that ECS is barely out of experimental as we are speaking, I doubt KSP 2 is using anything beside a few specific Burst/Jobs implementations for a handful of subsystems, but maybe we will be surprised. The very likely scenario is that KSP 2 is using exactely the same implementation as KSP 1 as far as RB physics are concerned, with a slightly smarter "spam RB joints to avoid spring rockets" system and likely some "optimizations" like merging parts as a single RB or making inactive stuff kinematic. Again, the mistake here is to try to use PhysX RBs for something they can't do. Using Havoc or DOTS physics wouldn't change anything, as they all implement a lagrange multiplier solver that fundamentally can't guarantee that joint limits and drives won't be violated, and are simply not suited for long joint chains with highly variable RB mass ratios. And on a side note, PhysX also has a reduced coordinates solver, which is actually more suited for this kind of stuff. And it would not be that much of an effort to implement all RB physics stuff in a C++ library written on top of PhysX instead of relying on the Unity default wrapper/API. Time will tell soon, but while I'm relatively optimistic that KSP 2 will be a better foundation than KSP 1, there are many hints that despite what was said, a lot of the core implementations were initially copypasted from KSP 1 without much analysis on if those implementations made sense in the first place. On many aspects, I'm expecting a KSP 1 2.0, not a KSP 2 1.0.

Spatial queries and Rigidbody simulation is far from being the main bottleneck in KSP. And PhysX is actually decently multithreaded. There are definitely some inefficiencies both on the Unity side, which doesn't expose some very useful parts of the PhysX API, but mainly on the KSP implementation side. But all in all, RB and collider physics are objectively the most optimized part of KSP, taking 15-20% of the frame time in part count constrained scenarios. The single-thread bottleneck has no main culprit, it's a combination of an inadequate general architecture and of tons of tiny or not so tiny inefficiencies in all subsystems. This being said, the main issue with physics in KSP is that a solver primarily made to simulate ragdoll physics is wholly inadequate for the task of simulating a rocket structural integrity. And it can even be argued that the idea of simulating structural integrity out of RBs whose shape and mass is primarily defined by function is a silly idea in the first place.