Padishar

I totally understand where you're coming from with the "don't need it then don't install it" thing, and can understand your use case but I don't see that case as needing resource specific names and wonder if this particular part isn't a feature for features sake that will cause you extra work down the road for very little benefit.

This started as a simple plugin that displays a graph of the Mono heap allocation rate and garbage collection, mainly intended as a troubleshooting and development aid rather than for general use (hence why I originally released it in the Add-on Development sub-forum rather than this one). However, I have since devised a way to force Mono to keep significantly more free space in the heap, which can significantly reduce the frequency at which the heap fills up and the Mono garbage collection causes a stutter, so I have added it to this mod and released it more publicly. I will be continuing to work on this mechanism to improve it further. The code has been highly optimised to create as little garbage as possible (given the constraints of the old OnGUI based API) so that it interferes with what it's measuring as little as possible. I do have plans to add various "usability" type enhancements but only things that can be implemented cleanly and are directly useful for the mods purpose. To install, simply download the zip from the link below and copy the MemGraph folder from the zip file into the GameData folder of your KSP installation. Mod-KeypadMultiply toggles the display of the window. Mod-KeypadPlus increases the vertical scale of the graph. Mod-KeypadMinus decreases the vertical scale of the graph. Mod-KeypadDivide runs a bit of test code controlled by MemGraph\PluginData\test.cfg Mod-End pads the Mono heap with a configurable amount of headroom to reduce frequency of garbage collections. Every second the plugin totals up all the memory allocated on the heap and whether any garbage collections have run. It also displays the current total heap allocation, the maximum heap allocation just before the last garbage collection, the minimum just after the last collection, the number of "render" and "physics" updates and the time between the previous two collections. The graph is 600 pixels wide and shows the last 10 minutes of the memory allocation in green. If a garbage collection happens during the interval, that column of the graph will have a red background. The test code basically allocates a number of blocks of the specified size and displays which allocations actually cause the allocated heap to change. This allows us to deduce various characteristics of the memory allocator and garbage collection mechanisms (and was a crucial part of developing the heap padding mechanism). Mod-End activates the heap padding. The amount of padding is controlled by the MemGraph\PluginData\padheap.cfg. The format of the file is very simple. Each line controls the amount of padding allocated for blocks of each size range. The first value is the size of each block allocated and the second is the number of blocks. The first values are only present for illustration, they don't actually control the size of the blocks, these are hardwired to the sizes in the default configuration. The total value at the end is the total number of megabytes of padding allocated (note, the memory usage of KSP will increase by more than this due to the free space headroom maintained by Unity). I recommend that you run the game normally and load up a situation that has noticeable stutter. Display the graph, setting the scale so the regular allocation rate fits nicely and the garbage collection red lines can be seen. Let it run for several runs of the garbage collector and then hit Mod-End. After a short pause, the game should continue with a considerably larger gap between the collections. After another few collections hit Mod-End again and it may improve further. I would appreciate feedback about how well this works, e.g. screenshots of the graph taken during this process and after another few collections would be very helpful along with details about your setup (and preferably, an output_log.txt/player.log file). Many thanks to @Tig for the testing and very well presented data he posted over in the Grumpy Collector thread. One other thing I should add, though it should be obvious with only a little thought, is that the heap padding mechanism is only intended for 64 bit versions of the game. Trying to allocate 900 MB of extra heap space on the 32 bit version is unlikely to be successful and, if it is, then it will probably cause the game to crash before long due to running out of address space. It is also unlikely to work effectively if your machine has only 4GB of RAM as the total usage of KSP is likely to grow close to 4GB even without loading a save, resulting in virtual memory paging which will seriously hurt performance. Obligatory picture of mod in use: Download MemGraph for KSP 1.2.x and 1.3 Download MemGraph for KSP 1.1.x Source on GitHub Previous releases on GitHub (versions 1.0.0.x are for KSP 1.1.x, versions 1.1.0.x are for KSP 1.2). The code is released under the MIT license (see https://github.com/Gerry1135/MemGraph/blob/master/Graph.cs). There's no obligation and it won't entitle you to any special treatment but, if you feel like it, then you can make a donation using the link below. Donate Here

Even stranger, when I was testing it further last night on my decent machine (i7-4770K, GTX560ti, Win64, limited to 60 fps) I was seeing a large amount of memory allocated just having GCMonitor installed without ever having opened the window (and the mem/fps thing disabled in the settings). E.g. with just my mod at the main menu I was seeing between 130 and 200 KB/s but when I installed GCMonitor as well the usage went up to ~1800 KB/s. Again, this is much higher than the 900B and/or 84B per frame would imply and both causes of memory use were closed anyway. Do you happen to know if GC.GetTotalMemory(false) ever returns a smaller number than the previous time it was called when no collections have happened in the interval? I presume not and I didn't see any when I had some logging in my mod. Obviously, Mono doesn't return a very accurate number for total memory, it's always a multiple of 4KB for a start. It looks like it is actually returning the total of all the pages that have anything used in them. So, if you call it, allocate something small on the heap and then call it again, then it will often return the same value the second time. One really "interesting" thing I found was that the other vessels in a save do have a really big impact on memory allocation rate. I have a save containing 4 reasonably large stations (2 of 300+ parts and 2 of 700+) and flying one of these "obviously" results in a considerable rate of memory allocation (e.g. anywhere from 8 to 18 MB/s) so I launched a Kerbal X to a ~200 km orbit and deorbited the booster but the memory allocation rate was still at 5 MB/s. I restarted the game a number of times and went back to the, now very simple, vessel and it was still doing 5 MB/s. I then created a copy of the save and terminated the 4 stations and when I then flew the simple vessel the allocation rate was "only" a couple of hundred KB/s.

I assume you realise that your list from RealFuels has a lot of duplication, e.g. pentaborane is listed 7 times, hydrazine 10 times... The only possible conflicts I see in that list are the various ones beginning with E. Ethanol75 would be avoided by including numbers as well as upper case letters and can't see any point in trying to maintain a list of exceptions as other resources could be created at any time. Mind you, I don't really see the point of the whole thing, does anyone create enough different vessels all with similarly constructed names, that this would actually be helpful...?

I don't expect you'll find the 1.1 pre-release sub-forum at all because it was hidden a short while ago. Some threads were preserved (moved into other sub-forums) and others can probably be located if there is a good reason but you would have to ask a mod (probably best to ask in the Kerbal Network sub-forum for a moderator to help you out).

Well, it looks like this is the significant error though there isn't any obvious link to your mod: FileNotFoundException: Could not load file or assembly 'System.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. This is happening at the beginning of the flight scene, presumably when KSP tries to actually create your KSPAddon. That is basically, exactly what I meant though you will probably need to use whatever UI there is inside MonoDevelop to make sure the string gets set to the correct value. I use Visual Studio so it is probably a bit different but, in that you right click on the "project" in the solution explorer and hit "properties" to get the general project options where this is set.

There is a section fairly near the start of the log that shows the loading of the various plugins. Your best bet is probably to upload a complete output_log.txt/player.log so we can see what is happening. One possible cause, given you say the real mod works, is that you're targetting the wrong version of .net it needs to be version 3.5.

Well, I think it was probably intended to be accurate but a flaw in how it is implemented means it actually displays the number of rendered frames per in-game second rather than per real second. Basically it will bottom out at (1 / <max physics delta-time per frame>) fps, if the framerate is below this value then in-game time is stretched and the display just shows the limit.

Are you sure you didn't mistype this comment or change something drastic in 1.4.3? I'm sitting in the main menu on a machine that only manages 20fps and with the graph open I see virtually no garbage being generated. The difference between the window being open and closed is only 4-8 KB every second (with just this and my own MemGraph mod running there is approx 28KB of memory allocated per second). This is much lower than I expected as 20fps * 900B = 18 KB for your window. However, if I show the fps overlay (and only the fps value, the memory ones are fine) then this jumps a huge amount to between 700 and 1000 KB per second (and this is clearly visible in your graph as well as mine). I've had a quick look at the code but I can't see anything obviously wrong. I didn't dig into the ConcatFormat stuff because the graph window uses it too and doesn't suffer from the problem. Edt: Incidentally, I've now released the MemGraph mod here:

There was still an unresolved issue similar to this between KER and RF in KSP 1.0.5 and, to the best of my knowledge, no-one has really looked into it since KSP 1.1 (mainly because RF has only recently been made compatible with 1.1). It almost certainly requires a tweak to how the simulation reads the current thrust/fuel consumption from the engines during flight.

I presume you aren't looking for "Buy a reasonable graphics card"? You could possibly try turning on the legacy shader stuff in the settings.cfg (you'd need to search for the details and hope they weren't in the pre-release sub-forums that are now hidden ). Also, the old tweaks to the ocean sub-division settings may also make a big difference...

The terminal velocity is not particular easy to calculate with FAR and is not particularly useful anyway. In previous versions, this and various other related readouts were disabled when FAR (or NEAR) were installed and I would have expected the same thing now but something may have got broken. I can't even say for sure that the terminal velocity (and related) calculations are accurate in a stock game, I'm not sure if they needed to be updated after all the aero changes in 1.0+ or if all the necessary updates were made. Terminal velocity really isn't a very useful stat since the atmosphere got so much less draggy... KAC and KER are not "creating" null exceptions, they are experiencing them, most probably because FlightGlobals.ActiveVessel is null. I will need to see the log to be sure but it sounds like Contract Configurator is having a problem which is causing the vessel to fail to load and, rather than they game noticing this, it just leaves you sat in the flight scene with no vessel active. The configuration of KER is stored in the various XML files in the mod's Settings folder and I believe they apply to all saves in the one install of KSP so I assume you actually mean how to import your huds from a different install of the game. If this is the case then you should be able to simply copy over most of the files from the Settings folder (don't include HelpStrings.xml as this is supplied in the mod download) though it should be fairly obvious which files control which things from the name and/or a quick look at the content. If this is not the case and you do really mean that a new save in the same install of KSP has lost your hud changes then I suspect there is some other issue going on and we will need a more detailed description of your problem, an output_log.txt, the saved games in question and, preferably, the contents of the mod's Settings folder zipped up...

Well, a float can only store 6 or 7 significant digits...

Perhaps, if you posted a link to your output_log.txt showing these errors, then someone might be able to help you.

On linux the file is called player.log and is in an odd place. See the how to get support sticky thread in this subforum for details of where to find it.

Can you supply a screenshot and an output_log.txt/player.log file please?

I can't do a detailed reply right now because I'm on my phone but you can change all the hotkeys in the settings file that should appear in the mod folder after it has run once. It should save the settings each time you leave the VAB/SPH and load them every time you enter.

Just a heads up in case you haven't noticed, there was an important fix made to the VesselSimulator code in the last couple of days. I was going to check in your source but couldn't find a source link in the OP that I can look at on my mobile.

Indeed, take my sig for example...

This issue affects some people so badly that they do not enjoy playing even in a stock game with a single vessel. They haven't just started complaining about this now, it has been a known issue since I started playing in 0.23 and has generally got worse in every new version. This is not surprising given the nature of the problem and the underlying cause, every new bit of code that gets written has the potential to generate more garbage.

The cause is not in Unity. The pauses are caused by the Unity/Mono garbage collection but it only runs as frequently as it does because KSP code generates excessive amounts of garbage. Allocating and discarding 120+ mb every few seconds is ridiculous. If this rate can be significantly reduced then the garbage collections will happen much less often and can also be deliberately triggered at points the user won't notice to reduce them still further. The truth is that it can't be fixed in a small amount of time regardless of what does or doesn't change in Unity. Some of the low hanging fruit (e.g. The resource system) can be addressed fairly easily but more significant gains would require an audit of the entire code base and considerable changes to many parts of it.

If the game managed to display any of the initial loading screen then there will always be a log file. There may not be a separate crash dump log but output_log.txt/player.log is always created and shows considerable detail about what you were doing.

VOID does use the KER vessel simulation code so will need updating once the issue is fixed in KER. MechJeb did use the same code for a little while but changed back to using its own code quite some time ago. The problem here is that jet engines changed in 1.0.5 to use a new fuel flow mode and none of the calculation mods are currently handling it correctly. It would be very helpful if someone could post a simple vessel (as few parts as possible) that clearly shows the problem. As for this not happening in 1.1.0, I suspect that the bug with the object pooling was masking the issue.

That's not really how it works. Unity decides how much memory to allocate for the mono heap and the collection runs when an attempt to allocate some fails because there is no space left. Only if the GC doesn't free up space does Unity ask the OS for more. Yes, that would be mine. The garbage creation and other performance issues with the resource handling are known to Squad and are the primary reason why they are planning to rework the system soon. Basically Squad do know about the GC issue, a related issue was mentioned in the change log for 1.1.1, but serious effort to address it will require a lot of work so they need to be convinced of the seriousness of the issue for a lot of people before they can dedicate the level of Dev resources it would require.

Logs, craft file etc?