Padishar

No, they really aren't, you just have to accept that KER only calculates the deltaV that each stage applies to the root part. If you decouple the root part from the remaining engines then all the following stages calculate as 0 (stage 0 in your first screenshot, click the All Stages button to see stages that don't generate any deltaV). The value for stage 1 in the first screenshot is almost certainly correct. If you change the root part to one that stays with the vessel (e.g. the command pod or probe core) then stage 0 should also show up. In any case, with KSP 1.2 being just around the corner and making significant changes to how fuel flow works, very little work is likely to be done on fixing issues with the existing deltaV calculation code because a significant amount of it is likely to be rewritten. Edit: incidentally, the reason for the odd looking numbers when you enable crossfeed is that initially the vector draws the fuel across the decoupler from the payload but it only has enough for 6s of burn. After this, the parts that get decoupled from the root no longer contain any fuel so they are treated as dead weight and the simulation stages to eject them. The stage 0 numbers are the Vector engine burning the fuel in stage 1 and it gives more deltaV because the top of the rocket is no longer attached.

The reason is more likely to be something simple like the root part of the vessel being in the part that gets decoupled. KER may not support enabling of crossfeed on decouplers properly but it should cope fine with a simple 2 stage rocket.

You may benefit a little but the 4k pages for the larger sizes can only hold a small number of blocks so the single block in each page wastes a larger proportion of the memory, e.g. for 1345-2032 each page only holds 2 blocks and one is used to keep the page allocated, so half of the memory is effectively wasted. It really depends on the pattern of block sizes allocated by your particular game which varies according to installed mods, the scene the game is in, how complex your save is and even things like which particular parts are used on your vessel. There certainly isn't a config that will suit all situations. I did do some work on tuning the padding to suit the current usage pattern but it's a tricky problem because the only way to determine information about the current usage pattern is by allocating and releasing memory to see what happens to the heap and this obviously affects the usage pattern itself. My current plan is to change how the config works so that the block size values set the "shape" of the padding allocated but have the total amount of padding controlled separately. This will make it very much easier to change it for machines with more memory and changing the block size values to better fit the usage pattern (e.g. if you somehow happen to know that your install allocates a lot more blocks of 145-176 bytes than usual then you would want to increase that value in the config) wouldn't affect the total amount of padding (well, not by much). However, this is still in the future and I've not got a lot of spare time at the moment so it will probably be at least a couple of weeks before I get around to it.

There is no part.cfg in that folder in the download. I suspect this was left over from a previous version, in 1.0.19.4 and earlier it was called part.cfg.

Seriously excessive perhaps, but, unfortunately, not unusual. The most important value is "Last" as this indicates how much memory is being allocated each second. In your case this is over 110 megabytes every second. Does the value change significantly if you close the KAC alarms window? A lot of the garbage is probably due to contract configurator, hopefully the author (or somebody) will be able to make some significant improvements to it soon. Exactly as @dr_evil said above (thanks).

That's ok, there are lots of quite experienced programmers that don't fully understand this stuff either. I explained some of it in this post: The heap padding basically creates a large number of 4k pages that only have a single block in, e.g. a 113-144 byte page will have 1 of the 25 available slots used but the other 24 slots free. The same is true of the other size ranges. So, some of the memory that you think is allocated is really allocated (it is necessary to avoid the GC discarding it again and losing the benefit) and the rest is the empty padding that is what actually increases the GC interval because lots of allocations don't cause the heap to run out of empty space.

Do you happen to remember which one of Roverdude's streams it was?

Hmmm, weird, I assume you're using the correct "Mod" key or the various other things wouldn't work but it's strange if it's only NumpadMultiply that doesn't work. Do the other numpad keys works, e.g. Mod-NumpadPlus/NumpadMinus to adjust the scale? Perhaps something in your window manager is trapping the key combination. Can you try setting some default KSP function to use that key and see if that works? Looks like another reason for me to get around to making the keys configurable. There's nothing specific I wanted to know about, just a general "does it work"? There isn't anything that should be platform specific but weird issues do sometimes crop up when you make assumptions like that...

As I mentioned in this post: ...on the previous page, at the moment you would need to modify the source and recompile the mod. I haven't got around to making the keys configurable yet, I've just been too busy with other things for several weeks... You're welcome. Yes, there are a number of posts in this thread that mention running with more memory. You would just need to adjust the padheap.cfg to suit the amount of memory you have though I recommend leaving a fair amount of headroom or Windows (especially Win10) may start doing strange things like memory compression. Anyone out there using this on Linux or OS/X?

Errr, have you been following the devnotes for the last few weeks? Squad are "fixing their crap". Have you read the first post in the thread? The scale shows the maximum value on the Y axis of the graph. It adds a new point to the graph each second (approximately). The value plotted is the "Last" value from the top of the window, which is the amount of memory allocated in the last second. The cur value is the current size of the Mono heap. The max is the heap size just before the last GC, the min is the heap size after the last GC. The R and P values are the number of "rendered" and "physics" frames during the last second. If you read various other posts in the thread you will see that the Contract Configurator mod can cause a significant amount of garbage. I would try copying your entire KSP installation, removing that mod and all the contract packs and then trying your save again.

Mod-End means to hold down the configured modifier key (on Windows this defaults to the left Alt key, on Linux it defaults to right Shift) and press the End key. You can tell if it does something by having the debug log window open (Mod-F2), you should see some output from MemGraph indicating the padding has been applied. Make sure you close the debug log window again as it generates a considerable amount of garbage. You must have a reasonable amount of free physical memory when you do it or it will cause the performance to suffer because the machine will start paging stuff to and from the hard disk continuously. If you have a large amount of free RAM then you can modify the numbers in padheap.cfg as described in various posts in this thread.

Glad you like it and it's working usefully for you. I've added a donate button to the bottom of the OP...

I would recommend something like imgur.com to upload images in future, the site you've used has a silly advert that completely obscures the image. Yes, your game is generating quite a large amount of garbage, did you have any specific questions. You may need to adjust the heap padding configuration (assuming you have a decent amount of memory) to get a better improvement in the stutter...

The UI deliberately doesn't have buttons because buttons in the old UI system tend to create excessive garbage. Mod-End means the End key on the keyboard with your configured modifier key (default of Left Alt on Windows and Right Shift on Linux).

There isn't at the moment (short of tweaking the source and recompiling it yourself) but I'll see what I can do. Probably just another little config file that contains the keybindings for the time being...

There is no such thing as KSP version 1.3. The latest version is 1.1.3.

Yes, this is basically how the stage priority flow mode works. It actually uses an internal part variable called "inverseStage". For things like engines and decouplers this indicates which stage the part is activated in but for fuel tanks it is set according to the number of decouplers between the tank and the root part of the vessel. For these sorts of vessels it is always a good idea to test the vessel on the pad to make sure the tanks drain in the correct order, e.g. you can hang the root part off a tall launch clamp (in stage 0). It can also be useful to mod the engine so that it has a much higher fuel flow rate so the tests don't take so long... I'll try to take a look at the decoupling of stage priority engines in the next couple of days.

Thanks for the feedback, it's looking better but there may not be much more I can do without more substantial changes to how the code determines when to fire the next stage. At the moment, the code builds a list for each stage of parts that prevent the next stage from firing. This includes any tanks decoupled by the next stage that contain fuel for the active engines and any of the active engines that are decoupled. It will then only fire the next stage once all the tanks are empty and all the engines have stopped. The problem that has been fixed was that the engines were drawing the fuel from the wrong tanks (usually all tanks together) so the tanks in the "don't stage" list never emptied until all the fuel was used on the vessel, then all the following stages have no fuel to burn and read 0 m/s. The problem with your vessel that decouples engines is that the 6 engines you decouple don't actually stop burning because they have access to the fuel in the other stages. I can probably fix this bit (without introducing other serious issues) by tweaking the rules slightly so that engines that use this fuel flow mode can be decoupled while they are still active (possibly only if there will still be other engines left on the vessel). I also suspect that at least one of your vessels doesn't actually arrange the staging in the same order as the fuel is drained which will be confusing things. Can you upload a zip with some of these vessels so I can give them a try (PM me a link if you don't want them public)?

No, the DLL files are not Windows specific, they are CIL (Common Intermediate Language) and are run by the Mono runtime used by Unity on all platforms. Just install it as directed in the thread and it will work fine...

This is only true if the GetEnumerator function of the object you are doing it on returns a struct type. If it returns a class type or an interface then it will cause garbage with any compiler. System classes like List<T> do return a struct but some of the KSP classes that are basically a wrapper around a List<T> return an interface (e.g. PartResourceList). These are on the list for fixing for KSP 1.2 though with that sort of nesting, you will probably get better performance with plain for loops (using foreach also requires the code to make two function calls to the enumerator object every time around the loop). Bear in mind that this will go through the list in the opposite order, which may affect what your code does. To go forwards through the list do: int count = <something>.Length; // (or .Count or whatever works for the object concerned) for (int i = 0; i < count; ++i) Doing that on every update is probably affecting the performance of the game quite considerably. You would be better off looking for another way to do what you are doing, e.g. by caching a list of the things you actually need to loop through and use relevant GameEvents to trigger updates of the list.

You may be able to do this in stock with two rovers, drive them close enough to start attracting but apply the brakes so they don't dock. Then destroy one of the ports with whack a kerbal (you might want to temporarily increase the magnet range to get a bit of clearance so you don't accidentally hit the other port too), or possibly decouple the port from the rover (though I suspect it needs the docking port to be deleted to go wrong).

While waiting for the next version of KER to be released you are welcome to try out this build of the latest changes. This includes the target lat/long, fixes for true anomaly being in radians and a fix to make stage priority flow engines calculate correctly (e.g. for multi-stage ion vessels). Simply download the file linked below (after making sure you have KER 1.1.1.0 installed first) and extract the DLL from the zip into your GameData\KerbalEngineer folder. It will display "(Pad)" or "p" after the version number to distinguish it from the current release. KerbalEngineer_1.1.1.0p.zip

Yes, I've been busy developing my MemGraph mod to both help diagnose garbage issues and to reduce the stutter, and also then helping to track down some of the major offenders in the stock game and in various mods. KER also generates excessive garbage (though nothing like some others) but I've not started on addressing that yet. In other news, I've taken a look at this Xenon droptank issue and it did turn out to be a very simple thing to fix. I have submitted a pull request that fixes it and will post a test version of the latest KER code in the KER thread shortly.

You could try adding the -force-glcore command line option. It may work better or worse than the default, good luck...

Well, from the names of the textures being unloaded I would have to guess that the textures are being shared by multiple bodies but the OnDemand unloading isn't taking this into account. What textures does Kerbin actually use in that mod?