Lisias

Frankly? Knowing what I know from Unity, this would not be a (new) issue. Dynamic Loading Assets would reduce the initial memory footprint (and the initial loading time) by a mile , but would also make the memory problems worse. Try to imagine the pathetic Unity's GC handling, also, many megabytes of binary assets being loaded and unloaded on demand on playing time... SystemD had bitten me on the SAS more than once. This thing manages to be worse than Unity's GC, and you are a happy man if you didn't had to figure it out by yourself.

Not only Mono, but Java and any other Garbage Collector based runtime - including C++ ones. To make GC work on Real Time systems, you need to satisfy a lot of constraints and demandings that, usually, renders manual memory management easier to implement. Only now, after what… 20, 25 years? Java has a somewhat usable Real Time kind of friendly GC (G1GC). But frankly… Who wants to do business with Oracle? Now take all this investment and try to figure out if isn't cheaper to just teach the !#$##!@# developer to handle memory and apply best practices and static tests when writing Real Time applications. A call to such OS function will be, always, more expensive than just allocating something from your heap. It will incurs on a context change to the privileged ring, a search on the memory tables for a suitable memory block (and sometimes repacking the free memory to build such block by "force"), mapping it into the Process Descriptor tables, zeroing it for security reasons and some more details I don't remember right now. It is a very expensive call. But yes... It's way more expensive not to do it. It's plain appalling that someone that calls itself "Professional Developer" just ignore this simple fact. "We don't aim to serve games with such long lifespan" it would be an acceptable answer. Ok, it's a low quality and cheap Engine for casual, 15 to 30 minutes session, small games. It would be a honest answer. But this "The O.S. does it wrong, we know better" approach? Really? It's due an abomination called WinSXS. Every time a program is installed, a "snapshot" of every DLL it uses is recorded by its installer. So, if another program or system update happens, this program still uses its own well known "copy" of the DLLs. With time and updates, you end up with almost a private copy of almost entire O.S. for every program you have. As an emergencial hack to keep things working while a proper solution is worked out, it's acceptable. Unfortunately, Microsoft have a notion of "temporary" that appears to be incompatible with Reason. You too? Another Follower of the Sacred Way of a SystemD-less System? Stuttering can be delayed by using MemGraph. You "pre-allocated" some memory ahead before it's really needed, so it would take sometime before the GC is needed - that stuttering is essentially the GarbageCollector freezing everything in order to reclaim unused memory. However, you do that too much, when finally the GC kicks in there're so many garbage to be collected that the freeze takes too much, and something else on the Engine blows up due the freeze. The GC must halt every other thread in order to do its thing. It's a limitation of the technology - threaded GC's are some of the harder problems to be cracked on this trade. About the 12+ hours gaming sessions - there's a unspoken true: some of us (me included) don't only mod the game, but we mod the mods themselves. We profile, detect and fix the performance/memory leaking problems for ourselves. It's the reason some old school players are still using 1.3.1 or even 1.2.2 - the effort to redo all that work is too much for the benefits they will get in exchange. You can count about 1.000 to 5.000 lines of code rewritten and months and months of work. Not for the faint of heart.

The runtime is way.... More adequate to be used as fertilizer than as memory manager. :-) Unity did some "optimizations" on the Mono Garbage Collector. Given the way Unity does things, this alone is already a concern. However, Unity has also a policy to never give memory back to the system. They alleged that giving memory back and then asking again for it is expensive, and once a memory was needed once, it will probably be needed again. What's is not wrong, but what they don't get is that swapping memory to disk is a dozen orders of magnitude more expensive and it's exactly what the Operating System will do as soon someone else ask for the memory Unity is compulsively hoarding. Now add the memory leaks to this near sociopathic behaviour... They manage to get away with this stunt on small to medium games (1 to 2 G ram). But KSP is a monster, almost an Operating System itself - and Unity is consistently borking on it.

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