Lisias

You see, this is another very nice Use Case that could be handled by PDLauncher if done right - checking for the need of trimming the environment for KSP, without the user needing to understand such shenanigans. That's the catch - this one is Unity's fault. Unity decided to do something absolutely nasty and stupid while handling some tasks (HID input surely is one of them), and they did it in such a way that the more cores you have, worst become the problem. By reducing the number of threads per core you reduce the damage Unity is doing. Common Sense would tell you that this would make your KSP run slower, as there will be less threads available to do KSP business, but Unity had screwed up things do badly, but SO BADLY, that by reducing the number of threads per CPU we reduce the damage caused by Unity, and this more than compensate for any benefit multithreading would give us. My CPU runs 2 or 3ºC cooler, and KSP runs faster on my MacKrap using this stunt (not to mention the whole machine running smoother - I can now watch a Youtube video while playing KSP on my multi-headed setup, something I wasn't able since 1.8.0 when they switched to Unity 2019, when this crap started). Essentially, all gamers using notebooks probably would need to use this (the MONO_THREADS_PER_CPU stunt), if not for any reason than to keep thermals under control, helping to prevent thermal throttle down. It's interesting to note that other games using Unity 2019 are affected as well, and this stunt is working for them too. This rules out any possibility of being KSP's fault - it's 110% innocent on this one. As far as I could check (pending confirmation), 1.12.4 really only fixed the tutorials (the difference on the download size when switching versions on Steam is only 200K). All the trouble is coming (directly or indirectly) from PDLauncher.

This was already diagnosed, and a pull request was issued, however never merged.

My bad. See this post for the full story: but TL;DR, create an environment variable "MONO_THREADS_PER_CPU", set it to 1 and run KSP. On Windows this is pretty messy, but on MacOS and Linux you can use your .bashrc profile file to set it, or just do as I did on this image: You may be interested on this another one, currently (eternal) work in progress: Of course, closing the PDLauncher after firing up KSP will also help! Use the task switcher, kill it, then go back to the game.

But it would be the approach I would do, because I don't know all the math I need to know to identify the problem by eye-balling, neither know the code enough to know where to eye-ball the damned thing! You see, the point is that you don't need highly skilled professionals to detect (and sometimes fix) some bugs (even on complex systems). You can replace skills with raw power (and some extra time). A highly skilled professional will always be more efficient, no doubt. But not necessarily the cheaper choice. Working with people is complicated. Working alone is, almost always, way "easier" - but most of the tasks of nowadays development are too big to be handled by a single dude, and so we end up working on teams, where everything is more complicated. One of the worst problems on working on teams bigger than 3 or 4 dudes is the Chain of Responsibility. When the team became bigger enough to prevent that every dude is able to know and understand what the others are doing, you have an opportunity to hide problems or let others to be blamed for problems you had caused. This leads to a growing bugtrack that ends up eating all the time available, stealing man-hours from the new features - and the money are on the new-features. Buggy code was already sold (it was the bugs were discovered at first place), so management rarely see them as a way to expand the incoming. New features, on the other hand, is how management is able to sell more copies of the product. And I hate to tell you: they are not exactly wrong. Check the Steam Charts for the peaks of users online, and you will find that most of the time, there was a new KSP release at that week. We don't have access to the sells chart (obviously), but it's reasonable to assume that these peaks on users online has a relation to more KSP copies being sold. And so we reach the dreadful Bug Priorization: since there's no time to fix the bugs and also deliver the new release, someone gives a priority on each bug, and so the team scrambles to fix the bugs ordered by priority. If someone gives a really annoying bug a low priority, it will be essentially not fixed until the end of the project when no new features are left to be added. But since at this point the sellings are usually stalling, there will be no money left for developers, and so we have a bug that will never be fixed. Bug Priorization is a Lost Art, I can tell you. On complex systems it's usual que a very underestimated bug ends up being the root cause of a lot of higher profile ones - to the point that fixing that Kraken damned small bug would fix by side effect a lot of nasty, user's SAS bitting ones. However, it's pretty rare to have people skilled and experienced enough available to do such priorization (not to mention that the dude must have a good knowledge about the whole code to identify such relationships). They are essentially the same thing, see my previous paragraph. Companies don't write code to brag about their coding skills, they write code to earn money. If they find that they can earn money writing bad code and walk, then bad code is what they will write. I'm prone to agree with you on a higher level that you think. BUT… "management" is a too broad concept, we have low, middle and high management, and the problem can be happening on any of these levels. It's the reason I'm cautious on talking about. However… I had learnt something on my PMI times (yeah, I had tried my way on the Dark Side of the Force - got burnt, by the way, Darth Vader level of burnt): "Good Managers don't work for Bad Managers, but Bad Managers can end up working for Good Managers - for some time". What's probably the explanation for the other saying I learnt: "A players hire A players; B players hire C players". What's also explains why you rarely find A players on big corporations - people on big corps don't hire people that can overshadow them, it's not on their best interest. You care about the product. Most people only care about getting paid. With as little effort as possible, by the way. Use a Spoiler (the Eye icon on the toolbar, below the "Font"). It's what I did on my previous paragraph! On mobiles, this button is usually hidden. Switch the phone into landscape position (wider than taller), and the extra space will allow it to be shown.

Me and my big mouth. Let me check the previous posts, so I can estimate how badly I will shoot our collective feet... These are somewhat complex calculations, and the one that will be on charge on fixing them would need to understand what the code should do, and then check what the code is doing instead. The code part is, indeed, not that hard - the worst part is to find where the problem is, and to do that, the dude would need to know the math needed and also the code. If this feature was working fine before, and suddenly stopped working, then one way out of the mess is to determine exactly the commit that got it screwed - access to the full history for the source code is, so, mandatory. A first step is to determine the very last public release with the feature working, and then walking up the commits from that point until it get screwed. Then a diff between the screwing commit and the previous one will fatally pinpoint the problem. Level of difficulty on the first method: hard . But it will probably be the faster one if you get capable workforce. Disclaimer: I'm not, I don't know all the math it's needed. Level of difficulty on the second, brute force method: trivial. But it will take a lot of man-hours - it's essentially a binary tree search where a node visit is a full compiling and then running the thing and look for the problem. This is what I would do, probably... It depends of how many people were working on the project at that time. Do you know the saying "9 pregnant women won't give you a baby a month for 9 months"? If you had a very few experts on the field, then they will probably get things right (or almost) at first time. The hard time is finding these huge experts on the field, then manage to lure them into working on a small software shop - no to mention having the money to pay the dudes. There's a reason you don't find NASA engineers working on small Marketing shops, right? But let's pretend for a moment that a NASA engineer decided to code KSP in 2012, instead of a crazy Brazilian dude that decided to go the masochist way : as soon as the game starts to get traction and the work starts to pile up beyound the capacity of the initial workforce, fatally new people will get hired to help them. And these people will not be NASA engineers, as these dudes are not easily available on the market. Now things start to get hairy, because the initial dude is not working on the code anymore, he's trying to teach the newcomers about how he had done things. Development slows for some time - what's rarely well received by whom is paying the extra money on the new hirings, they wants results faster. Probably some of the newcomers would be more experienced coders, but almost surely less experienced Space Engineers - and so, knowing most programmers of nowadays as I do, I'm pretty sure that old crappy code that was working fine were replaced by new, very well written code - but done by a dude that didn't know how to solve the problem himself and, so, will not realise when he/she does a mistake on the algorithm. (on a side note: I prefer to emphasise solid interfaces than solid code - give me solid interfaces, and the code crappyness is not a problem anymore, it can be replaced anytime without screwing up dependencies!) Now we have pressure to make things faster, as now the stakeholders are spending more money and they want the investment back as soon as possible (the dreadful "Time to Market" race). You have newcomers with more experience on coding replacing the "crappy code" but without enough knowledge about the problem being solved, and so without being aware of eventual mistakes being done. And new features being shoved on the backlog while the clock ticks. Do you get the picture? Having something done quickly and right is almost impossible unless you have top notch professionals all the way down. Given how KSP was incepted and how it was developed over time, I think it would be pretty hard to have things right at first. But once the team gets cohesion and motivation, they are able to rework the problems pretty fast after some time - as long they don't get burnt on the process. "Cheap. Fast. Good. Pick two." Yes, but not a fatal one. Usually is easier to isolate bad code under a solid interface, and then develop the new features around the interface. Good Software is pretty much alike good hardware: you don't need to replace your car's transmission if you need to replace the car's brakes, do you? Spaghetti code becomes a serious problem when people adds new features over it, instead of adding new features around it. Easier saying than doing, no doubt: but there's a reason good developers are highly paid, right? Let me tell you a history that I had lived on the days I was working on embedded systems: we were working on a considerably complex product, we were a team of 5 and we have a lot of code from different vendors to stitch together. There were good code but written for a different system, there were absolutely terrible code written for the same system, and there wasn't enough of us to rewrite everything. Sounds familiar? How we managed to survive the mess? By writting wrappers. We defined a framework in which we would develop our product - and this framework, indeed, took a lot of work from all the team to get done right. We took months on it, and we only managed to accomplish that because the Manager had a solid background on development himself and agreed that the solution was solid - but hell, we took a lot of heat due the lack of "results" for a lot of time. Once the framework got ready, we wrote a Facade around every 3rd party code - essentially shelling code around our interfaces, writing code to convert things when needed. Some CPU were wasted on these conversions, and again some heat because CPU resources are usually limited on embedded systems - but, again, we got lucky because the hardware were over dimensioned for the task and we have some fat to burn. The only time we got screwed was when the Top Brass, worried about how slow were were developing the thing, decided to "help" by hiring contractors to accelerate the deliveries. It was not totally bad, the knowledge of the contractor effectively helped on some issues - but the dude was being paid by task, not time spent, and so he did things the faster he could - taking shortcuts over our framework and doing direct calls inside the components instead of using our public interfaces. Guess what? We lost months of development rewriting a good part of the code he wrote, not because the code was bad (some of it was, but if the thing works, then it works!), but because he didn't follow up our interfaces and made calls to things that wasn't meant to be called outside their contexts, completely screwing up the stacks of the threads and halting the whole system. At the same time, one of my colleagues, besides being a very good electrical engineer, was (frankly) a bad coder. But he did everything by the book, and almost none of his code was flagged with bugs. Hell, I was a way better coder than him, he reached me for help on the programming language now and then - and yet my bugtrack's size was twice of him's. (he had a better understanding of the hardware than me!!!) Well, after this wall of text, I think you must get caught the picture: Spaghetti code can be a hindrance or a problem - it's how the team copes with the code that decides which one. Well… Let's be careful on this one. There were capable professionals on the team, no doubt. Some more experienced, some rookies, some nice guys, some sas-moholes, the usual stuff as always. In a way or another there were good things being implemented, we can't say that the all the features were crap - not at all. IMHO what we had was some critical bugs pilling up without being fixed, to a point in which all the very good stuff being added could not be appreciated by the users. Why these bugs pilled up must be the key to answer your question. However, I don't know the facts I need to know to give you a answer for it. What I know is that it's possible to have a terribly incompetent team formed by very competent individuals - as well to have an incredibly productive team formed by rookies. You can save or doom a team by adding or removing a single dude... Most of the time, management is the key for the success of a Team, but it's premature (and probably unfair) to just blame management for all the problems - at least, without more information. And I, definitively, don't have much... Given the results we have nowadays, it's clear that the Team had failed on delivering the results expected from them. Lack of skills can be one reason for that, but my guess is that it was not the only one - perhaps not even the main reason. If I would make a bet, I would bet that over-confidence played a bigger role than the lack of skills. Some features should not had been allowed to be published at the state they were. Hell, some KSP releases had config files with merging problems (to the point I had written a lint tool for the config files) - at least this one is not about skills, I can tell you.

Yes, but with reserves - the focus is on making the existing parts working again. So this is not too different from what I have on KAX now. It's better than nothing, but barely…

That would be a shoot on my foot. There're things I can try on KAX for R&D that I can't on AP.

Damn. You blew up my surprise… It's on the backlog, but I was keeping it in secret. (to tell you the true, for some time I was trying to decide if I would put it on KAX or AP, due the date it was created - more or less the cutoff date I had set for KAX, but since it was asked here, so in AP it will be!). The main problem is reworking the meshes. Meshes made for FireSpitter have a internal structure different from the ones made for Stock. KSP Wheels is on my sight, Kerbal Foundries I didn't checked yet. Ideally I want to avoid forcing the user to download many different add'ons to do something that it was able to do before with only one, but things are the way they are. I have absolutely no problem on adding support for 3rd parties PartModules later, if it adds value to the parts. It's the trend I'm going on KAX, by the way. I'm working on patches to allow the user to use FS if available, or Stock if FS is not available. Of course, the engines will behave well better with FS but, as I said, it will be user's decision about what's better for him. I'm getting some help on "reverse engineering" some parts, once we have one part of each type migrated, all the others became "grunt work" and this I can do on meshes. So I hope things will work a bit faster on this holidays. Humm… I completely forgot about this one. This is the problem on expending too much time coding and too few effectively playing the game. I will give this a peek. I know. But the FSCoolant works better on propeller engines than Stock - I'm bashing my SAS the whole year (as time allows, RL™ is being a Sun on the Beach for me this year…), and I'm just can't get a satisfiable overheating model for the new D-45 engine. The RL™ counter part, Pratt&Whitney R-4360 Major Wasp, have terrible heating issues that I managed to reproduce on the game - but using FSCoolant made it easier to accomplish. As a matter of fact, I'm thinking on going this lane exactly due KSP2. It's uncertain when it will be available for Mac and Linux, not to mention when if will be available at all. And I'm not going back to Windows on this life. I think KSP1 still have some juice, and I'm going to probe some ideas on it before trying them on KSP2 - assuming I'll ever migrate to KSP2, as this is, at this point, highly uncertain. Being completely frank on the matter, looking on the Steam Charts and the huge amount of problems I detected in the last few years… I would trade the current KSP1 for the one made by the amateurs any time. My worst problems (by a mile) where the ones created on recent team's tenure. If you have the patience (and the will) to check the immense historic of bugs on my github, you will find that except by one (the auto-struts problem), every single other nasty and hairy problem I had to cope with was created after KSP 1.4.0 — I really don't know where the problem laid, my perception is that (at least most of) the developers were capable professionals. Clearly, something didn't worked as expected, and whoever was the one in charge of the development, failed on detecting the trend before it had grown too big to be reverted. I'm not telling you the previous team would not wake up in the morning with burning ears - hell, they would (I have a big mouth, after all). But as far as I understand, the Life Cycle breakage and the memory problems (to stay on the more evident problems I detected) started on KSP 1.4.0 and later. KSP 1.3.1 and 1.2.2 worked beautifully on all my rigs (older or new) and, in the end of the day, this is all that matters for the die hard users that used to love the game.

More about the early 2000 CGI than for the music, I enjoy more the videoclip than the song itself!

Reproduce the problem, then quit KSP, then publish your KSP.log and also the Player.log using Dropbox or similar service. Let's see if it's a software bit failing inside KSP.

Nope. I had rolled back to 1.12.3 and then rolled forward again to 1.23.4, and Steam only had to download about 200K of data to do so (granted, 200K of compacted data, I'm guessing about 1 or 2 megabytes unpacked). But by doing that, you are waving the Steam Integration, and for some people this is a serious no-no . Users with a single monitor setup make use of the Steam Integration to chat while playing (well, more or less, they need to pause he game - but you got it). You also lose the Steam Cloud features, etc. It's not only about launching the game, it's about losing Steam features - that I don't use myself neither, but some users do - and, so, they have a compelling reason to try to get rid of the PDLauncher and have things back as they were before. I can't blame them for trying. Well, I ended up doing it (for obvious reasons :P) but not too much - I see their point.

The PDLauncher's depot was added to almost all KSP's packages. So it is being installed on every KSP Steam installs on your rig, and not only for 1.12.4 . I have reports of people using KSP 1.12.3 trying to get rid of it. I will eventually check if it will be installed too on older KSPs as 1.7.3. It was downloaded and installed on MacOS by the way, besides it's not being configured to be used by Steam and I'm not being able to run it manually (and I tried, something about donet not being able to run .EXE Assemblies, only DLLs I think). And I find this slightly hairy. This is not limited to KSP 1.12.4, this is potentially being applied to every KSP user (pending confirmation, I have hard evidences only for 1.12.3 until this moment).

Constantly backup your savegames, just in case. B9PS doesn't complain just because, it usually has a reason for doing that (as TS does, by the way). You may have a ticking bomb planted on your GameData waiting for the opportunity to blow up (been there, done that - pretty embarrassing, by the way… ). Welcome! R.U.D. safe!!!

IMHO, the only problem was the absolute absence of a way to do not use it. I see why PD found value on it, I see where they want to go and I think they are not wrong. I think the problem is that they missed an interesting opportunity here: to add value to the user too. Had they added some compelling feature to the users, and most people would probably still complain about it (people do what people do, we love complaining! ) but fewer people would had tried to get rid of it. One of such features is auto-settings. With so many years of experience stored on this Forum, they have the means of creating a component that would analyse the user's machine, and propose (and auto implement, with rollback!) changes on the settings.cfg. Lower textures, less details on the 3d models, simple terrain, delta physics, etc. It's a pain in the SAS to get this right for people not using top notch machines (max everything out and you are done). Not to mention that you need to load the game first, and if you are on an overload machine, it will be a pain. Having an external tool to do that would improve things considerably, and a lot of people would embrace the Launcher if it would do this for them. We need someone there thinking on a Win-Win Negotiation mindset: "oukey, I want users to use this, and I know why I want them to use this. But how can I make this appealing for them in exchange?". And, of course, offer an option to go back to the older ways for die hard old-farts like me that like to do things low-level - I don't even install KSP by Steam Client anymore, I have bash scripts that build test beds automatically using DepotDownload (yeah, I'm have issues, I know). On a side note, the PDLauncher is remaining in memory when KSP runs, taxing the GPU's VRAM. People with modest hardware that were able to play the game now are getting screwed up by lagging due VRAM exhaustion (what makes the GPU driver to store textures on the CPU's land, where things are some orders of magnitude slower to access). And this is a compelling reason to do not use the PDLancher even with nicer user features added: it shrinks the current user base, shrinking potential revenues. Please consider this, PD. A bad standard is better than no standard at all. It's usually better to everybody err together than everybody trying to do the right thing by themselves. Imagine a foreign neighbourhood where people walks on the left side of the sidewalks because this is what they do on their homeland. Okey, they are "wrong" but what's best - to walk on the left side with them when you need to cross that neighbourhood, or to insist on doing the "right" thing and disrupting the flow? Same thing on KSP - I tend to do what KSP is doing and err together. There's no point on "doing the right thing" if KSP is not doing it. So if it is working for KSP right now, it will work for me too. And if KSP don't do the 'right thing' on something , it may have a reason for doing so, and it's usually safer to follow suit. (since I didn't worked on it on the development time, I don't know if there's a reason for KSP doing things this way - perhaps working around a bug on Unity? some closed source library that can't be fixed? whatever) Once you get experienced on maintaining legacy systems (and KSP is a legacy system by now), you learn than fixing non-functional bugs more than often ends up creating functional bugs.

We are going to need to agree on disagree on this.

No, it was not a bug on the mods. Even KSP was writting the KSP.log on the wrong place, and "forgetting" to use the UserLoadingScreens. But… You raised an interesting point. I didn't checked how this "PDLauncher bypass" had affected the KSPUtil.ApplicationRootPath. Doing it now. -- -- POST EDIT -- -- I reproduced the bypass problem on my Windows testbed and got this form my test case (this was executed on a Windows 10 machine): [LOG 05:30:41.839] [KSPe] pwd: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\PDLauncher\ [LOG 05:30:41.839] [KSPe] origin: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\ [LOG 05:30:41.839] [KSPe] KSPUtil.ApplicationRootPath C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../ I concede that using the KSPUtil.ApplicationRootPath would had prevented some breakage, but since KSP itself needs the PWD to be set at the same path as where the executable is (called "origin" on the path above), I can't blame the add'ons for following suit. When in doubt, we always should do exactly the same as KSP does, and KSP needs the PWD to be set on the same directory where the executable is, otherwise it will misbehave - as misplacing the KSP.log, ignoring the UserLoadingScreens and if I remember correctly (pending confirmation) where the @thumbs directory is placed (I think this is how I detected the problem on Linux, when a Graphic Shell launched KSP with the CWD on a different place - but it's more than an year, perhaps two, since i handled this, I need to find my notes). — — POST POST EDIT — — My add'ons will be updated nevertheless. If the consensus of the eco-system is to use KSPUtil.ApplicationRootPath, so this is what I will use from now on.

I'm building the testbed at this exact moment - but Internet is slow around here - don't have a clue why. Oh, well.. I survived dial-up, I will survive this. That's odd, I don't remember any patching about KSPWheels from my side. In a way or another, while firing up the rig after applying your CKAN file, ModuleManager complained about a fatal error and asked to quit the game. So quit the game I did, but didn't found any error message on KSP.log neither MM ones! But on Player.log I found a MM Exception about missing the MiniAVC-V2.dll. Odd. I'm still digging using KSPWheels installed for while. I think the problem may be something else, with random DLLs being caught in the crossfire - this had happened before. — — POST EDIT — — Now I'm getting Error Messages from B9PS. Since you didn't complained about it, I'm assuming I may be on the right trend on believing there's something else on the rig screwing up innocent bystanders. On the other hand, this Windows machine I'm using has only 8GB of memory, what can be a problem - your rig is way more powerfull that this one... In a way or another, still digging... I will come back to you soon. — — POST POST EDIT — — — Kopernicus borked on me too. I didn't found any Kopernicus complains on your KSP.log, however... -- -- POST POST POST EDIT -- -- OUKEY. Found something: [WRN 23:20:19.271] AssemblyLoader: Assembly 'CC_RemoteTech' has not met dependency 'RemoteTech' V1.7.0 [WRN 23:20:19.271] AssemblyLoader: Assembly 'CC_RemoteTech' is missing 1 dependencies [WRN 23:20:19.271] AssemblyLoader: Assembly 'KerKonConConExt' has not met dependency 'KerbalKonstructs' V0.9.0 [WRN 23:20:19.271] AssemblyLoader: Assembly 'KerKonConConExt' is missing 1 dependencies Contract Configurator has a hard dependency on RemoteTech and it apparently failed to be loaded. . But it was not installed! This triggered that nasty KSP Assembly Loader/Resolver, and by then nothing more works. The KSP.log your CKAN file generated here is substantially different from the KSP.log you had sent until this moment, by the way. So take what I'm saying here related to a KSP rig built with the CKAN file you just sent, and not to the KSP logs you had sent earlier. I will install RemoteTech and see what happens. But later, right now I need to give attention to something else. — — POST EDIT — — By installing RemoteTech and Kerbal Konstructs I fixed all dependency problems on the system built by your CKAN. However, the game doesn't loads, it enters into a loop inside Kopernicus - something about missing a Star System? Well, I will start removing things now, being Kopernicus the first of them. Once I managed to have a working rig, I will be able to identify what's happening. — — POST POST EDIT — — OUKEY. I removed Kopernicus, and by some reason CKAN removed a lot of add'ons too. B9PS is still complaining, however - but this didn't prevented me from launching a savegame and playing a bit on the Editor. I found why your crafts lost Scalings, something had completely removed the TweakScale scalings and added its own - very limited, if compared with the default TweakScale ones. I will work on this new misfeature now, and later I will try to understand why CKAN removed a lot of (apparently) unrelated add'ons when I asked it to removed Kopernicus, and then I will try to diagnose why adding Kopernicus (or some of the add'ons CKAN removed) was preventing me from launching the game correctly. —— POST POST POST EDIT — — I'M AN IDIOT! There's no problem related to TweakScale on your rig. What's happening is that you had installed Realism Overhaul, and RO has their own rules for scaling. They removed the default Scales from everything, and then added their own - and some parts are not scaled anymore, while others have different scaling rules. There's nothing to be done about this, it's take it or leave it. If you want to use RO, you need to wave TweakScale as I publish it and embrace TweakScale as they envision it should be used. If you want to use TweakScale the way I publish it, you will need to uninstall RO and play without it. Sorry. In a way or another, I consider this aspect of your report as closed/wontfix - I can't further help you on this matter, as I would be intentionally "mangling" other peoples work by their backs. I will uninstall RO on my rig and try to figure out why all that Exceptions are happening. — — FINAL POST EDIT — — So this is what I did to have a working KSP rig using your CKAN file: Installed RemoteTech to satisfy the ContractConfigurator dependencies Installed Kerbal Konstructs to satisfy KerKonConConExt dependencies Removed RealismOverhaul (and anything that was installed due it). It worths to mention that B9PS stopped yelling on me after removing RO, so I'm pretty sure that one of the things installed due RO was screwing it up. Since this is something related to B9PS and/or RO, I think you should reach them for help to fix this one, assuming you really want to keep RO installed - remember that by installing RO, you will lose your crafts scalings as RO uses a completely different (and incompatible) scaling system. Cheers!

There's something else to be considered. I noticed people complaining about KSP 1.12.4 being laggisher than 1.12.3, and people are blaming 1.12.4 due this. However, when I downgraded KSP 1.12.4 to 1.12.3 on Steam, less than a megabyte of data was downloaded - this is too few to be related to textures - the main source of lag on my punny MacPotato. My best guess at this moment is that the extra resources needed by the PDLauncher were the straw that broke the camel's back on people still using older 2 or 3GB VRAM GPUs. Getting rid of the PDLauncher may help on saving VRAM, that by itself will tax less the FPS.

Until this moment, 1.12.4 didn't broke anything that wasn't already broke in 1.12.3. The only occurrence of a KrakenStorm I'm aware was due people trying to workaround a misfeature related to PDLauncher in an unfortunate way. I worths to mention that such misfeature also affected KSP 1.12.3, as the PDLauncher were injected on 1.12.3 installations too. The problem only affected Windows users - MacOS had the PDLauncher installed, but it wasn't configured on the Steam Launcher. I don't know about Linux yet. This could be the extra VRAM needed due the PDLauncher being in memory - KSP 1.12.x eats a lot of VRAM, and if the user has a 2 or 3GB GPU card, any graphical program more on memory can be the straw that breaks the camel's back. Everything and the kitchen's sink uses VRAM nowadays, from the System's GUI to Browsers - we just can't get enough, as it appears, and games are the ones suffering from the problem the most. I suggest to anyone having lagging on the gameplay to lower a bit the Texture Settings on the Main Menu's Settings. Until this moment, it solved most of the lagging I had on KSP 1.12.x . The MONO_THREADS_PER_CPU trick also helped a lot - it even made my machine to run cooler with the same load.

Dude, I would nominate this as the "Post of the Month" if we had such thing around here!

Worst. KSP itself will start to look for and save files on the wrong place - while this ordeal were being diagnosed on my side, it was found that KSP.log was being written inside the PDLauncher's directory. I didn't further tested this, but I'm unsure about how settings.cfg, partdatabase.cfg and perhaps even the savegames would behave on this situation. On my add'ons, I choose to stick with Stock and normalized my pathnames to work with the PWD the KSP likes - using absolute pathnames instead is less than ideal because it makes porting code to handhelds and console more problematic (and, hey, Steam Deck is a thing! I'm dying to grab one!). The unreparse stunt made by the mono runtime is already bad enough. Yet more fun: on MacOS, we follow the NextStep convention: an Application is a folder those name ends with ".app" and inside we have all the resources needed (or symlinked) for it. It's elegant to say the least, installing and uninstalling applications is pretty straightforward. But it's a pain to call them programatically, we usually do a shell with "open /full/path/to/Application.app" and let the OS do the rest. About the problem at hands: what happened is that the Program Working Directory, PWD (or Current Working Directory - CWD, or Default Directory - different names on different O.S.s for the same thing) was being set inside the PDLauncher folder, and not on the KSP's root directory anymore. And so, everybody that is relying on the PWD being correctly set (including KSP itself, as the KSP.log ends up on the wrong place due the stunt) gets screwed as things are not reachable anymore from the places it used to be.

As far as I know, only Windows got the PD Launcher configured on the Steam Launcher, besides it's being downloaded and installed on MacOS (and probably Linux). I don't know why, as by the Krakens I could not manage to run it - at least on MacOS, I will try Linux eventually.

What implies you see yourself as simpleton? Too much modesty I say! Real life is way simpler: I'm rarely harsh with users, I'm the one knowing better, it's up to me to explain how things works. But I agree I tend to be more demanding with people that appears to know more. The more you know, the more I tend to hold you responsible. That would probably end up with bloody noses or with bloody marys. Sometimes both!

It's exactly what I did. On every KSP.log that has the following entry on KSP.log: Environment Info Win32NT 7FFFFFFFFFFFFFFF Args: KSP_x64.exe C:\Games\SteamLibrary\steamapps\common\Kerbal Space Program\PDLauncher\launcherpatcher.exe the Steam's launching configurations were badly configured, and this was the source of the problem. I didn't dug into this to fully understand why this caused KSP to be launched using the wrong Program Working Directory - this was the problem that triggered the huge krapfest on the whole ordeal to tell you the true. Using the default configuration does not cause any problem. For people really wanting to get things the other way, adding KSP_x64.exe as an external program solves the issue the easier way. Creating a shortcut and using it on the Steam Launcher will allow you to run the game using "steam://run/220200", but I don't know if this will add any benefit over just adding the KSP as an external program. All the other reports are real problems, and I will proceed on their diagnosis as usual. — — post edit — — And yeah, I found where it was mentioned bypassing the launcher, but I didn't knew about the Thread, so I took bypassing the launcher as what we were trying to do, and not as some new "technique" to (not) be applied to the Steam Launcher.

NOTAM Given that I finally got a Windows machine (blergh) to test things, I could check things myself and understood what happened about PD Launcher The whole ordeal was a mess. PD Launcher is not a problem. POINT. TweakScale was the one reporting something wrong, not the victim nor the cause of the problem. POINT. Some dude tried to accomplish something on Steam Launcher, made a mistake, and then a lot of people started to shoot the messenger (TweakScale) and I got involved on the shooting without a gun. Yes, I'm eating my words on this one. — — I just got notice of an even better solution!