Gotmachine

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.

This sentence, my friends, is the best summary of the 40k+ posts in the KSP 2 subforums. Sorry for the interruption, could not resist. Keep going.

I don't think OP said anything about random part failures, but about part reliability. Part operational lifetime limits is to unmanned missions what life support is to manned mission, a way to introduce mission time as a gameplay element, they go hand to hand to build a game mechanism introducing both more depth and more realism to a contemporary spaceflight, more real life grounded playstyle. KSP is a relatively casual, goofy rocket and orbital mechanics game. That doesn't mean there isn't any room for something else in the subgenre.

I guess the piece of code you're showing is just for testing purposes, but you can't do what you're doing from a KSPAddon, because FlightGlobals.ActiveVessel will change when switching vessel, docking, undocking, etc You need to either use a VesselModule, or alternatively to manage you callback registrations by pooling the active vessel list (technically you can also use GameEvents, but there are many corner case to handle with that approach).

Nobody has a source on that. But RSS and RO are in the top 10 downloaded mods on CKAN. "Real rockets" part mods like BDB and Tantares are also hugely popular. System rescale mods or larger system scale mods like JNSQ or KSRSS, quite popular too. "Simulation" mods like TAC-LS or Kerbalism are also still quite sought after, despite being essentially abandoned. If you look at KSP youtube videos produced and views or discord servers populations, you can see that there is quite some interest for "more simulation". Yes, there is definitely a greater potential playerbase for a more casual game, that's exactely what I said. But it can't be so easily dismissed that a large part of the success of KSP is due to the enthusiasm and dedication of the hardcore space nerds. Beside, the Orbiter comparison is irrelevant. Orbiter is a simulation, not a game. I never said KSP 2 shouldn't be a game, just that it could have had more real-world and contemporary scope. Anyway, the point is that I just wanted to expand on OP statement : You're definitely not alone.

I've been saying this since the start. An interstellar scope KSP fundamentally changes the granularity of the simulation and of the game, there is no way around that. I think it's a good move for making the game a large commercial success. A less directly exposed simulation with more gamey mechanics featuring shiny science-fiction stuff is what attracts crowds, and if the devs did the job at least half right, it will definitely be fun to play. But there is a relatively large proportion of the KSP1 playerbase that are here for the "simulation" side. The KSP franchise is the only game that provide a relatively decent spaceflight/rocket simulation, and a lot of people are here because they are spaceflight nerds, not because they want to play a space game. Now, objectively, stock KSP 1 doesn't offer much on that front, but if you look closely at the modding community, a large proportion of it is about real world, historic and contemporary era spaceflight. And there is a lot of interest for real world constraints like more realistic system scale and overall part balance (including real world rockets/missions), and simulation-leaning implementations of features like fuel boiloff, tank ullage, thrust limits, engine ignitions, components reliability, life support, radiation, ISRU, comms, science, etc. To a lot of long time KSP 1 players having used mods extensively, the feeling of stock gameplay is that you're playing with toy rockets in a toy system. And that aside of the delta-v equation and orbital mechanics, you're not really facing any of the "real" challenges of spaceflight. And for those players, stock KSP 2 won't offer anything more than stock KSP 1, apart from a (welcome) technical/graphical upgrade. Time will tell, but long term I'm relatively confident that a segregationist "de-interstellarized" KSP 2 modding ecosystem leaning toward contemporary spaceflight will emerge. Speaking for myself, I think they could have made KSP 2 a slightly more simulation leaning game than KSP 1 without that interstellar scope and it would still have been a success. A world setting a la "The Expanse" with a slightly more realistically scaled system and featuring more planets, moons, comets and asteroids would have been very appealing to a lot of people, I think. But well, other stars and sci-fi colonies we shall have. To me, it seems early on they got quite stuck in the "we must keep/reuse everything that exists in KSP 1" safe zone. At least they dumped science/career mode.

I won't go into that pointless debate. Low level modern C# is just as fast as low level modern C++. High level "usual" C# code tend to be slower than equivalent "usual" C++ code because the BCL abstractions are much higher level and offer handy features like automatic exception handling, managed memory and some level of thread safety. If you choose to deliberately to get ride of those high level features (which you can in modern .NET), C# code becomes again in same ballpark as C++. Edit : actually, did you look at the results on the GH repo you linked ? The fastest C# implementation (very low level) is 34% faster than the fastest C++ implementation. The "normal" C# implementation ("tannergooding") is twice slower. Which kinda illustrate my point nicely. I suspect that a middle-ground C# implementation not resorting to unsafe code but using .NET6/7 low level constructs would be roughly equivalent as C++.

Nope. CLR and CoreCLR aren't and never were interpreters. Only Mono has (had ?) an (optional) interpreter, which isn't used in Unity. They fully compile the whole application on startup, with the downside being a vastly increased start delay. Which is why stuff like NGen or NativeAOT existed, and why CoreCLR has introduced tiered compilation where jitting is initially done with a minimal amount of work done on optimizations to get quick app startup, then it takes some times to do some deeper analysis and re-jit identified hot paths. The compact framework JIT is a bit different and does on-demand jitting, not compiling stuff until it actually used. The micro framework JIT however is an interpreter, but it's almost a completely separate product. Nope. Unity has forever been using Mono.

Nope, Unity uses (a custom fork of) Mono on all platforms. And IL2CPP performs very marginally better than Mono in terms of execution speed. The main reason it exists is because it allow Unity games to run on platforms where JIT VMs aren't allowed (namely iOS), but it also has the advantage of producing a smaller distribution and using slightly less memory (because it strips unused BCL classes and doesn't need the JIT VM), which is relevant on mobile platforms in general. CIL is not statically interpreted. That's not how the JIT works. It is compiled to assembly when the application start. Which means that technically, you can get as much performance from C# as in C or C++. C# in practice is (slightly) slower than equivalent C++ code because of the overhead of the high level constructs of the BCL and of the GC. But at least on modern CoreCLR, if you desire so you can get quite close to the metal with the most low level C# constructs and get similar performance as C/C++.

I'm quite skeptical. For that to work, you also have to create bindings for all types used as a parameter or return type, and consequently bindings for the methods in those types too. That mean a huge proportion of the BCL and Unity API surface. In a way or another, you have a ton of work to do if you want to expose a vaguely useful LUA modding API. While we have zero confirmation that LUA modding exists, we have a lot of confirmation that C# modding exists, and there is technically no way to do such sandboxing if they allow C# modding. And frankly, if they try, it would be a deal-breaker and a major failure on their "KSP 2 will be at least as moddable as KSP 1" statement. I can guarantee you that the first thing the modding community would do is to move on to BepInEx or similar and build it's own C# based no strings attached modding ecosystem. By definition, modding doesn't want to limit itself to what the developer has made. If you read carefully what was reported by Snark in 2019, I think the likely scenario is quite clear : embedded LUA scripts in config files in order to be able to define custom logic within the scope of the configured subsystem and its specific functionality. This seems like a very sensible choice to me, but extending that to a general purpose modding API that cover the full KSP (and consequently BCL & Unity) API surface seems a total waste of resources for very questionable benefits. Hu, what ? C# is compiled to machine assembly, it's not interpreted on the fly. Lua can either use a static interpreter reading byte code, or be compiled to machine assembly too. Either way, in practice, Lua mods would be much slower than C# mods. Not so much because it is intrinsically slower (which it is), but mainly because of the overhead of calling into the C# API while mutating the methods parameters on every call. The overhead here would be very significant.

This is a lot of extrapolation. So, yeah, this just confirms that those LUA bindings still existed in february and are still used for internal developments. For reference, this is the only source we have (it's actually from 2019) : I see very little incentive for them to put together a whole user facing LUA-based modding API and framework, when thanks to the game being an Unity game they basically get full modding support for "free". What I realistically envision is some level of LUA embedding for specific configuration files use cases. Being able to have a fully functional programming language at the config files level can be very useful in some situations. There are many KSP 1 mods that provide in one form or another some level of logic embedding in config files (ModuleManager and ContractConfigurator for example). But anything is possible. Indeed, if they already have most of the LUA bindings they (we) need already in place and have used them in production for some final configuration systems, the gap to a LUA based modding framework might not be that much extreme, although the API coverage needed to be able to do anything useful is quite huge. It doesn't only need to cover the KSP API, but also large chunks of the Unity API. A LUA modding framework would maybe somewhat lower the perceived barrier of entry to modding (although if this is actually good is debatable). There are some possible benefits like hot-loading (to be fair that's also possible with C#), but there are many downsides. Beside API coverage limitations, LUA is slow, it's a very barebone language with a very barebone standard library. My opinion is that it would make modding harder, not easier, and without putting words in others mouth, I doubt any serious KSP 1 modder would disagree on that. Overall, my feeling is that this is a lot of work for the game devs and not that much benefits for the modders. As a modder, if I were to choose what I want, I'd rather have a good built-in CKAN/ModuleManager than a redundant LUA modding API. Don't get me wrong, having a scripting language with good API coverage would be an interesting feature. It would basically mean that KSP 2 has a built-in KOS, or at least something quite close from it, and that opens up a lot of possibilities if the LUA system itself is correctly exposed from the C# API.

Nothing was ever confirmed regarding LUA modding. All we know is early 2020 tidbits from one random guy on the KSP 2 team. Who was saying that they had experimental LUA bindings on top of the C# API used in the context of some internal prototyping tools, which may or may not be used in the final product.

RP-1 has it's own persistent rotation feature and is incompatible with PR. but is supposed to disable itself in the presence of PR.