runner78

Maybe KSP should introduce better save system like Save new save in a temporary file rename the old save file rename the new savefile to the targt name delete the old file. In this way, a complete loss of data should be avoided, since the old file is never changed directly. Some editors like WebStorm/PhpStorm do this, so far i know.

The new Magnetometer has a weight of 0.5 tons, isn't it a little too heavy?

https://www.comicsanscriminal.com/

The newer PhysiX has better multicore optimizations, but i don't the details and also has it's limits. KSP 2 need to chunk parts together as one physic body (or some other tricks), otherwise are high part count not possible.

I played with 1.8 and had also some stack overflows after a long game running. I don't played 1.9 yet. I was better then in the past, but there would still be room for improvements here.

So far i know, Unity run Physics on a seperate core, but the mainthread have to wait for it. Orbit calculation can be an bottleneck. I have played once without deleting debris, the performance got pretty bad after a while (only 30-40 debris, on a AMD Ryzen). After deleting it was back to "normal". I once testet simple orbits with DOTS, 200,000 small rocks, on 30fps (single precision). And orbit calculations are run always. My point here is: physics is the greatest bottleneck, but not the only one.

KSP is more then just rigid-body simulation. Don't forget orbital simulation, Sound, UI, Animations, Rendering (CPU part), Terrain, Aereodynamic and some other gamelogic. KSP 1 using camera stacking, that is also a large perfomance killer. I don't know is KSP 2 using Unity 2019.3 now, that have a PhsyX upgrade from version 3.4 to 4.1 https://blogs.unity3d.com/2019/10/22/physics-updates-in-unity-2019-3/

The Job system is a Tool, and developer need to learn how to use the tool. You can also use the Job system to run jobs with Burst on the main thread, for small jobs its faster as the overhead for the scheduling. On of the main advantage of the job system and multithreading in general is not only to process one task parallel on multiple core, but process different tasks at the same time. You can also split a task in small jobs with dependencies each other, and maybe some subparts can be parallelized. One thing that KSP can do well in a job would be e.g. orbital calculation. All vessels and debris are simulated in the background. And with Bust and SIMD optimization it could also very fast.

KSP use PhysX for the lokale physics (vessel) PhysX is Open source, and work on every CPU. GPU physics has the problem with the large CPU<->GPU communication overhead.To create a custom rigid-body physic engine is immposible for an indie gamestudio. Not even large AAA Studios. Most AAA Games using Havok.

One part of DOTS is Unity's Job system that uses all CPU cores and is already production ready for about 2 years. And the Bust compiler, that make the jobs at least so fast or faster as C++ code, is also relesed for a while now. I hope, they use it, it would be a waste of potential.

Right, as an example by default Unreal uses the same as Unity. Namely NVIDIA PhysX. So far i know Unity use a newer and faster version as Unreal. With Unity ECS it comes also 2 other Pyhsic engines, "Unity Physics" as default for ECS with and as an option to switch to Havok. Havok also develope the Unity Physics.

DOTS are C# job system, Burst and ECS, the first 2 are production ready and the ECS core are planned for Unity 2020.1. For Unity 2019.3 comming is close to production ready ECS core, and previews for animation, sound and multiplayer. During the Unite 2019 they presented a DOTS demo with animation, sound and multiplayer. KSP2 could using DOTS in some cases like orbit simulation (that does not use any physic engine) With an early ECS preview i have testet it with simple newton gavity, i have simulatet arount 200,000 visible objects at 30 fps.

Yes, that immediately free it, a garbage collector make no sense in this case. With .Dispose() the allocator knows the memory is no longer in use. A garbage collector check objects whether they are in use or not, that is expensive, not the clearing itself. The later part are to use different allocators for specific use cases. The concept of different custom allocators exists in C++ and often used in games.

No, there is no garbace collector in background. If you use the native collections, you must clean the memory yourself with the .Dispose() method. Unity give you errors if you forgot or choise the wrong allocator. https://www.youtube.com/watch?v=DDsRfbfnC_A&t=105s https://unity3d.com/book-of-the-dead

Tell them SQUAD to deactivate it for the next Update.

Unity has his own native collection like NativeArray and NativeList. This memory is managed by Unity native and has no garbage collection.

Some part of DOTS is already production ready (C# job system and Burst compiler), the ECS system should be production ready for Unity 2020.1. The next step is to update many Unity modules to DOTS. If KSP2 uses PhysX and has make some complex changes/hacks switch to DOTS would be difficult. A later update to DOTS would break all mods.

If no service active (by the game or some other parts/libraries) and Hardware stats is turned of, nothing should is send to unity's servers.

The DOTS approach is different from the old, but is very fast. The whole game to change would be too expensive and not all Unity components supporting it yet. But you can create hybrid games, using both approaches a the same time.

Also a tree branch are joined to the main branch, if you separate them, then you have cause a strange unpredictable behavior. Unity has with they new DOTS approach also Havok as physic engine available. If currently in preview, and should be production ready at the beginning of 2020. But i don't think KSP2 using DOTS (maybe for simulation only).

If you delete the analytics dll and the game running, that means, the game not using it while running. so deleting is unnecessary. If the Game use it actively, then the game link to the dll and use the API from this DLL in the game code. In this case the game can no longer start, is common sense. Analytics must be activate for the project, is not active by default.

With Unity's C# Job system and Burst compiler you can also create high-performance code with Unity, without Mono as bottleneck. For prepare and scheduling Mono is fast enough. And Unity has alo the IL2CPP build option, and create C++ code from the .NET IL code and the game no longer use Mono. But that is not modding friendly. Here some benchmarks: https://github.com/nxrighthere/BurstBenchmarks

If they us Unity's C# Job system, example for orbit calculations, then you benefit from many CPU cores.

Unreal Engine is NOT open source. In the EULA: "You are permitted to post snippets of Engine Code, up to 30 lines of code in length. online in public forums for the sole purpose of discussing the content of the snippet..."

For cosmetic weather / atmospheric effects, i think it's possible for KSP 2 have it already or they implementing it right now. Physical weather not come in the first KSP 2 release, but possible in future update. (Infos from some interviews)