Lisias

I build this: And then launched it: On KSP 1.4.5. Ask me how.

Right. And our colleague was beaten down to the ground and kicked in the stomach (had this happened after lunch, our friend could had a stomach rupture). It's already on the next level. It's already a police case. In a way or another, the very first thing he must do is ask for help from his parents (as I said below). And watch himself, because that kid is acting with criminal intent, has managed to beaten him down once and will do it again if he can. Sorry to tell this, but that kid is a sociopath. You don't reason with sociopaths. And yeah, I'm done with this. The message was already sent, and I think we stressed it too much already. @Vanamonde , I will not talk about this again.

K.I.Y : Kerbals In Yellow . The next DLC from Squad will be available next… (toc, toc, toc) Just a instant, someone is knocking my door. *FLASH*

He tried, he was beaten, that kid knows how to fight: got kicked on the stomach. This is already on the next level. ed

No. Never. Under no circumstances. This is not a sport, this is not a tourney. We are not knights, this is not a joust. This is real life, where the adversary/enemy/criminal/whatever are not bounded by any rules except the ones that are enforced by force (redundant, not?). Remember: if the other guy would be bounded by rules, you would not be in the need to defend yourself at first place. The response must be quick, ruthless and the most painful and consequential you can manage to accomplish *and* live with the consequences (because, yeah, you are bounded by rules). You don't need to avoid only this aggression. You need to make the guy regret trying the stunt at first place - otherwise, he will do it again, and will be better prepared. That kid would be a criminal if he had enough age. I suggest to do not forget this.

I got some self defense training once, due things that doesn't worth being mentioned. What I was told is that once you decide that you need to stop the aggression, your first, main and only concerning is to stop the aggression, no matter what. You should put the guy down on the first blow, no matter how, not matter the consequences. And then run, run as your life would be in danger (sometimes, it will). If you can't or don't want to cope with such consequences, don't fight back: acquiesce to the agressor and pray for the best - usually it's less worse than the consequences of doing a half baked defense (as our colleague ended up seeing by himself). Justice and fairness are something to be applied by jurists on a court. Here, on RL, all that matters is to stop the aggressions - the current one, and also eventual future ones (prevention). Predators don't have a sense of justice - they would not be predators if they had.

Unfortunately, I can testify that it works! So... Kick him in the balls strongly, ruthlessly and gently?

何も悪くない悪いことはありません。

It's just a number. Given the huge amount of changes and differences from the 1.3.x series, one can consider that perhaps the 1.4.x series should be that 2.0 the OP talks about. Squad needs continuous funding, otherwise they will not get paid - what would defeats the very reason they are working on KSP. Being that by a new KSP version, or by a myriad of new DLCs, you will pay for it again and again somehow or KSP will be a dead project. That said, what the OP means is that, perhaps, they should handle KSP as a Project - a iteration with a starting milestone, an end milestone, and some goals to be reached between them. And then sell this product for some time before restarting the process again. As you can't have the cake and eat it too, there're advantages and disadvantages on this approach. The disadvantages you already know, but the advantage would be a least about a year without having your savegames being broken by updates. Honestly, I think that a middle ground can be reached. But this is a discussion for another thread - I just wanna to explain the rationale used by the OP. He have some good points (as well you, just to clarify).

@JoE Smash, do you think this issue is the same of yours?

If you prefer to be beaten, it's your call. But I would suggest another line of action. Self preservation is a ability you must master sooner or later, however - and I not talking about fighting back (yet), but to avoid being beaten at first place. This kid acted with "criminal intent" - he knows he's wrong, as he avoided being recognized. He choses you as victim, and there's a reason for that: predators always prey on the weakest first. He measured you, and concluded that you are a "safe prey". Honestly? He was not wrong. The very best line of action is ceasing to be an easy prey. How? It's up to you. My first suggestion is look for support from your parents. They are your first line of defense, as you are not an adult yet. In the mean time, learn how to kick your opponent in the balls - strongly and without remorse.

Sergio Aragonés trolled me. I can't explain exactly how, as it would offend a Forum Rule, but this guy managed to troll me now using something he did 20 years ago. From thousands of his cartoons on the Internet, I managed to pick that very one. And it wasn't even one from his times on MAD…

"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.