Settings data is getting screwed now and then when Switching to Map and back

[Lisias]

See #31 (comment) for details, while I don't find the mood to write a proper Issue 😝

[Lisias]

It's a pain in the arse, but for now the workaround for when the problem happens is to open DOE Settings and set the Minimum Significant Body Size to default (or the desired value) manually. Don't forget to hit "Apply" before closing the Dialog.

--- EDIT

Nope, this doesn't works ... See this Forum post

[kobe-maru]

When this bug happens, the targetColorScalar debug value also stops working when looking at the sun. It stays at 1.0 when looking at the sun and the skybox dims partially. It does still work when looking at the day side of the planet though, and goes to 0.0 as the skybox goes to black.

[Lisias]

Weird... On MacOS this appears not to happen. I spammed the "m" key repeatedly, trying to break something by forcing a scene change before the current one finishes settling up, but the behaviour never happened.

I will try again with Windows to see what I get.

It may not be something related to Windows or GPU, it may be something on CPU - I had some reports of weird issues that just happens on some kinds of CPUs (like that ones with different types of cores, the e-core and p-core thingies). If you had a e-core working in parallel with a p-core, you will have some threads running slower than others and Unity just wasn't made to handle this.

Theoretically, Windows would deactivate the e-cores as the p-cores gets traction and demands more power - but what happens on Scenes where the CPU is less demanded? Well, the CPU will back throttle and then the e-cores may be reactivated and then Unity starts to misbehave because the hard coded synchronizations that assumes all threads running a the same pace would fail...

Let me check your CPU in your logs from #31 ...

---- EDIT ----

OS: Windows 10  (10.0.0) 64bit
CPU: AMD Ryzen 9 7900X3D 12-Core Processor  (12)

https://www.amd.com/en/products/processors/desktops/ryzen/7000-series/amd-ryzen-9-7900x3d.html

Nope, this thing has 12 cores (24 threads), all cores the same. Perhaps it would deactivate some cores to maximize performance on some few ones as things get heat enough?

[Lisias]

@errolkokbas do you have the PBO enabled on BIOS?

I have word that on high thermal conditions, the Ryzen will deactivate one of the chiplets (it uses two, 6 cores on each). What means that once the thermals get under reasonable levels again, it will reactivate the other chiplet and you will have 12 working cores again.

If I'm right, the "solution" would be to avoid deactivation of one of the chiplets, so you will have consistently the same number of cores all the time.

I remember a environament variable called MONO_THREADS_PER_CPU used by Unity to determine how many threads it will fire up. If you have 12 CPUs, it will multiply 12 by the value found on this setting (or by the default value). If you have 12 cores, but then suddenly only 6 of them are working, then whatever is relying on this setting will get handicapped by half.

It's a WAY long shot, but it's the only thing I can imagine that may trigger a synchronization problem based on CPU's characteristics.

There must be a reason I can't reproduce the misbehaviour on my rigs (all of them, pretty older CPUs by the way).

[kobe-maru]

Nope, this thing has 12 cores (24 threads), all cores the same. Perhaps it would deactivate some cores to maximize performance on some few ones as things get heat enough?

Actually, I have AMD SMT turned off to improve single-core performance specifically for KSP. So my rig should always have twelve physical cores and twelve threads. I've only changed that and enabled the AMD EXPO ram overclocking profile in bios. I have not touched CPU voltages and done no over/underclocking on the cpu at all. My CPU is water cooled and rarely gets over 70C.

---

Also cross-posting from the ksp forums because they are becoming less reliable over time:

It's a pain in the arse, but for now the workaround for when the problem happens is to open DOE Settings and set the Minimum Significant Body Size to default (or the desired value) manually. Don't forget to hit "Apply" before closing the Dialog.

In my testing, this did not help, and some values that users can set Minimum Significant Body Size to will cause unexpected behaviors.

My work-around solution so far has been to reload my vessel after using the map. For some reason forcing the game to re-initialize the physics sphere and vessel fixes it. You can do it either by:

-quicksave and quickload
-selecting another vessel to switch to from the map screen, then switching back to your first vessel either with key-binds or the map screen
-going back to space center and then back to your vessel through the tracking station

[Lisias]

@errolkokbas

Actually, I have AMD SMT turned off to improve single-core performance specifically for KSP. I've only changed that and enabled the AMD EXPO ram overclocking profile in bios. I have not touched CPU voltages and done no over/underclocking on the cpu at all. My CPU is water cooled and rarely gets over 70C.

There's a way to now if the CPU had put some cores to sleep? And when it wakes them up?

What you described (here and on Forum) looks incredibly like code synchronization issues, and since I already know that Unity does internal synchronization by brute force, this is currently my best (because it's also the only) working theory, and it would help to rule it out ASAP if I'm wrong.

[kobe-maru]

I can try keeping my task manager with the resource monitor that shows core clock speeds over time graphs while running ksp, and I can also try re-enabling SMT so that it is a more stock setup....not sure how else to monitor cpu wake-state in real-time...

---

@Lisias Turned back on SMT, confirmed 24 threads in system monitor, tested; no change, Case 1. and 6. still breaking partially after going to map and back. Nothing remarkable happened on the 24 cpu system monitor graphs.

[Lisias]

@errolkokbas , please give RC4 from https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2 a try.

It's a blind (besides not exactly wild) guess, but it worths a shot.