Lisias

"RAM is overrated". I have a rig with 48G of RAM (a professional Workstation with a dual boot for gaming! - don't tell my employers!), and I can't shove everything I want into GameData neither. The main botleneck is CPU. You have "too much memory", and the CPU will be put into its knees on Garbage Collecting. Besides, every single mod you instal on the game also eats their share on the CPU's cake, and since every part alive on the game it's a discrete entity in need to be individually simulated, the after math is that you run out of CPU way sooner you run out of memory in rigs with more than 16G RAM.

Bill Gates didn't did all of that alone. To tell you the true, a lot of problems and bad practices we atribute to them (Microsoft) was, actually, misdemeanor from their "alies". People found a way to commercially exploit something on the Microsoft eco-system (including the flaws), and them coerced them into maintaining the bug/exploit. In the 80's and early 90's, Microsoft was not this giant we know nowadays. A big player could manage to hit a serious blow on them, and some of these blows would be unrecoverable at that time. Do you want to know something that Microsoft did right, but yet everybody else managed to twist it agains them? DPMI. Here is the full True History of DPMI, directly from the trenches: https://lists.gnu.org/archive/html/lynx-dev/1998-04/msg00773.html

Check if this DLL was compiled in Debug Mode. It was (are?) usual practice to ship binaries linked against the debug libraries from Microsoft because this library can be "tricked" into absorbing exceptions instead to throwing them up to the caller. It's the earliest form of empty "try catch" I'm aware. This would explain some performance and functional glitches. A function with a masked Null Pointer Exception would return a random value (whatever on the returning register/memory address at the moment), not to mention the time spend on the exception handling,

Sometimes, we software developers just do what we are told to do. And then the time passes and the reason for what we were told to do something is not valid anymore, but nobody tell us to stop doing that, and so we keep doing it. I'm wondering is this is not the case: somebody, somewhere, fixed something by doing this, and nobody remembered to tell him to stop doing it once it was not needed anymore. And yeah, I think your line of action is the more sensible one at the moment. I'm somewhat lost about what DLL is good and what is not - I somehow was convinced that the KSP's xinput was the good one, and you had to copy it to system32 to make it work. Reading now, it appears to be the opposite way. o.O Nevertheless, copying the "good" dll into the same place where the .EXE are should fix the problem (if it will create any more, we will see). KSP exhausted by a mile Unity's maturity and capabilities. The usual Unity's client has a product life cycle based on a Project - you start it, you work on it, you finish it, you kick the product thought the door then close the shop and that's it. KSP is a Program (in the sense of a Space Program!), a long term commitment formed by a series of specific short term goals. Exactly like a Space Program. Unity doesn't copes well with this model. They don't expend enough resources on long term support and compatibility as new versions of the Engine is sent to the streets. Try to imagine every single computer of the Apollo Program needing to be reprogramed, retested and redebuged every 6 months due a change on some vendor's math library (they can just switch from imperial to metric system on the next version!). Yeah, this is what's happening with KSP. That's the catch: I took some private pilot lessons as younger. I even learnt some commercial pilot lessons (I can read and understand the flight manual for a old Boeing 737, and perhaps a 747 - Airbus is over my head, new aircrafts are totally different nowadays). And this was the reason my first airplanes had a weird tendency to hug the grass. There're some glitches on the model they adopt for the lifting forces that doesn't match exactly a real airplane - what's perfectly fine, they had to shove that math on a consumer grade consumer from the last decade - but this smart-sas here wanna to play engineering and, obviously, failed. You need to see my face when one of the guys here explained how things work on the game. A kid would already figured out what to do, because he/she would try to understand the problem at hand. I spent months trying to shove what I knew about into the game, ignoring the evidences that the game were providing me. I feel stupid every time I open that save game. And Ellon is crazy. BFR style crazy.

It's about 4 years since I installed my last Windows machine for professional work, and since then, I only installed another one last month for a job (B.S., I installed Windows on my workstation to play games on a nice machine! ). And both are Windows 7. So, I don't have the slightest idea if anything really changed on Windows 10 and screwed up everything and everybody, or this is something that somebody else is doing on some systems, so I don't know exactly why this is happening with you. We need broader arms now, and Squad have the resources to check it out. KSP uses as a 3D Engine a thing called Unity, and this engine handles all the weight lifting when handling hardware - from the GPU to the HMI (Human Machine Interface) devices (joysticks, mouses and keyboards for the common people), so we have yet another variable on this mess. Unity. This time Unity appears to be innocent, besides this weird stunt of using what appears to be a 32 Bits DLL for input. Did you check if the DLL is 32 Bits by Right Clicking on it and selecting Properties? Just to avoid misunderstandings. Ideally, this should not be happening. So there's no "more intelligent way" to solve this. What we can pursue by ourselves is the less ugly hack possible. Copying the working xinput to the very same directory where the KSP_64.exe is should do the trick, but by doing this, you are "mangling" with the KSP installment, what technically void your warranty. And also can cause something else to blow up, because we don't know who else on that directory would need the "other' xinput by some reason (if any). However, yes, copying the working xinput.dll to match KSP_64.exe location is the "less dumb" solution for now, if it works. This is Windows, there's no intelligence available here.

Open a ticket for this problem, with a small abstract and link to this forum where the hot information is. https://bugs.kerbalspaceprogram.com I think you are the one that should do it, as you are the guy with the evidences. The devs need to test my hypothesis before investing resources on a fix (I can be wrong on the conclusion, besides the historical knowledge corroborates my hypothesis), and it's your machine that can provide the needed information.

Been there, done that. I once read on this forum (I think it was on one of the Announces for a new 1.4 version) from a fellow kerbonaut: "It's infuriating". I bought TWO copies of this game, one for me and one for my son. Some time ago I asked him about the game, and he answered that the game should be nice as he saw me playing it a lot, but he preferred to play Elite Dangerous instead. He wants to enjoy himself, and the way I used to curse while I was playing didn't sounded like enjoyment to him. That made me contemplative for some hours. I tried to figure out the situation: if I was cursing that much, but yet I still insisted on playing the game, something had to change. So I remembered that I am a software developer myself and remembered the classes about Software Engineering and User Expectation Management (not sure if I translated correctly), and realized that I was cursing because I was feeling impotent. Things got better since then - if something is wrong, I just work to fix or workaround it, so I can go back to play. I don't care about who was expected to fix what , if I can I fix it, if I can't I workaround it. My son said that the cursing almost stopped. KSP is related to Real Rocketry as much as Test Drive is related to Real Racing. It's a complex game, but yet, it's a game. Some real life concepts applies, but not all. And some ones were way simplified to make things bearable. Some of my funnier mishaps happened when I tried to use "real life engineering" and the damned thing exploded under my nose. Play KSP as you were a kid: don't bring the RL knowledge to game. Use the game to find out what RL knowledge you need to bring to the game. Of course, this is just what works for me (I was a Carmen Sandiego addict when a kid, I used to play with Barsa on my side!), your mileage may vary. Been there, did that. The more time one "invest" on the game, more angry one gets when the "investment" fails. It's exactly like this everywhere. Be careful with your stubbornness. This will lead you to become a Software Developer if you don't take adequate precautions. That explains the marvelous investigative work. We need exactly this kind of approach on the industry. But I'm digressing... There's this fantastic cartoon from the early 90's: There're kids around here. There're youngsters. And some old guys like me that never grows up. Give them some slack, I surely needed that when I was a fanboy doing some mess on forums (boy, I was chewed a lot! ). But there're also some people that, frankly, you don't have to cope with. Put them on the "Ignore User List" and that's it - I put two in my very first post on this forum, 5 minutes after creating my account and I don't regret it for a second. They can be the best of the persons for someone else, and that's ok. But I didn't came here to be angry with people, so…

Damn, I don't usually read YouTube comments. Most of the time, it's a waste of time. It would be funny such idioticy - but then we realize that these idiots do vote.

Obligatory mention : https://youtu.be/KZLl3XwlAIE

"Offense is taken, not given." It's up to every one to choose what they take for themselves, and their reaction for what their voluntarily take for themselves is their sole responsibility. Yeah. I'm stoic. That said, it's the association that bothers me. I don't like my name being associated to Pablo Escobar, for example. It's demeaning for me.

So, not willing to step on anyone toes, but not willing to waiting for the good will of them too, I start to fork things that I use and need to fix. Nothing really worths of mention except.. There's this guy that though it would be a good idea to incept a Repo using as nick name a (in)famous arian dictator from an European country during the WW2. I don't give a sheet of paper for Politically Correctness, but I don't have that urge to attract to myself this kind of attention. I don't want to do a "silent fork", that would impair the original maintainer (and anybody else that forked the thing) to merge back any good stuff I do on my fork (we fork public projects for a reason, right?). But I also feel a bit awkwardly having my name on the same repo as… "him". #sigh Rebasing a 3 years commit history is far from being a nice solution neither.

Well… Now that the reentry-plasma appears to be calmed down, let's talk about the issue at hand. There're numerous different problems that leads to a crash, and yours is only one more of them. Until now, 70% (more or less) are directly related to Unity's lack of resilience when anything, absolutely anything goes slightly different from the ideal - not to mention the performance problems. But your crash is caused by something in the other's 30%, congrats. In a way or another, you are right about Squad being responsible for a answer, but are wrong about thinking they are "guilty" on the issue. They are being screwed up by a vendor. In this case, by two of them! And that's is the irony of the thing: you detected and solved the problem by yourself. Really, impressive work. Kudos! You don't have the slightest idea about the reason (I have, I will explain below), but yet you nailed it down marvelously. Really, congrats. You keep doing this, and you will have a job on any place I have some word about (assuming we could afford you!). Well… Welcome to Windows DLL Hell. Take a nice seat, you are staying for long. Originally, in the late 80's and early 90's (I know what I'm talking - been there, done that), the C:\WINDOWS\SYSTEM was the place where you put system wide DLLs. DLLs are a good thing, it's a way to share functions between clients - but as time passes, new versions with fixes for old bugs and new bugs to be fixed by new versions are created - and a bug that doesn't screws up with a new program can crash an older one (and vice versa). And Microsoft did nothing to prevent that, besides this being a well-known (and already fixed) problem on any decent Operating System of the era (yes, I'm talking about UNIX). To make things "worse", Windows didn't tell .EXE from .DLL on a thing called "search path", that it's a mechanism to allow programs calling each other without having to know exactly where they are. So, if you put a utility on your "search path", you also allow all its DLLs to be reached as they were a system wide one. So, people started to have a copy of the DLL they know for sure it's working fine to them on the same directory of the program, that is the place where it's supposed to be the DLLs that were made by the program maker and is not meant to be system wide. This defeated the very purpose of using a DLL, but whatever. This is Windows, and they are the Microsoft - don't expect too much. And then Windows 95 came, a 32 bit system build from a 16 bit infrastructure, with support for legacy Win16 programs - they need to do that, otherwise they simply would not sell. But Win16 programs can't handle [well] Win32 DLLs, and Win32 EXEs can't handle [well] Win16 DLLs. Worse, MS also had the brilliant idea of allowing system data and configuration to be stored on C:\WINDOWS\SYSTEM , messing everything. What they could do at the time to cope with their own mess is to create the C:\WINDOWS\SYSTEM32 directory, and store there the DLLs for Win32, and leaving the Win16 DLLs on the C:\WINDOWS\SYSTEM. And everybody continued to look for configurations and data on C:\WINDOWS\SYSTEM. If a Win16 program is started, the kernel would put C:\WINDOWS\SYSTEM on the end of its Search Path. If the program was a Win32 one, Windows puts C:\WINDOWS\SYSTEM32 in the front of the C:\WINDOWS\SYSTEM - so, yeah - if a Win32 program starts and invokes an DLL those 32 bits was not installed, then the 16 bits one will be provided. And yeah. **BOOM**. Looks familiar? Yes. When Win64 arrived, nobody had to deal with Win16 anymore, but all that code was still there being compiled in 32 bits. Worse, people didn't had learnt anything from the past, and the new programs were hardcoded into the c:\Windows\System32 (we finally had lower/upper case support and long filenames as default! hurray! ). So, using c:\Windows\System64 for the new 64 bits DLL would need to revise and recode everything. So... The damned stand-up guys just recompiled everything in 64 bits and put them all on the System32 and that's it. Since Win32 support would be kind of a sandbox (a "light container" would be a better definition) and so, having differentiated handling, they could be in anywhere else. So they had the "brilliant" (please note the quotes) idea of naming this place "System for Windows 32 on Windows 64", or SysWoW64. Oh, yes. Do you remember that "Search Path" thingy? They are still there. But now, in three different ways to screw you up! Four, to tell you the true, because they cooked up a way to allow Win64 EXEs to call Win32 DLLs. It works some times. At this point, you already know the reason. There're a DLL for each directory in which there're an EXE that needs it, to prevent exactly the problem that is bitting you in the SAS. However, and this is the inherent problem, some dumb-SAS mangled with the Search Path. I don't know if it's something that was done on your machine by some utility/program/whatever, or if it's something that someone on Microsoft implemented on the new Windows versions. In a way or another, this stand-up guy screwed up royally the way programs load their DLLs. Now, you are being forced to use the System Wide DLL, and not the one the program vendor (Squad, in this case) intended. As I said before, welcome to DLL Hell: And… Yeah, the newest approach from the Microsoft "Gurus" for this problem is a thingy called WinSXS - Windows Side By Side. This is another excrescence they had to do to make things work for while. Every installed program (using the Windows Installer subsystem) owns a copy of the current System Wide DLLs it uses there. So if the System Wide DLL changes, that program would still use the one it knows about. Now try to realize every single program you installed on your system having its own private copy of the DLLs. Yes, the WinSXS directory grows up until it's some times bigger than the original Windows Installation. SSD users really appreciate it (not!). Nowadays, 320GB SSDs are not enough due exactly this thing. Dude, it did. You really could had nailed down a reason for the Win64 instability. Now we need to check if what I said before about the "Search Path mangling" is valid for everybody else or just for you. This is something that the Dev Team should be aware too. @Vanamonde what you suggest? I don't know for sure if this is a bug, so I don't know if a ticket should be opened on the bug track.

I'm on mobile, so no links for Don't do it. You don't need, and you expose yourself to malware (God knows if that source is trustworthy). Google for download_depot, get the info from steamdb and learn to use steam://nav.console It's your best option. — EDIT — Okie Dokie, I'm on my Desktop now. On the spoiler below, the complete Step by Step: If you want some of the localizaton for M.H. , search for it on steamdb - it's a similar process. The Manifest id for the 1.4.3 is the third one from top to bottom on the Manifest Tab. If you are a steam user, you are allowed to do it. Don't worry about doing anything 'wrong', if you try to download something you didn't brought, the Steam App will not allow you to download it.

Because there're people in need of such support. Squad is responsible only for the Stock game. It's what they sold you, and it's what (theoretically) was approved by their Q/A team. Nobody in their right mind would give support for other's works. One can only support what he can control. But yet, modded game are an important niche on the eco-system. So these specific forum was created to allow people willing to help each other to find themselves.

Old dog, new tricks. I think this guy is from the old ANSI terminals era,.when all we had was 16 colours to do the job. :-)

I had similar problems that I workarounded by slightly pushing out the docks from the enclosing. Give it a try - it appears to be something on the colliders.

Oh me, oh my. :-) The information on this specific question is playing style and othet technical information. It's far from being your social networking and private business - that the advertisers already have, by the way, because some member of your family sold this info for them in exchange for some free kitten pics. :-)

The temperature is not the worst. The high humidity is. Hot and humid, man… You would sit on the ground and cry if you could (you can fry an egg on the pavement on the peak of the day). ( (cut the sound or get the kids out of the room - profanity alert! )

Yeah, it's pretty annoying when it's hot as this. It used to be that hot on Summer in Manaus, where I used to live. At midnight. At noon, we got usually 45 to 50º C.

No doubt. My argument was focusing on the tool, not on the results from using it. We have mission builder nowadays. Of course the OP perhaps didn't know about, but I do and your point didn't crossed my mind. But even by OP misunderstanding a Mission with a Mod, both our arguments prevails. It would be hard and expensive as hell in the best case.

I found this on the log: (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) PartLoader: Compiling Internal Prop 'Squad/Firespitter/Props/FSGearSwitch/prop/FSGearSwitch' Firespitter definitivelly is not part of the stock parts. Dude, delete everything. Every file. Check if you don't have an automatic backup/restore utility (OneDrive?), and delete the data from the backup too.

I'm probably the first kerbonaut to had seen it! This guy's problem is KSP unrelated. For sure. Something is corrupting the installment - perhaps the antivirus, perhaps the volume is corrupted, whatever, I don't know. What he's describing is similar to an issue I had on my Mac - usually, the Mac's file-system is case insensitive, but I reconfigured mine to be case sensitive as I do a lot of UNIX development on it. And some mods became broken due this, as the code/cfg/whatever mistyped the case. On Windows and "normals" Macs this is not an issue, as the filesystem is case insensitive. But on Linux and "my" Mac, this bites. However, it probably is. 1.4.4 broke Kopernicus, and the broken Kopernicus don't handle the Solar Panels (as it changes them to use his module, not the stock one). It happened to me before on the 1.4.0 times (I tried to use the 1.3.1 version, and the bug hunt lead me to this).

Don't bother, it's a well known issue by now. Something changed in the deeps of the 1.4.4 engine, and it broke some mods (namely Kopernicus and Kerbal Konstruction). Something about a PQS thing. The 1.4.5 release (happening right now!) is expected to fix this issue. However, keep in mind that these mods are, really, intended to be used on 1.4.3 . It may or may not work fine on 1.4.5 - in a way or another, keep an eye on the announces from the mod's dev team.

On a thursday? How do you guys expect me to work this friday?

And why this would be a problem?