Lisias

Don't know if the thing flies, but … Damn! https://www.rbth.com/lifestyle/327929-pimp-my-ride-russia-best-cars

That is pretty odd. The Player.log just stops abruptly, without a stack dump or even a error message. So all we can do is to guess. Find and remove all directories (and contents) called @thumbs. There's a known bug on KSP that makes it to crash when a thumb image file is damage. If by doing this the problem persists, consider verifying the game's integrity if you are using Steam, or re-download it if using other shop. But, again, I'm wild guessing - I have no clue about what's happening on your rig...

Welcome! And since we are here, kudos for @TheDarkBadger, @MOARdVand @Rubber Ducky for keeping it alive before me! Cheers! If I have seen further it is by standing on the shoulders of Giants. Newton, Issac

Are you using Waterfall? KSPIE deactivates scaling engines when WaterFall is installed, because there's a glitch on the TweakScaleCompanion that handles Waterfall that reverts the plumes to default scale if you do a Revert to Launch.

Yes. There's the quick&dirty way, and the proper one. The Q&D is to install All Tweak. It's a bit hacky, but it works most of the time. Be aware, however, that sometimes a part will misbehave terribly by using All Tweak, it's highly recommended that you keep updated backups of your savegames when using it. It's pretty rare to tell you the true, but it happens - some PartModules need special code in order to be safely scaled up and down by TweakScale and since you as an end user can't tell in advance if the Part is using one of that PartModules, the best option is to be pessimistic and keep backups. The proper way is to write a proper tailored patches for it. I added a task for it on the respective Companion: https://github.com/TweakScale/Companion_Rockets/issues/5 Keep an eye on the TweakScale Companion Program'sThread for news:

ANNOUNCE Release 2.1.1.12 is available for downloading, with the following changes: "Dumb mistakes fixed" edition. Closes issues: #34 Hundreds of errors in KSP.log #25 Rework the Settings. #14 Disabling "changeSkybox" non functional #1 Support ReStock! I'm proud and embarrassed at the same time on releasing 2.1.1.12 with some way late fixes for some known problems, being the most visible (pun not intended) the ReStock one. TL;DR: I fixed a lot of mistakes, bad decisions or plain stupidities of mine (yeah, I have my bad moments too). On a side note, I had already said it before and I need to say it again: supporting ReStock is essentially supporting Stock the right way™, and I will try to remember that in the future. See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. The reason is that I'm working this weekend (again), and I will not have too much time to do proper support. So I will probably update CF Saturday night (assuming nothing blows up in day job), and SpaceDock by Sunday night I think...

This sounds like music to my ears!

This singer only got better as time passed by, excellent music! Tiffany, Waste Of Time.

VesselDraw is the part of DOE that draws vessels that are on Rails and normally not drawn by KSP. This option is normally off: if you never used DOE before, it's already off for you. If you had installed DOE before and somehow activated it, open the DOE's Settings and uncheck the Vessel Draw checkbox: A (more or less) proper walkthrough can be found here: https://github.com/net-lisias-ksp/DistantObject/discussions/35

Problem with ReStock is the (relatively) new PartModules that are fooling DOE into not using them. DOE uses the PartModules present on the Part to infer how it should draw the part. Has the Mesh some animation? Lights? That stuff. When ReStock waved known PartModules, DOE lost the information it needs to know what to do with the mesh. Well, I think I had dragged my feet on this issue long enough. An interesting situation happened on Day Job and this ended up opening a small window for fooling around, let's see if I can get this fixed today. https://github.com/net-lisias-ksp/DistantObject/issues/1 — — POST EDIT — — Humm… I'm not understanding why some parts are not being displayed anymore since the first time DOE worked fine with ReStock of that time. This is going to need some R&D first…. — — POST POST EDIT — — Oukey, embarrassing news. TL;DR: @Rutabaga22, you can use DOE with ReStock, but if you have TweakScale installed, you will need to turn VesselDraw off due some glitch on the Mesh Engine for TweakScale that it's screwing up the ReStock parts - or at least, is what my today's test sessions suggested (see the issue I linked above). It's not a surprise I couldn't find the problem before, as I was looking on the wrong place. The thingy that are in need to be updated is the Mesh Engine for TweakScale.

Contention caused by memory access is serious stuff! (WHY SO SERIOUS? ) A similar situation happened in the old MS-DOS days, before the Era of the PCI. The first commercially successful 32 bits expansion bus was VLB (Vesa Local Bus), beating IBM's EISA to the ground on shame (EISA was better, but IBM was being IBM and the hardware guys flipped the bird to them). That cards were essentially ISA cards with extended connectors to the 32 bits extensions - pretty clumsy. Programs that only knew how to access video using the legacy frame buffer would have terrible performances as the ISA bus not only was 16 bits wide, as also have the clock downed to ~8 MHz, as it was the clock of the first 286 to have 16 bits ISA slots and it became Standard (I managed to overclock the ISA to 12Mhz - more and some cards would fail). To cope with this terrible bus, games usually rendered the screen on CPU's RAM and then did a memcpy to the framebuffer as it was found that this minimized the losses - better to handle the bottleneck only once than on every time you poke a byte there. When using the 32 bits frambuffer , things were obviously lightning fast, with a 32 bits access under a clock of 16, 25, 33, 40 or even 50 MHz, depending of the Processor's Front Side Bus. Funny fact: with a clock or 40 or 50 MHz, VLB was theoretically faster than PCI that used a 33Mhz clock! Anyway. VLB was sensibly expensivier for some time so few games gave support to it, but the ones that did, boy what a difference. They could access the frame buffer almost the same speed they access main memory (there's still some contention because the DAC need to run continuously the frame buffer to send 60 images per second through the VGA port). What we get here is pretty similar. By not using the ReBAR stunt, OpenGL ends up having to do things in a similar way as we had to do on the old ISA days [edit] when handling dynamic textures. Obviously, this would not be a problem if game developers weren't handling all textures as dynamic, as it appears to be happening nowadays - but people do what people do, similar things happened in the past and they will happen again. I will give it a try, but I'm not holding my breath. My problem is a terrible GPU (Intel 4000) and my performance problems are due VRAM exhaustion when the GPU driver borrows CPU's RAM for textures and so every time something is textured things have to go thought the bus bottleneck. By trimming down the DDS textures to civilized sizes, even KSP 1.12.5 is giving acceptable FPS [edit] on my Mac Potato. But... it will be interesting to see what happens.

If I understood correctly, the "problem" is how Textures are handled nowadays. Originally, the Textures would be sent to the GPU and "forgotten" there, unless they would be dynamic textures, where the texture would be kept on the CPU domain for being manipulated and then "committed" to the GPU to be used. This forces you to have two copies of the dynamic texture: one on CPU's memory and another on the GPU's - not to mention the bandwidth needed to update the GPU's copy as needed. Nowadays, the new GPUs are being designed to allow "transparent" VRAM sharing to the CPU (using that PCIE-BAR stunt). Unless the VRAM is dual port, it will lead to contention when the CPU tries to access the VRAM block when the GPU is in need of it, but it usually is way better than allowing the GPU doing it on the CPU's RAM, or to keep copies of everything on the CPU's RAM and updating the VRAM's copy as it changes. This stunt (mapping the while VRAM on the CPU's address space and unifying the Dynamic Textures) is implemented on DirectX, but AFAIK not on OpenGL. I think Vulkan implements it, so there's still hope for KSP2 on Linux (if it will be ever ported). Additionally… KSP's textures are all upscaled to 4K nowadays (including on KSP1), and this makes things even harsher on UNIX machines - I'm on MacOS, and yeah, I'm screwed by this stunt too...

NOTAM To anyone that could be interested, this is how TweakScale was licensed over the years: Originally licensed under CC-BY-NC-SA, it was relicensed to WTPL in 2015. Biotronic's post explaining it Biotronic's TweakScale OP with the WTFPL license stated. Pellinor published it also under WTPL, see his thread's OP. I originally kept the WTFPL, but due uncontrolled copies being published by 3rd Parties (screwing my life doing Support), I changed it to GPLv2 on TweakScale 2.4.4.0 in December 2020 with an Shared Source style license offered as alternative if the end user could not use GPLv2 by some reason. https://github.com/TweakScale/TweakScale/discussions/298

There's no such thing as too much wheels!!!!

Boy, what a collection of exceptions! With or without VAB, you surely will experience some glitches while playing... I noticed that you entered the Settings page and back, but there's no mention on trying to entering the EDIT (VAB or SPH) - for the curious, "Scene Change" from MainMenu to Settings, and back. So or you did forget to try (unlikely), or the thing is deactivated (or not activated) by KSP's code by some reason and then your clicks on it were bluntly ignored. We will need to hunt the dirty way: make a full copy of your KSP installation (and I strongly suggest you do a full copy and do the stunt only on the copy, as it's a destructive process) and start to remove things until you get access to the Editor. Once you get access to it, redo a new copy and remove only the last thing you removed on the previous copy to be sure about who is the troublemaker. Given the messages I found in your KSP.log, I suggest removing: FreeIVA Impossible Innovations Bluedog_DB SpaceY Tantares TantaresSAF Keep in mind that doing this you may find a trigger and not the cause - it may be something that all of that parts needs that are screwed so just removing the offended partset is not enough (there's too much different things broken, and these things are known to work in other people's rigs!). Good hunt! I'm currently unable to check it on MacOS because they ditched Mojave, and I kinda "trapped" into Mojave due some 32 bits programs I still need to use. I will some tests on my Windows rig as time allows. My best guess is that you may have installed 2.4.6.2 manually sometime in the past, and then CF stopped updating the thing - but it's a wild guess. This will probably render a bug report on the CurseForge bug track.

I remember a bork of mine preventing crafts from being saved, but preventing entering the VAB is a new. Post the full KSP.log (remember to exit KSP to prevent it from being truncated) after reproducing the problem and I will check. At very least, I will be able to pinpoint you to who ask for support if not me.

Hi! Such a high number of FATALities are almost for sure a symptom of having TweakScale installed multiple times, and in you case it was exactly what happened: [LOG 06:40:14.776] Applying update GameData/TweakScale-2.4.7.1-CurseForge (1)/TweakScale/patches/Squad/Propulsion/@PART[noseConeAdapter]:NEEDS[Squad,TweakScale] to Squad/Parts/Aero/cones/noseConeAdapter.cfg/PART[noseConeAdapter] [LOG 06:40:19.230] Applying update TweakScale/patches/Squad/Aero/@PART[noseCone]:NEEDS[Squad,TweakScale] to Squad/Parts/Aero/aerodynamicNoseCone/aerodynamicNoseCone.cfg/PART[noseCone] Remove the directory GameData/TweakScale-2.4.7.1-CurseForge (1) and you will be fine! Additionally, I found this Exception on your log: [LOG 19:27:48.948] [TweakScaleCompanion.Frameworks] Version 0.2.0.0 /L BETA [EXC 19:27:48.958] TypeLoadException: Could not resolve type with token 01000029 (from typeref, class/assembly Finder, ) TweakScaleCompanion.Frameworks.Startup.Start () (at <61373f5e28644a2d9623e47ceccc0688>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) The TSCo Frameworks is at this moment at version 0.4.0.1 , and you will need this newer version to work on TweakScale 2.4.7 series. I suggest to downloading the latest TweakScale Companion Überpaket. How about giving the CurseForge Installer a try? It would work out these details for you!

You see, that ship has sailed. The news I have is that a lot of management people were fired recently on PD . https://www.rockpapershotgun.com/take-two-confirm-layoffs-affecting-private-division-despite-exponential-growth-in-recent-years So whoever will answer the phone on the other side, will know Squad squat** about what you would be talking about. On the other hand, the new guys would be more prone to listening to you as they weren't the ones that created the mess at the same time they are the ones that will profit by fixing the mess - assuming the mess is fixable, of course. Keep this in mind if you manage to talk to them: this is the best opportunity to earn their hearts, don't push them against the wall!

The OST from this magnificent Movie came to my mind today while reading some posts here on Forum. Beautiful music.

Al Jaffee, MAD cartoonist, passed away at 102 last April 10. (image source)

So do I, and yet I usually appreciate people trying to explain things to others, even when I'm aware of the subject because: 1) people willing to explain things in a good and interesting way are rare. We should incentive the practice. 2) you don't walk around with your Resume hung in your neck, and people don't walk around with Crystal Balls hung in their necks neither. We just can't foresee what you know or not. 3) this is not a private message to you. You are not the only addressee on the message. Most people here are not old farts like you and me, and they will make good use of the information! That said, please note that I'm not doing any judgment of value about you, please take this post on the most amicable way possible. Be well.

You were bitten by a long standing internal bug on a thingy called Assembly Loader/Resolver inside KSP: when something fails to be loaded (due a missing dependency, or the DLL being corrupted or similar things), that ALR screws something inside it and from that point anything trying to load something, or to use another thing called Reflection, start to bork relentlessly no matter what. What we need to do is to find who is the trigger of the problem in your rig, and once it's fixed everything else just works as expected (including TweakScale). In your case, you have a problem on versioning! KSPe.Light.TweakScale v2.4.0.4 Scale v2.4.6.2 TweakScaleCompanion_Frameworks v0.2.0.0 Waterfall v0.0.0.0 TweakScalerWaterfallFX v0.2.0.0 The current TweakScale version is 2.4.7.1, but you are using 2.4.6.2, a pretty old release. So old that TweakScale Companion for FrameWorks is not being able to use it! [LOG 18:45:49.145] [KSPe.Binder] Looking for TweakScalerWaterfallFXIntegrator.dll on GameData\TweakScaleCompanion\Frameworks\Waterfall\.\PluginData\... [LOG 18:45:49.145] [KSPe.Binder] Found it on GameData\TweakScaleCompanion\Frameworks\Waterfall\.\PluginData\TweakScalerWaterfallFXIntegrator.dll. [EXC 18:45:49.173] MethodAccessException: Method `TweakScaleCompanion.Frameworks.Log.force(string,object[])' is inaccessible from method `TweakScaleCompanion.Frameworks.Waterfall .Startup.Start()' TweakScaleCompanion.Frameworks.Waterfall.Startup.Start () (at <00cc8c66dfac41b999a3e65c52711d89>:0) System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Glo balization.CultureInfo culture) (at <9577ac7a62ef43179789031239ba8798>:0) <....> Please update TweakScale to 2.4.7.1, or you will not be able to use the Companions (not to mention a lot of fixes and improvements made over the years - 2.4.6.2 is really, really old!)

padding memory doesn't really solve the problem - only delay it, making things worse when finally the memory needs to be collected, but ended up not being collected due the high CPU load. It may be useful for recording a video for youtube or twitch, but for general gaming sessions it will probably bite you in the long run… Welcome to the club! Do you want to seat? You are going to stay for while…

As a matter of fact, not that much. The problem is Unity . Someone on Unity thought it would be a good idea to shove busy waits (euphemistically called "spin-locks" nowadays) everywhere, and these busy waits are eating CPU as they were candy. Since the Garbage Collector relied on sparing CPU time to do deep memory collecting, the net result is the GC never doing it. Try to set an environment variable called MONO_THREADS_PER_CPU to 1 and see if things get better. Check this thread for the gory details:

It's a wild guess, but last time I got this, it was a thumbs failing to be loaded. Find and delete all @thumbs directories on your KSP installation. With a bit of luck, this will solve it.