Gotmachine

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.

No. There are a few new modules like the inventory/cargo stuff, but they have near zero impact. That's not what I meant by "global overhead". What I meant is that for many methods, the exact same code seems to be executing slower in 1.12 than in 1.10.

These messages are "normal", and would happen in stock KSP too. This happen because all your mods are adding non-stock modules to stock crafts. This being said, the log entries should probably not be emitted as warnings.

I understand your point of view. I'd say that 20% is an absolute worst case scenario for a 650 parts vessel basically doing nothing in the least performance intensive situation. In more real-world performance heavy scenarios (atmospheric flight, active attitude control/engines, stuff running in the background, mods adding their own overhead, etc), that difference will become much lower and likely unnoticeable as the fixed overhead is dwarfed by other things that are just as heavy no matter the KSP version. In fact, I just tested a random craft file from KerbalX and got actually better FPS on 1.12 just because that ~500 part ship had a few converter parts, and those have perf issues on 1.10 but not on 1.12. I'm trying to think about what could be causing that global overhead. While the differences are measurable and consistent, there is always the possibility of some measurement bias, although I'm relatively confident in my methodology. Here are some compiled results : Hard to say what is at play here. Diffing some of the methods showing significant degradation, there are some methods where null checks against Unity objects were added, which can be somewhat expensive, but some methods are strictly identical between 1.12 and 1.10... But yeah, I need to do the same tests against other KSP versions Maybe. I guess the bulk of the overhead comes from the call to Part.isKerbalEVA(), which could be partially optimized. The above graph show other potential optimizations, like preventing SuspensionLoadBalancer to run when not landed,

That's a strong statement. It's extremely difficult to make reliable performance measurements between different runs without automated benchmarks that reproduce exactly the same configuration and sequence of inputs. This being said, I'm somewhat able to reproduce what you're seeing, although not as dramatic as the 27% FPS difference you're showing in your screenshot. Using your craft file, I can reliably measure a 4-5ms per frame overhead on KSP 1.12 vs 1.10 (for a frame time of ~45ms). In practice, this mean a 0 to 20% drop in terms of FPS, depending on the baseline. This can partly be explained by new features. With your craft, Part.FixedUpdate() call time has jumped from ~0.65 ms/frame to ~1.22 ms/frame due to the new kerbal mass system. There are likely a few other methods that increased in complexity slightly, resulting in some fixed overhead in newer KSP versions. More surprising, there is also a consistent and repeatable overhead (about 5% overall) in many top level method calls, including methods that haven't changed at all between KSP 1.10 and 1.12. I'm not sure how to explain this apart from some global regression at the Mono/Unity level when KSP was upgraded to Unity 2019.4.18 for the 1.12.0 update.

Thanks for the report. I managed to reproduce this on KSP 1.10, but not on 1.12, so this is caused by some differences in the stock robotic code between those versions. The RoboticsDrift patch is developed against KSP 1.12, I have a few other robotics related issue reports lying around, and I suspect at least some of them are caused by minor differences between KSP versions. I don't really have time (nor willingness) to investigate and fix such version-specific issues, so I will just disallow the patch to run on KSP versions prior to 1.12. The error you're getting is indeed caused by some mod uncorrectly managing resources, so "whatever adds this" is indeed the likely culprit. I would suggest finding which mod it is and asking on the forum thread for this mod, or to post in the "Technical Support (PC, modded installs)" forum, this has nothing to do with KSPCommunityFixes.

I encourage you to do so

Doing that will have the side effect of having KSP running from the wrong working directory. In stock KSP, the only likely side effect will be that the KSP.log file will be generated in the "PDLauncher" directory, but this will definitely cause cascading side effects on various mods. While you can specify a different executable in the Steam command line, you can't set the working directory, which is hardcoded to the "PDLauncher" directory. This being said, the proper workaround is to have Steam pointing at a shortcut instead of KSP_x64.exe : - Open your KSP root folder (In Steam, right click on the game > Browse local files). Usually this will be "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program". - Right-click on KSP_x64.exe > Create shortcut - Rename the shortcut to "KSP_x64_Steam" - In Steam, open the game properties, and in the "Launch Options" field, put the path to the shortcut between quote, with : "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command% This will launch the shortcut instead, with the correct working directory.

People are having that issue because they are trying to bypass the launcher by adding an extra command line option in steam to start a different executable than the launcher. This is what I have seen suggested : "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64.exe" %command% This doesn't work because the executable working directory will still be set to the "PDLauncher" subdirectory, causing cascading issues all around. A workaround is to make a shortcut to KSP_x64.exe, let's say I'm renaming it "KSP_x64_Steam". Then in the steam command line options, point to that shortcut : "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\KSP_x64_Steam" %command% This will launch the shortcut instead, with the correct working directory Said otherwise, the only issue here is people making a mess on their own by following random bad advice on the internet.

Good idea. I don't have the time or motivation to implement this, but suggestions are welcome nevertheless Well, don't have much time either. The few "kraken fighting" patches in KSPCF are far from a definitive or reliable fix. KSP will forever stay prone to such events, and there might be indeed corner cases where KSPCF is doing more harm than good. This being said, if you can reliably reproduce a case where the same craft has issues when the PartStartStability patch is enabled, and is working fine when the patch is disabled, please provide the craft or save file. Please try to reproduce this in a stock install. There is a large probability this is caused by a mod. And if you manage to reproduce it, please provide your Player.log file (see https://forum.kerbalspaceprogram.com/index.php?/topic/83212-how-to-get-support-read-first/) It is fixable with a mod, but it would be a behavior change that has a significant chance to affect other mods in unexpected ways, so KSPCF isn't the right place for that. Same response. KSPCF doesn't change stock behavior like this one to avoid messing with what other mods are expecting. This is something that you can and should handle from your own mod.

This data doesn't exists, not under a serialized (ConfigNode) form. KSP holds its data in various subsystems, most of it is easy to get from various static accessors or fields in singleton top level classes. For vessels (and everything they are made of) and bodies, you have FlightGlobals, for Kerbals you have KerbalRoster. Some other relevant top level classes are all subclasses of ScenarioModule, like ResearchAndDevelopment, ScenarioUpgradeableFacilities, Funding, Reputation, ContractSystem...

I'm just another modder. Lets just say that we have ways to see what is happening exactly under the hood.

It's quite simple. Part.buoyancy is the per-part equivalent of PhysicsGlobal.BuoyancyScalar (which you can tweak in Physics.cfg). In short, the formula for the magnitude of the force applied on a part by water is (physically "accurate" result derived from the drag cube and part mass) * PhysicsGlobal.BuoyancyScalar * Part.buoyancy. Default value for PhysicsGlobal.BuoyancyScalar is 1.2 (to account for the fact that stock parts are way too dense). Part.buoyancy default value is 1, and is sometimes tweaked up or down on stock parts to account for even sillier densities. In the context of rescaling a part, assuming both the drag cube and mass scaling are accurate, density is staying equal and nothing else is needed. Messing with Part.buoyancy mean that you're altering the part density, which is obviously wrong. I haven't read the whole convo in detail, but part.buoyancy set aside, if as @damerell suggested TS is only scaling the drag cube area and depth (and not size), it's no surprise that effective buoyancy results are inaccurate, as the formula make extensive use of the drag cube size. EDIT : to ensure a scaled part is keeping the same density, one can check the Part.partBuoyancy.displacement value. This is the intermediate result of the drag cube/mass computations before any "cheat" is applied (BuoyancyScalar/buoyancy), aka the "physically accurate" density of the part. Ideally, it should stay the same no matter the part scale.

Part.buoyancy is essentially a corrective factor applied over the part default buoyancy derived from the part estimated volume (itself derived from the drag cube) and mass. Said otherwise, it's a factor to do an arbitrary final adjustment of the part density in the context of the buoyancy formula, which mean it doesn't make any sense to scale it when a part is rescaled.

No responses because information is extremely scarce. We know they are using Unity, so yes, Mono is involved. They have no reason to use IL2CPP unless they really want to kill modding. We know that they have at least toyed a bit with Jobs/Burst for the new PQS system in combination with compute shaders (source). Maybe other parts of the game are using Jobs/Burst. It would make a lot of sense from a perf standpoint, but the fact they had to contract a freelancer to make it happen for the PQS system isn't a good sign. Other than that, they talked about config-driven modding with vague ideas for MM-like features and some limited config-level scripting capacity. This was a "it's all in flux" comment from three years ago, so don't hold your breath. If I were to speculate a bit, I'd say that the eventual performance optimizations (Burst, Jobs, GPGPU, multithreading...) and multiplayer feature are likely to increase the difficulty of making "complex" mods compared to KSP 1.

It isn't. It was fixed in KSP 1.12.3, you just need to update.

To get back to your original post (because I actually didn't really took the time to read it before) : the results you are getting make perfect sense to me. A +0.001 offset in true anomaly is absolutely not equal to 1s of orbital period, it's far, far more (something like 1400s), so of course you're getting a much larger movement. Also, if you followed what I said before, comparing the absolute position magnitude like you do doesn't make much sense because you don't know where the origin is.

I think we are lost in semantics. To me, "origin" is the 0,0,0 point, anything else is a reference point, not an origin. If your question is "are the positions returned by the various orbit methods consistent relative to each other and to a common reference point ?" the answer is yes. There are two different set of methods in the orbit class. Those prefixed with "Relative" return a vector expressing the position offset from the parent body position, but that vector is usually in a coordinate system where the y and z axis are swapped compared to world space. The non-prefixed ones return an absolute position in world space, where the origin / (0,0,0) point can be anywhere. No, for the methods that don't have "Relative" in their name, they return an absolute point in world space where the origin (0,0,0) point can be anywhere. If you want a vector from the parent body, you need to look at the "Relative" methods.

No. If you use one of the "AtUT" method, the body position is computed recursively relatively to it's parent body using keplerian orbit parameters and equations. There is no need for a known absolute point of reference.

@Razhan Sounds like it. Could someone create an issue with as much detail as possible (minimal repro steps, findings on what is happening...) on the KSPCF repository ?