Lisias

Are you using the latest release? I think I had fixed this here: https://github.com/net-lisias-ksp/DistantObject/issues/38 I will give this a peek before bedtime, but it will help to publish your current KSP.log (after reproducing the problem, and after quitting KSP to prevent the log from being truncated) it will surely help on the diagnosing. === == = POST EDIT I just fired up my "Acceptance" (acp ) test bed, where I have installed all the add'ons I publish on the latest releases, and... It's working for me. It was a pretty simple test (hey, I sleep now and then and I'm already done for today): Fired up KSP 1.12.5 (acp) Loaded the DOE's smoke test savegame Opened the DOE's Settings Dialog Set Show names on mousever to off (i.e., unticked the check box). It was On at that time. Pressed Apply Quit KSP Load it (again) Loaded the DOES's smoke test savegame (again) Opened the DOE's Settings Dialog (again) The Show names on mousever is still off. Just to be on the safe side, I also used the Tracking Station to jump into a living spacecraft and the option not only was still deactivated when I checked the Dialog, the feature itself wasn't active as expected. Activating the feature on the Settings made it work again, so the cycle is closed. So: there's something fishy in your rig; or your are using an old DOE's release (just checked SpaceDock and CurseForge, I confirm they have the latest); or there's something that you are not telling me on the bug report (perhaps a use case that I had messed up, and that wasn't tested by this simple test session I did). So please send me your KSP.log so I can check the options 1 and 2, and please describe step by step (like I did above) how to reproduce the problem, so we can rule out (or not) the option 3.

When you hit "stage" by accident... Poor cow. https://medium.com/@shermikeholmes88/the-time-we-accidentally-nuked-new-mexico-301489770be2

I fail to see how a Game Industry professional plans to enrich its resume by violating the EULA of a competitor (or former one, who knows nowadays). You know, their employer also has a EULA to enforce - and I really don't think such employer would be proud of their employees violating EULAs on the wild - their business model depends of EULAs being enforced! (or to hire someone that did that)

I'm playing this nice "little" game called Dome Keeper, suggestion from my son. Hard as hell initially, I took weeks until I finally got a grasp on it and started to win a round now and then. There're less demanding modes, as no enemies (essentially, digging without worries) and automatic weapons (that do the service by themselves, but you need to upgrade them or you will be overrun). But they are available only after completing a full cycle, damnit.

You know... Sooner or later someone will try to deploy Commandos with these things! ("Commandos away...." )

Proton is doing a pretty good job on simulating the Windows API nowadays, but I agree that Linux native is, most of the time, better. Problem is, as usual, Unity support.

Or pigeon bombs! (but with the pigeons replaced!). Way easier to train, but extremely hard to deploy... (could work to the japs, however...)

Crazy, almost desperate idea from WW2 era: doing MEDEVAC on pods mounted on the bomb mounts of a P-38. What could possibly go wrong? ("Bombs awa..." uh... Whoops.. ) (but it would be a hell of view!) https://aviationhumor.net/experimental-air-ambulance-version-of-the-p-38/

Never allow more than one ModuleManager to be present in your installment. Some older DLLs don't have enough meta-data to allow KSP 1.12.x (and only it, previous releases were a yet worst mess!) to try to figure out what to load. Being not bad enough, I have evidences that some rigs are prone to fire up more than one instance of MM at once when this happens, and you end up having race conditions on the patching - this really screws up things. This appears to victimize MM 4.2.3 in special because, in the majority of the situations where a doppelgänger is also running, the most evident problem is the Localization's patches being screwed (with nodes copied inside themselves, really a mess). I could only detect this one by eye balling the ConfigCache - a very tedious task... Since it's not feasible to determine in advance which DLL is safe to have as a doppelgänger and which is not, the safest and easiest way out of the mess is to avoid having more than one Module Manager DLL in your rig as it would be plague (what, in essence, ends up being sometimes). As a matter of fact, I'm diagnosing some complex installments and decided to install MM 4.1.4 and 4.2.3 at the same time to see what happens with the patching on KSP 1.12.5 (MacOS). This ended up allowing 4.1.4 to be ran instead of 4.2.3, as the following log excerpts demonstrates: [LOG 21:50:19.605] ******* Log Initiated for Kerbal Space Program - 1.12.5.3190 (OSXPlayer) en-us ******* Kerbal Space Program - 1.12.5.3190 (OSXPlayer) en-us <yada yada yada> ************************************************************************ Environment Info Unix 7FFFFFFFFFFFFFFF Args: KSP -crash-report-folder /Users/lisias/temp/ksp Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 Scale_Redist v1.0.0.0 / v2.5.0.62 ModuleManager v4.1.4.0 ModuleManager v4.1.4.0 <----- doppelgänger!!! <yada yada yada> [LOG 21:50:48.120] [ModuleManager] version 4.1.4.0 at /Users/lisias/Workspaces/KSP/runtime/1.12.5/GameData/ModuleManager.4.1.4.dll won the election against Version 4.1.4.0 /Users/lisias/Workspaces/KSP/runtime/1.12.5/GameData/ModuleManager.4.2.3.dll So, and assuming that you just installed things by unzipping the whole contents without removing unwanted things after (the most usual M.O. on userland), it's pretty unlikely that MM 4.2.3 would be causing any trouble for you, because 4.1.4 would be the one being run, perhaps twice (I never managed to reproduce this MM being run twice behaviour on my rig, it appears to be tied to some CPU models). So, in a nutshell, never, ever allow more than one Module Manager be present in your whole rig. === == = POST EDIT Well... I did this test: tried the GDLV3 stock craft on a test bed exactly like this one. In one test session, I used MM 4.2.3, and in another I used 4.1.4. In both cases, the ConfigCache generated were identical (compared char by char). There's no way MM 4.2.3 would caused the problem you depicted. In both cases, the image I got was: Whatever is happening on your rig, changing to MM 4.2.3 must be a coincidence. But, to be certain, I suggest you do what I did: Install MM 4.2.3 on this test bed. Delete ConfigCache. Fire it up, fly the GDLV3 and see what happens Rename the ModuleManager.ConfigCache to ModuleManager.ConfigCache.mm423. Remove MM 4.2.3, install 4.1.4. Fire it up, fly the GDLV3 and see what happens Rename the ModuleManager.ConfigCache to ModuleManager.ConfigCache.mm414. Compare both ConfigCache for differences. I think this may be related to VRAM (there are too many programs using video et all opened? On my old potato, I could not watch Youtube and play KSP at the same time!). Perhaps deleting the Settings.cfg and the PartDatabase.cfg (on the same place where the EXE file is) would help? If nothing helps, post your full KSP.log (quit KSP before copying the file, to prevent KSP from truncating it) after reproducing the problem again. I would like to see it to check if I find something on it that I recognize.

EL&P - Eternals.

"When the people want the impossible, only liars can satisfy." Thomas Sowell. Originally aimed to politicians but, boy, it's also perfect for Software,

So, it's bad to have too many issues opened in a repository. Ok, I can accept that. So let's hire more people to tackle the issues down, right? No! Let's create a bot that will automatically close all the issues after a week!!! What could possibly go wrong?

"That's a Bingo!" @AlamoVampire in on the house?

As someone that "been there, done that"... Videocassetes had a way better noise/signal ratio, and we could save our programs using it faster and with more reliability than using audio cassettes.

There's always someone going the Kerbal way on everything!! A racing car with AIR BRAKES! (and the turbo intake on the pilot's left ear!) https://uopshadowicons.com/product/can-am-shadow-special-edition-package/ https://www.instagram.com/goodwoodrrc/reel/C5wSkAfIzMv/