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.

The tutorials voise reminds me a bit of the voice of Venti from Genshin Impact (male character, female english voice actor 30+), or a youtuber with a similar voice who creates Gensin Impact content. The voice doesn't have to be pitched, Paimon from Genshin Impact isn't pitched either (english voice), she can speak like that. In animes generally, children are spoken by adult women.

By means of a tractor beam that attracts everything that comes close to create the illusion of gravity.

Minmus is actually a hollow artificial satellite that uses ice as a camouflage and at the same time as a photovoltaic system by absorbing all heat energy that hits the surface and keeping the ice frozen.

Are the part modules implemented in a similar way to KSP1 or differently? The current implementation is unfortunately not the most efficient, and especially when mods increase part module count, it has a significant performance impact.

By the way, that's just Unity's old default. This can be changed in the project.

Editor or runtime? Game performance in the editor is always much slower than runtime build due to the editor overhead. There is also a difference whether the editor is in release mode or debug mode. For example, it makes no sense for level designers to run the editor in debug mode, this is only useful when debugging scripts.

With mordern Unity (Jobs + Burst + new Mesh API) shouldn't be a problem on the CPU either. I saw an example, a coin animation at 60 fps (in the editor) when a new mesh was created every frame with over 100,000 quads.

After Dyson Sphere is also build with Unity, like KSP, but different art style. Valheim is also build with Unity and both Valheim and Dyson Sphere Program has an Hightmap based terrain deformation system.

It certainly depends on the game, but the menu and controls are often different. Genshin impact also uses asset bundles for ingame updates (events). But what you have to consider from the beginning is the performance, if the game should also be playable on low end devices, it is better to develop it for this right from the start. Genshin impact is, in my opinion, a good example that it succeeded, and the visually most beautiful anime-style game on the market.

Theoretically possible. The game "Genshin impact", also made with Unity, gets updates every 6 weeks, simultaneously on all platforms (PC, IOS, Android, PS4, Switch) In practical terms, this only works if you develop the game for all platforms from the start.