soulsource

There are some tutorials on the internet, on which things to avoid in code, the rest comes with experience. A good starting point is the Unity Documentation about Memory Management, and the tutorial on Optimizing Garbage Collection in Unity Games. In principle all sources for garbage are some kind of object creation, but many of them are not obvious, or happen under Unity's hood. Examples for non-obvious sources of garbage (apart from OnGUI() calls) are string concatenation, foreach loops, most LINQ-functions, and delegate creation. Edit (2017-04-09): There is also a Visual Studio extension available through NuGet, which can highlight heap allocations in the code. Sadly I don't remember how it was called... Edit (2017-04-10): I mixed up something. The tool I was thinking of was actually an extension to ReSharper, and it's called Heap Allocations Viewer.

As a pure user, I'm afraid there is not much one can do, except to wait for mod authors to provide updates.... If you are willing to code a bit, you can of course work around the issue yourself, once you know which mod is causing it. If you are motivated to do this, the developers surely will be happy to accept pull requests for fixes on GitHub. The way I found out which mods cause the issue was by profiling KSP with mods installed, and checking where all the garbage came from. If you are lucky the mod causing your issues is doing this not via OnGUI(), but via some of the numerous *Update() methods. In that case, the Unity Profiler will tell you which class is causing the problem, and which function, so it's rather easy to find. If you have problems caused by too many OnGUI() calls, the situation is different. Sadly, I did not (yet) manage to get more information out of the profiler than how much garbage all OnGUI() calls together are causing, and how many OnGUI() calls there are in total, and figuring out which mods caused them was then a matter of uninstalling them one by one...

I've been playing around with the profiler to see why my modded KSP install is stuttering, and noticed that I get more than 500 calls per frame to OnGUI() - each creating a little bit (384 bytes) of garbage. After a little digging I could track this down to vessel modules running on vessels that are not loaded (including asteroids). This of course made me curious about what's going on here, so I made a test mod that does nothing but print the vessels on which it is currently running: using UnityEngine; using KSP; namespace Testmod { public class Testmod : VesselModule { void Update() { Debug.Log("Testmod running for vessel: "+ GetComponent<Vessel>()); this.enabled = false; } } } Sure enough, after adding it to a fresh KSP installation, starting a new Sandbox game, and launching a craft, the log started showing interesting things: (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Testmod running for vessel: mk1pod (Vessel) (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Testmod running for vessel: Ast. HSJ-227 (unloaded) (Vessel) (Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) Testmod running for vessel: Ast. CMP-717 (unloaded) (Vessel) But this was not all. I would have expected the vessel module to disable itself after one frame, but the log output went on, and on, and on... Obviously KSP keeps re-enabling all vessel modules every frame, so even disabling those beasts is not an option. Long story short: I'm pretty certain that (at least with KSP 1.2.2) vessel modules are running for all vessels and cannot be disabled easily. One has to make sure not to place any code that causes garbage or heavy load into those classes, especially bad are functions that cause garbage whenever they are being called, even if they return immediately, like OnGUI().

Just to let you know: I still get multiple FAR buttons. Apart from that it seems to run fine up to now.

Thanks a lot! When I have some spare time (meaning: more spare time than I could spend playing KSP...), I'll have a closer look at the kOS source code, as I'm quite curious about its inner workings. For now I'm happy to know that each opcode counts as instruction, and that there's an option to profile code. This will hopefully allow me to get my script to finish in a single physics tick. I'm aware that I could just increase the IPU limit, but I like the challenge to get it running on tight resources .

Hi! Sorry if this has been asked already, but I didn't find it in a quick search. What exactly is an "instruction" in kOS, and how does it count against the IPU limit? Is an instruction a line of source code, is it an opcode in the compiled file, or is it something completely different? I'm asking because I'd like to know if it makes any sense to factor out variables. As an example, which of the following two snippets will take less instructions counted against the IPU limit? SET x TO a*b*c+d+e*f. SET y TO x+2^x+3^x. SET y TO (a*b*c+d+e*f)+2^(a*b*c+d+e*f)+3^(a*b*c+d+e*f). In traditional programming the first variant would of course be the faster one, but if the whole SET instruction counts as a single instruction towards the IPU limit, the second variant would be preferable.

Just to avoid confusion, a quick reminder that the code for this mod is not under GPL, but under the MIT licence. That's actually the more interesting point. While many mods are under a permissive licence to encourage contributions by the community, most mod maintainers prefer to be the only person to publish built dll files, to have some control over versions being out in the wild. The reason for this is support. It has happened too often, that users of unofficial development builds start to annoy the original mod authors because of issues that either have already been fixed upstream, or have been introduced by the person who made the unofficial build. So, unless you have permission by the mod maintainer to distribute the build, it's definitely the better option not to share, as we players definitely want to keep the modders in a good mood.

Seeing a similar (but not exactly the same) issue on Linux. Opening the Scatterer GUI and setting the Experimental Atmosphere Scale to 1.0 did fix it for me though.

Some mods are hosted at Curse, but many mods are hosted on other places, including but not limited to the personal websites of the mod developers, github, SpaceDock,... While I personally do not like CKAN it does have the advantage of allowing to obtaining mods from all those different sources.

I've finally managed to get back to play KSP again, after having a real-life induced extended break. Not much was done today, but I finally decided to just timewarp in my 1.1.3 save to get to an Eve->Kerbin transfer window and bring Clauma Kerman, brave pilot of the first working 1.1.3+FAR Eve lander back home: Imgur Album

Disclaimer: I haven't played 1.2 yet, my experience is based on Remote Tech. A geostationary comm network isn't meaningful with a single control point either, as it's not a requirement to always have the same sat connect to KSC. You could just as well have a equilateral triangle of sats that can see each other at any altitude - one of them will always have line of sight to KSC.

KSP can request additional memory from the operating system whenever needed, but before asking the OS for more RAM, it first checks if it has some memory already allocated that contains no longer needed data, and will reuse that memory if possible. This process is called "garbage collection", and it sadly causes a noticable load spike. How often this garbage collection happens depends on how much "new" memory the game requires over time. Game developers typically try to keep this amount as small as possible, and currently the KSP developers are working on exactly that issue. Another possible source of garbage are mods (if the mod's authors don't keep garbage avoidance in mind...), so when comparing your Windows and Mac installation, make sure to use the same mods on both. A long explanation of the whole process can be found in the Unity Engine's Manual page on Understanding Automatic Memory Management. I would not expect KSP (or any other program) to care about the RAM usage of other applications, and other applications cannot demand memory back from KSP (not counting the operating system's out-of-memory killer, but if that would be running, you'd notice it more drastically than by stuttering...). There is one thing though that could cause similar stuttering, and that's paging. It doesn't have much to do with KSP (except that KSP uses lots of RAM...), but simply with the condition that physical RAM gets full. Once all open applications together require more RAM than there's physically available on the computer, the OS will start to move data that hasn't beem accessed in a while from RAM to HDD. If now a process wants to access that data, it has to be copied back from disk to RAM, and the disk access can cause a performance impact (if paging happens excessively, it's colloquiall called "swapping hell" due to the performance impact...). In your case, what could happen imght be that KSP+whatever you do in the background causes paging of data which is later on copied back to RAM in small portions whenever something accesses those portions.

I wouldn't be worried about heating issues on your laptop. Only really crappy devices don't have sufficient cooling to support being run at 100% load for extended periods, and last time I checked Apple devices were pretty far from being crappy. That said, the PC versions of KSP are far from bug-free. Both, the OS X and Windows build of 1.1.3 tend to crash quite frequently, and the Linux build is only slightly better regarding stability, but has other (mostly graphical) issues. (Disclaimer: That's based on my personal experience - might be that others don't have frequent crashes on Windows.) Still, with the PC version you have the option to downgrade, and 1.0.5 is pretty stable (though performance is worse). Also, you'll get updates sooner, and probably 1.2 will solve some of the worst issues we currently are experiencing. In addition there are some extremely cool mods out there, which greatly enhance gameplay, and without which I hardly would want to play any more (for me FAR is a must...). The next thing is that on PC you won't be forced to upgrade to newer versions (not even if you buy through Steam, as KSP doesn't have copy protection -> just copy the installation folder somewhere else and Steam won't overwrite it ^^), what can become important as version upgrades might break savegames.

Maybe one should also mention the scientific term for the fact that it's (quite a bit) more efficient to directly burn for the transfer from low orbit: Oberth Effect.

My biggest failure and my biggest success have one and the same name: Eve. In my current save I did two crewed missions to the purple planet. The first mission failed, as the lander wasn't aerodynamically stable (I'm playing with FAR), and could not keep the heat shield prograde during entry. Also, the lander was huuuuge (that's why it's literally the biggest failure). Matrix (or was it Martrix - I got Kerbals of both names in my program and keep mixing them up...) Kerman was lost in that tragic accident. Recently I decided to give Eve another try, and this time the mission was a success. I did have to reload a few times though, as with Eve's dense atmosphere even a small change in ascent profile can cause a huge difference in fuel consumption. The lander was much smaller than on the first try as I planned to use the Kerbal's jetpack dV in addition to the fuel in the lander, and as I now had the 10m heatshield, it was much easier to have it aerodynamically stable during entry. Also, the decision to land in the mountains (at 4500m iirc) helped quite a bit. And if you ask for my literally biggest success: That's also Eve, back in 0.23.5 (without FAR). A monstrous rocket, which was perfectly capable to reach Eve orbit from sea level...

If the game manages to crash your whole system (meaning: not even CTRL+ALT+DEL does anything), then what you are seeing is likely caused by something else, not by KSP, as on modern operating systems userspace applications should not be able to cause a system crash. What userspace applications can do though, is cause driver bugs or hardware issues to surface, and that's where I'd start looking for solutions. First, make sure that all your device drivers are updated to the latest version, especially your graphics card drivers (I'd try to use the drivers available from the nVidia website, as those tend to be more up to date than those on the Asus website, but they might not work on all Asus laptops). Check for firmware updates on the Asus website. It can easily be, that your laptop firmware is buggy Make sure your laptop doesn't overheat. Open the case and remove dust from the fans. Check your laptop's memory for errors. There's a free tool named memtest86+ (not to be confused with the non-free memtest86) for that. Edit: If there are memory errors, it's perfectly possible that it's just a bad contact of the memory module. Before buying replacement memory, try to remove the module(s), and mount them again. In any case, if you bought KSP over Steam, you should have a few hours of time (I don't remember how long...) to get a refund.

I'd like to second what bewing wrote, and back it up with a reference to a statement by the developers. Currently the game can, under certain circumstances, miss intercepts. Once one gets close enough to the target body, the SOI change does take place properly though. For details see:

Not really. It's just a distance check, and if the craft is close enough, the craft's trajectory is analytically calculated with respect to the body. While this is, in scientific terms, physics, from a code view it's just geometry.

Planets are already always "on rails", meaning their current position is a very simple formula that just depends on time, with no physics involved at all. I doubt that it would be a big performance change to replace that by bone animation.

While meanwhile one can in principle calculate everything on the graphics card, there are two issues here: First, KSP is built using Unity, which uses nVidia PhysX as physics engine, which relies on nVidia CUDA, which is nVidia only (as PhysX is closed source, not even the Boltzmann Initiative can help here...). Second, and that's much worse, the way KSP is simulating a single vessel is not well suited for parallel computation (that's why there's also only one core per vessel on the PC). I wouldn't expect KSP to run better on the consoles than it does on a PC with comparable specifications, but I hardly can wait to test it myself as soon as it gets released in Europe.

KasperVld has written about it here:

That was a reference to the South Park episode "Freemium isn't Free". If you don't know it yet, watch it. It has a nice (and informative) summary how Freemium games work.

First: A very, very big THANK YOU towards Squad for not forming a pact with the Canadian devil. They have done everything right from a player's point of view, they've even given us the chance to try the free demo before spending money on the game. Now to the luckily just hypothetical question: A completely heartless person could make KSP free to pay. To do that, this hypothetical being of pure evilness could choose to allow players to buy funds with real money (and have the in-game fund earnings at or lower than what one has in early game hard-mode). Or to pay real money for "someone else" to do rescue missions, to bring back otherwise lost craft. Timewarp might be limited, so that one can only timewarp for a certain amount of time per day, except if one pays. Parts might be unlocked against money instead of doing research, or part unlocks per day could also be limited. There might be super efficient premium-only parts, that one could unlock for a few hours by paying real money. For all of this to work, the game would have to be far more grindy though. The main ingredient of Paymoreium games is the fine balance between frustration and addiction. The game has to be addicting enough to keep players hooked, but also frustrating enough to force them to pay...

Memory and performance concerns are not really relevant. It only has to be clearly communicated that mods can have a negative impact on performance, and that users basically loose support unless they uninstall all mods again. Especially memory usage is a non-issue, given that until recently the majority of players was stuck with a 32bit version of KSP.

I've done a lot of stuff during the last days, most of which I'll post once the missions are over (so I can show off the whole missions in one post). This means, I can only show one mission today, as it's the only one I finished yet: Namely an unmanned plane for Duna. Its fuel was planned to last for 20 minutes rocket-powered aerodynamic flight, but at that point I completely underestimated how well stuff can glide on Duna's atmosphere due to the planet's low gravity (and maybe also because FAR is awesome). Burns were then only performed for a few seconds a time, with gliding phases of several minutes in between. In the end the flight not only brought the drone to all three anomalies SCANsat had revealed, it also went to both poles of Duna before landing on a (sadly too steep) slope close to Duna's north pole after the fuel finally ran out. The only negative thing I can say about this mission is that it went too well. I spent several hours flying around... Edit: Should you wonder why the dV readout is so much smaller on the first view screenshots on Duna, that's because the front tank was locked at that point, as draining it first would have made the craft unstable.