runner78

Maybe some modders create an craft-converter.

Yes and no, Unity has IL2CPP, that converts IL-code to C++. Was designed for devices where no JIT is allowed. It exists also as option for Desktop, but Mod-support will be difficult. Unity's Burst compiler create machine code AOT (JIT in development) for C# Jobs.

One of the problem with N-Body is probably the timewrap. With simple on body orbit, you can calculate the position of the object for any time. With n-body this will not longer work. With height timewrap, the orbits will by unstable due to calculation inaccuracies. I doubt it exists a way to calculate n-body with fast forward on a mid-range consumer PC.

Regarding quantity of new games, Unity is the market leader (50%, according to Unity, worldwide an all platforms) So its natural that a large amount of this game are bad and poorly developed, and that pushes the image of Unity down. So Unity work on the promise "performance by default" with DOTS (Data-Oriented Technology Stack) But don't underestimate bad developers, they can also create bad games with the best engine.

Oh yes, NASA required that, i think the original design was without. I don't now, if this controls used in normal operations.

Not always, Burst using LLVM/Clang to create aggressively optimized machine code from the IL code, in some cases it can be better optimized, as would be possible with normal C/C++ compiler.

16 bit float or the "half" type: where accurate calculations are not necessary and speed is more important (but depends on the CPU or GPU). Often used in deep learning. 32 bit float or the "single"/"float" type: mostly used in games and most graphics Cards can do that best. With positioning, the problems starts with 10 KM from origin (10000 units). Eeloo Apoapsis 1135497132 KM (1135497132200 units) 64 bit float or the "double" type: for accurate calculations and biger numbers, normal consumer GPU's are bad with doubles, newer used for rendering. 128+ bit floats: some GPU/GPU using larger floats for intermediate values, but mostly used only in science. Unity HDRP use camera centered rendering, that means an the GPU the camera is always the origin, but that not change the scene/physics origin. Unity has also an new math library which has double vectors, and supported by the Burst compiler for job, i seen a NBody brenchmark, Bust are 140% faster then normal mono, and 60% faster then C++;

Some ISS Pictures, i see chromatic aberrations. https://images.app.goo.gl/u7Wjf4Wa6nHsPqyQ9

Orion in the atmosphere: G-force kill all Kerbals G-force destroyed the vessel Shockwaves burn all grounds along the lower fly path EMP destroyed all electronic on the continent. radioactive fallout make Kerbin uninhabitable Really kerbal-like

I need something like Kerbal alarm clock in stock. It' easy to forget planed maneuvers with many active flights. Or hard to planing launch windows without helpers. Maybe as part in the progression mode.

When I saw the video, I immediately thought, that will now go around as a new KSP UI... SpaceX crew Dragon has no physical instruments, not even physical controls, only touch screen monitors. And for Airplanes, as newer the model, the less physical instruments.

Its a Techdemo, but shows what is possible with Unity: https://www.youtube.com/watch?v=34K8YJOMDRY

Here are better images: The Image comes from here:

Correct me if I'm wrong, but so far i know, Blueprints are quite slow.... I don't now you can convert Bluprints to C++ also for Mods, but then you need compile it separately for each Platform (Windows, Linux, MacOS) Look at pictures of modern cockpits, real navballs are also flat.

About multithreading in Unity and .NET: If you use the default Task/Thread from .NET, normaly the OS or the Runtime manage on which core a Thread run. Starting Thread has some overhead, newer .NET versions has the Task (in KSP 1 < 1.8 not available), who use a threadpool and with async/await you can easier write multithreading code. But switchiing context (task to mainthread) and Garbage collection make this approach not suitable for perfomance criticial game code. Unity has with the C# job system his own multithreading solution, specially designed for games. Unity starts one Backgroundthread on each logical core (1 core reserved for the maintread) and schedule jobs. And with the Burst compiler they compile the jobs with LLVM/Clang to optimized machine code.

Physics is difficult for multithreading in most cases, specially the vessels in KSP, you need the results from the previous calculations, so you can't calculate in parallel. Unity using NVIDIA PhysX for Physics, Unity has no direct influence on performance here.

The main Problem with Unity is: easy to use => many crap Games => has a bad reputation as it deserves Unity has evolved a lot in recent years and continues to evolve: The new 2 Renderpipelines (URP/LWRP and HDRP), one for better look, the other for better performance (i wonder is KSP 2 using it?) C# Job system and Burst compiler for high performance multithread code without Garbage collection and in some cases faster als normal C++ (i hope KSP 2 using it!!) Future: ECS System (Entity Component System), a new data oriented approach instead of object oriented with a high performance boost (core API could come out of the preview this year, KSP 2 could using it for some internal simulation stuff) For what possible with grafics in Unity look at: https://www.youtube.com/watch?v=34K8YJOMDRY For what possible with Performance in Unity look at (using ECS): https://www.youtube.com/watch?v=KgcU2HBOXAw