Padishar

Are you sure about that? Perhaps, based on what happened to my thread below, he should have suggested that you lock it to "avoid confusion" rather than "because he asked you to"... I'm not actually asking for it to be unlocked as I'm not taking up development of it again just yet (the last version I built for 1.2.9 still seems to work fine with 1.7.3, I've not played any versions in-between).

Just change the total line at the end to be the number of megabytes you want to use, e.g to use 4GB change it to total:4096

Because there is a bug in KER's handling of RealFuels engines that no-one has got around to fixing yet. You don't unless you know a reasonable amount about KSP mod development using C#, in which case you work out where the problem is in the mod code, fix it and then submit a pull request on github...

Well, you should definitely see the Cur value in the MemGraph window jump when you hit Mod-End. Are you using the End key on the number pad (on the 1 key), a laptop Fn-based End key or a real End key (it should be this one though the laptop style one may work)? If you can't get it to work then you can edit the key binding in the settings.cfg file and change it to a different key (there is a post in the thread somewhere linking to a Unity documentation page that lists all the different key names). If you are running mostly stock and have lots of free memory then you can also increase the total line in padheap.cfg (though this shouldn't be necessary to see an obvious improvement).

Only by removing them and seeing if the behaviour stops. Your min is 814, max 831, so the GC is running after only allocating 17 meg and your game is currently allocating about 4 meg per second (that is what the graph shows) filling the 17 meg in about 4 seconds. Try activating the heap padding feature, it should improve things considerably (assuming you have some free memory to play with)...

Yes, it was an intentional change. See the release post of the latest version here: There should be a fairly obvious setting in one of the usual places...

There is a fairly high chance that the behaviour has changed at some point since 0.23.5 but I don't know for definite. @Claw hasn't been around on the forum for quite a while but it should be quite easy to run tests to confirm the rules (think along the lines of rovers with docking ports to make the tests easier)...

To stand more chance of the log being useful, please click the KER Settings button and then click the Verbose simulation log button. This should add a whole lot of log output ffrom the deltaV simulation code.

You can change the vesselWindowX value in the BuildOverlay.xml settings file.

This. Cybutek already rewrote the UI code when v0.6 became v1.0 and it won't be a trivial task to change it over to the new UI system.

Sorry for the lack of activity here. Anyone know if this actually works in 1.3? Given the simplicity, it stands a reasonable chance and I would probably have released an update for 1.2.9 if it didn't work in that... I do also need to fix the issue in the .version file so I will try to get a 1.3 specific update out fairly soon...

You're welcome. Have you followed the advice/instructions in the first post (mostly about needing a decent amount of free memory)? Nothing is remembered across a game restart so just restart KSP and don't hit Alt+End. If you want any, more helpful, advice then you will need to provide some details of your machine and KSP install...

Why did you bother when the version I built for the 1.2.9 pre-release works fine in 1.3? Glad to see you're still around... @cybutek is the author of this mod. Actually, he may as well just get rid of it as my version, while unofficial, is made by a significant contributor to the mod, is already marked as different to the official release and is confirmed as working in 1.3...

Or even, at all... Having said that, I'll try to get an unofficial build up for KSP 1.3 sometime over the weekend... Actually, have you tried the version linked in this post:

Yes, but in the linux and Mac worlds it is different keys...

Are you holding down your configured "modifier" key?

I believe that's an error from Kerbal Konstructs (?) when KSP has got into some dodgy state in some way. I've not looked into it in any detail though as I don't have any reason to believe the problem is caused by KER, sorry... You're welcome...

Can you find the cfg file for that part and have a look at what it says the mass is?

There is no reason I can think of for any amount of padding to increase the GC in the way you describe. The heap min, cur and max values in your first screenshot aren't consistent with those in the second screenshot (the second one makes sense given what you describe but the first ones are all 4050-4099, which doesn't make sense if 1024 MB of padding was added and then re-added). Any chance you could run the first test again but take a screenshot before applying the padding and a little while after? Incidentally, for anyone interested in the KSP 1.2.9 pre-release, MemGraph 1.1.0.3 appears to work correctly without being recompiled. I will probably release a new version once 1.2.9 is officially released but it can be used in the meantime...

For anyone wishing to use KER with the KSP 1.2.9 pre-release, I have put together a build that seems to function reasonably well. This is built from the test129 branch on my GitHub. The only changes, so far, from 1.1.2.8 are to add the version suffixes. Download KER 1.1.3.0p from my DropBox (only for KSP 1.2.9 pre-release). I'll try to find a bit of time to catch up with what's been happening for the last couple of months and also try to contact @cybutek to find out if he is still going to be active.

@Amechwarrior, thanks for the report. It will take a bit of looking into, though I'm not sure when I'll be able to as I'm very busy with other things at the moment (I haven't even installed 1.2.9 yet)...

Have you set up a maneuver node?

Yes, there are currently some issues with how the simulation code is handling RealFuels engines that make it pretty unusable and I've had too much other stuff going on to find the time to look into it yet (I've hardly touched KSP in the last couple of months).

It basically releases the old padding and allocates the padding again. This may result in there being more padding available as some of the original padding will still stay around due to other memory allocations. They are counts of the number of rendered and physics frames that happened in the last second (approx.). So, R is basically your FPS and P is a measure of how much time is being slowed by the game (50 means it is running at real speed, 25 means it is running at half real speed). The two columns would be "size of memory allocation" and "proportion of total padding created for blocks of that size". Memory is allocated in 4kB pages which can hold a certain number of allocations, e.g. if the block allocated is 8 bytes or less, it gets put in a 4kB page that holds blocks between 1 and 8 bytes, if a block of 123 bytes is allocated it gets put in a page for blocks between 113 and 144 bytes. The padding works by deliberately allocating a single block from each 4kB page so there is lots of free space still unused but the page can't get freed because it always has one block in use. Each row in the config sets the amount of the total that is used for that block size so, with the default settings, the total of 1024 MB is split equally between the first 17 block sizes, making ~61680 kB for each size of block so 15420 4kB pages get allocated for each block size. Changing the first numbers makes no difference, they are just labels, the block sizes are defined by the Unity/Mono memory allocator. If you changed just one of the lines (e.g. the first one) to be 4 instead of 1, then 4 times as many blocks would be allocated for that size than the others. As there would now be 20 weight in total, the 1s would represent 13107 pages and the 4 would be 52428 pages. So, these lines allow you to set the "shape" of the padding without needing to do the calculation of page counts manually. I assume you have quite a complex savefile (lots of ships, and/or big ships) to be getting bad stutter with just those mods. I would expect the default padding to make an obvious difference, what does the Last value say (and the graph itself, which is just of the Last value)?

Mod+End isn't a toggle, it simply causes the padding to be set up according to the values in the padheap.cfg. Once the padding is applied it can only be totally removed by restarting the game. However, changing the total value in padheap.cfg to 0 and hitting Mod+End again should remove most of it within a few cycles of the garbage collector. The various descriptions are a bit technical but configuring it is now very simple. Just run KSP normally and get into a situation where you get bad stutter, Look in task manager to see how much free physical memory you have. The only thing you are recommended to change is the number on the "total : " line at the end of padheap.cfg. Set this to the number of megabytes that you want it to use for padding. If your free memory is under 3 GB or so then you probably shouldn't increase the total value much from the default or you risk the game crashing (or the performance dropping through the floor due to virtual memory thrashing) fairly soon due to the tendency of KSP to use more and more memory as time (and scene switches in particular) goes by. If you have a large number of large (in terms of texture size mostly) mods installed then you will have to use a lower number than of you only have a few mods. As for general use, there is a setting to automatically apply the padding early in the startup of KSP but, if you have to use quite a small padding value then I recommend you don't use it and, instead, just hit Mod-End when you get the stutter. The most important value in the window is "Last". This shows how much memory was allocated by the C# parts of the game and mods in the last second (approx.). To stand a decent chance of reducing the stutter significantly, this value needs to be reasonably small. If your mod load and the state of your savegame results in this value being tens of megabytes (or more) then you will need to allocate a lot of padding to get the stutter intervals to a reasonable length. Does this help? If you still have questions then please post some screenshots showing the graph window (with the scale adjusted so the graph isn't totally green) and give some details about the spec of your machine and your mod load and I'll try to answer any questions you have and/or give advice on what to do...