Lisias

And more interesting: I'm using this expedient myself!

I find it lovely! Ugly it's this monstruosity I call a "planes" and that I managed to make it to fly probably due some KSP bug! (and yeah… It takes off exactly as this IL-76!! )

Fixed! Sorry the trouble!

I think it would be another "victim", I gave a peek on the source and I only saw calls to UnityEngine, not "direct calls" to any native DLL. Most games doesn't eats memory as candy as KSP. I don't expect too much fireworks.

I once mentioned how my KSP designs are similar to some soviet ones. And today I came to this: (Forum safe this time! ) I can't remember a cargo plane of mine that didn't take off after the runway ending… Do you know of any more Real Life Kerbalism? Please share!

I'm a dumb SAS. Until now, I completely missed about this important piece of information besides being advertised ad nauseaum. It's still a guess, but now a more informed one. Joysticks are not needed except on Flight Scenes. So, it's reasonable to assume that the XInput are "opened" when you enter the Flight Scene, and "closed" when you exit it/enter VAB, SPH, et all. It's also well known that our "friend" Unity just don't releases memory no matter what. And since it's well known its memory leakings, it's plain clear that memory footprint is aways on an ascent - what varies is the slop. So: User builds a plane/rocket. User enters Flight Scene XInput is "opened", and a memory buffer is allocated for it. User flies this toy Unity globs some more memory, raising the footprint a bit User goes to a non-flight scene (Mission Control, Tracking Station, whatever) XInput is "closed", and the current used buffer is released This memory is not under Unity's control User goes back to flying XInput is "opened again". Since the previously used buffer was released and probably already reused for something else, a new buffer is allocated As the memory footprint grows, eventually this new buffer is allocated beyond the 4Gb boundary and then things goes KABOOM on 32 bits DLL. @Just Jim, I think we nailed down a deterministic Modus Operandi in order to reproduce the issue. A small custom part that "eats memory while flying" would speed up the process. Perhaps MemGraph could do the trick too.

After more than a month without really playing, I decided it was time to come back to my 'First Career" - just to realized I was kind of cheating without being aware (I forgot a cheat activated). #sigh Well, it's a game. We call rollback So I cheated again and restored a backup from 40 days ago that was for sure "uncheated", and restarted from there. Would be interesting replaying that missions again with the know-how I currently have. So… I rescued Lt Melald again and, well, I managed to get some really nice screenshots this time! On the not so bright side, I discovered some new Null References Exceptions on the KSP.log - I think I well spend the weekend chasing bugs again.

You can increase the texture compression (I use x2 on my rig), or delete one or two less needed Mod. I have 4 installments for KSP here, each one specialized on a Mission exactly due that.

I suggest The Kerbal Way to solve this problem. Build a decently big rocket, strap your classmates on it, fire it and see the fireworks while the rocket explodes the launchpad, your classmates and (hopefully) their parents nearby. Add MOAR BOOSTERS for maximum effect.

I run KSP on a Mac machine, and it's usually eats up 10 to 12G of RAM. If your KSPx64 is consistently dying at 4GB of memory allocated by the process, I definitively would bet on some 32 bits DLL somewhere in the System being used by KSP, and getting killed when KSP reaches that memory limit and the get shoot on the feet when it calls that DLL using a memory pointer above that. If the XInput trick didn't helped you, there's a good change that something else on your system is getting into this. Another thing is VRAM memory. Each texture you add to KSP via mods eats VRAM from the GPU Card. When you exhaust your VRAM, Unity also crashes without any clue about the reason.

Hi. RemoteTech has been updated, and it broke Contract Configurators. Trying to purse the matter, I found that there's a new method on the Interface ISatellite, and since CC doesn't implement it, CC is not loaded. I just added public bool PowerShutdownFlag { get { return false; } set {}; } on the line 81 of RemoteTechProgressTracker.cs to make things compile. Don't have the slighest idea about what i'm doing, however. I will give some feedback later. — POST-EDIT -- It appears to do the trick. Reading the RemoteTech documentation, the new Interface Method signals when the Satellite is under a manual override shutdown. — POST-POST-EDIT -- A proper fix was published below by PiezPiedPy.

3 Minutes? Congratulations! I'm running KSP on a i5 MacMini with 16GRAM and 2.3GHz. And it takes 10.

I think it does something else. The landing gears are brittle without KJR. But you gave me an idea to check this. EDIT: I just remembered the reason I installed KJR - I made a really big blimp, and I could not launch it due some Clamps bug or something. No matter how many clamps I added to the thing, the clamps fails on launch exploding everything. I'm reconsidering my options.

Well, since the Unity log files are the same for every game on my machine, I concluded that only one Unity application is expected to run at the same time on one machine. So you rationale makes sense. If an user don't want to be 'tracked' on a game, he/she probably don't want to be tracked on any other too. Well. It's correctly advertised (from the 1.4.5 Change Log) But.. Perhaps it was too much succinct for the non experts, you have a point here. Since Squad is a "user" for this functionality (as it's something embedded on Unity, and not made by them), there's a chance that even they don't know exactly how this works. I'm kind of learning some Unity (due KSP), and I can tell you that not everything is clearly explained on the thing. (And some things that are, I think it's plain wrong - but whatever).

Cheap counting beans stand-up guy. I aim to recover and reuse even the bolts. I don't litter the Space, I bring everything back! Fuel is cheap, hardware is expensive (Spacex style). I also delay any tech or facility upgrade until I exhausted any hope of carrying the mission without that. I try to work with what I have at hands. Of course, all of this is feasible because I make use of mods. Shamelessly.

Not anymore as it appears. I just saw my son using Facebook on his mobile besides being sit on his computer playing.

I'm on mobile now, and I see no sig! Here, see how it looks on mobile.

If it's stored server-side, it's not local. Check your KSP.log. You will find something like this: [LOG 11:26:29.681] Loading data opt-out preferences from PlayerPrefs [LOG 11:26:29.730] Requesting data opt-out preferences from https://data-optout-service.uca.cloud.unity3d.com/player/opt_out?app id=XXXXXXXX-d29d-4faa-bb01-YYYYYYYYYYYY&userid=b5XXXXXX021e49fYYYYYYYYe01dea37&deviceid=XXXXXXXX-43F1-5FAC-A363-YYYYYYYYYYYY It's not a random server. It's not even Squad's server. It's Unity server. Moreover, it's a simple HTTP request made on the open. O made a simple wget on the URL, and got this: --2018-08-17 18:18:26-- https://data-optout-service.uca.cloud.unity3d.com/player/opt_out?appid=xxxxxxxx-d29d-4faa-bb01-yyyyyyyyyyyy Resolving data-optout-service.uca.cloud.unity3d.com (data-optout-service.uca.cloud.unity3d.com)... 50.18.192.203, 52.8.62.165 Connecting to data-optout-service.uca.cloud.unity3d.com (data-optout-service.uca.cloud.unity3d.com)|50.18.192.203|:443... connected. HTTP request sent, awaiting response... 401 Unauthorized Username/Password Authentication Failed. SO… What we have: A HTTPS request with appid (KSP, for sure) and a userid and a deviceid is sent to Unity's server Such request is protected by password. If you have a problem with any of this, I suggest put the server's IPs on a black list on your firewall. Other than that, there's very little one can do without doing precisely what Squad is being accused to. ]] Well, we are not asked anymore if we want to share our IP. But since we are using it on the open, right here on the Forum (did you know that every time you load an image from, some random server logs your IP?), why it should be a problem on KSP? Any information you would wanna to keep out from eyes they already have. You bought the game from Steam, GOG, from them directly of from any other dealer. When you did that, you already sent to them your name, address, CC number and IP (and don't complain about, the IP is logged as a security measure - if you challenge the transaction, they need to have such data). When you downloaded the game, your IP was recorded to protect themselves from fraud. Your concerning about the matter is misguided, IMHO.

I think this is by design. The configuration is stored on the server side - so, no matter how many different KSP installments you have, all shave the same configuration.

I would not try it using a real world password. Who knows if that guy is not building his own rainbow table or selling known passwords associated to an IP to someone else?

I knew I saw this before! Well, I spend some serious time on my first career. Things were going more or less fine until I realized that I forgot Kerbal Joint Reinforcement installed for some reason (probably some test I did in the past, I don't remember). I deleted the thing, and then I realized than my aircrafts are not working anymore. (I should had been suspicious when I made a FireSpitter TetraPlane, with fabric wings, reach Mach 1…. ) I wanna to "play serious" - I want to do some crazy things, but I don't wanna cheat. Too much. So I'm considering delete the savegame and start over again. Damn it.

Kind of worst. A retired employee is not necessarily an angry guy. Developers don't leave because they're happy, however. And, guess what, companies that happily complies to any customer demand that expose to other customers, usually allow the developers to dump the credential's table. What could be possible go wrong, right? The passwords are "encrypted".

Buy a dog. It's all about reducing the chances. People have access to your computer all the time. Your computer is broken? You don't know how to repair it? Well, the guy you will hire to fix it will have access to all your data. Including the password file. You don't have the slightest idea stuff I find on second hand hard-drives. You will screw up sooner or later. So secure yourself as you were going to do that today. About the Palm, you don't know it. They are not tablets, they were handhelds - most of them don't have any connection capability but a wire for syncing to a host. And the best of them didn't even had storage, all is kept on RAM. You wipe the thing (or the battery dies), everything is gone for good. Point. Elegant devices for a more civilized age.

People screws up everywhere, every time. Security is like Freedom - you only have yours if you fight for the other's. One single stand-up guy breaking the chain ruins everything. I used to work on a company that sells tracking services consolidated (and automatically file complains for refunds when applicable). One day, one client asked by mail how we store passwords - well, I answered imprecisely "we use a message digest and a salt". Then the client asked about the Digest we are using, I refused to answer. I said I would prefer to review our proceedings under any security standard he chooses and tell him the result, but I would not be disclosing any implementation for third parties - much less on a insecure channel and without NDA. Boy, Hell broke loose. The guy phoned my boss complaining, and he ordered me to answer. BY MAIL. (sigh). Well, I replied with a 15 page email describing every single digest algorithm from Earth (and some more from Mars), and said that we use one of them. If by any chances he have any restrictions for some of them, I asked him to enumerate them so we could change if by some means we were being using it. Well, I don't work there anymore - but you probably guessed that. Uneducated, rich and persuasive clients are the first security flaw of any business. The second is leaving developers. These two guys are the worst security nightmare I ever had on my life.

Easy access for anyone that have access to your computer, physically or remotely. ;-) Never save passwords this way, unless you have a old Palm. They are excellent password keepers - until the battery dies.