runner78

The problem here is probably when pixel art fonts are not used in the font size for which they were designed.

integrated GPUs are still GPUs

One has to take into account that Unity is quite advanced in development since the beginning of KSP1. Some limitations do not exist anymore, and some limitations also arise from the inexperience of the developers. Unreal, however, is starting to get the problems unity used to have with its easy accessibility: many games with the same look. I just recently saw a video of an Unreal developer ranting about Unreal. More and more bad Unreal games are coming out. While it's easy to make "good-looking games" with unreal 5, that doesn't mean that this only applies to the trailers and that the game is then just bad or boring. he also ranting that unreal is becoming more and more complex and complicated with every update. I tried Unreal 5 times, apart from the huge installation size, between 40 and 110 GB depending on the components, I felt more comfortable with Unity.

You should also be able to set the version manually in the settings, according to SteamDB there is a public branch for the current version

UTC is not a time zone but the world time to which all time zones are based.

At the weekend I tried to create an experimental orbit scene in HDRP with realistic stars (HDRI skybox) but had quite a problem with the exposure, as soon as an object such as a planet was even slightly in sight, the whole scene was completely overexposed . However, I think that the move to HDRP is a bit late and maybe it should have been used from the start, or at least upgraded earlier in development since it's quite a hassle now.

I had the same problem once that I got into the map at enter "m" on saving in VAB, and once I had the problem that spacebar no longer triggered stagings. Had to restart the game and then it went back to normal.

It depends on what the time says. KSP1 shows the time like a calendar (our calendar has no year 0 by the way). Rather, KSP2 shows the elapsed time since the beginning of the campaign. That would then be 0 based since no year has passed.

After I saw this bug here in form for the first time, I thought, funny bug, 30 minutes later my space station crashed into VAB... in orbit.

I play with a 24" 1920, and I also find that some of the UI text is very small. After 1 or two hours I notice that my eyes are getting tired.

Unity's job system only has one worker thread per local CPU, and by the way it's a C++. The C# job system is just a wrapper over it. Unity also supports async/await, e.g. "async void Update()". For 2023.1, unity has also implemented its own Awaiter type that has less overhead and is then used for asyncone unity calls. Only crafts within your vicinity will be loaded, at least the visual/part-physics. All others craft no longer play a role when it comes to local physics. I've never heard of Update() or job being skipped. The thread is about burst not compiling a job, but that only means the C# JIT is executed as a fallback. The job is always executed.

But you need a GPU to display the Terminal.

You always need a GPU to see anything on a monitor at all. I hardly think you can play KSP via an SSH Terminal from another computer.

The MonoBehavior message methods are called onthe main thread, but it does not mean that you have to calculate everything in it. You can just plan in LateUpdate() an job, and use the result in the Update() on the next frame. Many API from Unity now have job support, e.g. RaycastCommand. I do not know exactly to what extent the phsix multihiltering model is used in unity, but even if you calculate two vehicles separately, as soon as they are close to each other, they must be calculated together again so that the collision detection works. KSP2 actually uses the job system and burst, but it is still surprising why, for example, the fuel System case som problems, I assume that you can the complete the work in jobs pro vessel/station, and is not dependent on Engine APIs.

I think you're not quite up to date, Unity itself uses a lot of multithreading on the engine side. Rendering uses its own thread, physics is actually multithreading so far i know. And with Unity's job system, a game developer can implement multithreading quite "easily" and is also used a lot internally by Unity. But physics is generally not particularly well suited for multithreading and has some limitation.