Other ways to reduce memory footprint?

[blackrabbit]

I'm aware of the standard ways to reduce memory when playing heavily modded KSP installs like Active Texture Management, -force-opengl, and things like that. I play a VERY heavily modded KSP mainly because I see a mod and fins maybe one or two pieces that would look cool or be cool in my game. However this requires installing the entire mod which adds all sort of other items I may not use. My question is does anyone have other tips to reduce the KSP memory footprint in Windows?

I've thought about going into the mod installs in my gamedata folder to remove unneeded parts and on some mods it's pretty easy and some mods it's not simple at all. Is there a mod tool out there that can remove individual parts that I don't want? I played with ModAdmin a little bit to see how well it would work that way. Also if I do remove a part should I clear out the Active Texture Management cache and let it do it's thing all over again so it has less items in it's cache?

I'm sure I'm not the only other person here that's wanted to remove unused parts from their modded install so I thought asking would get me pointed in the right direction. Thanks in advance.

[BudgetHedgehog]

My question is does anyone have other tips to reduce the KSP memory footprint in Windows?

Hack it to run x64. Aside from that, nothing. There's Autopruner that stops the game loading things you already have procedural versions of, but aside from that, you're going to have to dig into the mods files. But that said, if the mod turns out to be complex and there's texture sharing going on with the different parts, there's not a lot you can do. The author has already done as much as possible to remove RAM overhead for you (thinking of the B9 HX parts - they all shared one texture or something so impact was negligible). If you want to reduce it further, you end up removing textures needed by the parts you want, which is what you don't want to happen. I think the KSO mod had just one file with all the different textures on it and then each part referenced a certain section of that file to use - there's no way you can change (save for loading the model itself and changing it there) or mod it to remove textures that parts you didn't want referenced. The upside of this kind of texture sharing is there's no duplicate textures, and that DOES increase RAM usage (a few versions ago, I think stock KSP had about 200MB or something of literally identical textures loaded. Remove them, nothing changes except for lower RAM usage).

TL:DR - first two sentences.

[blackrabbit]

Thanks. I kind of figured this would be the answer I got. I guess my best option would be to have different installs with different mods. Currently the two main mods I use for parts are the FUSTek Station Parts for space stations and USI MKS mod for bases. These two mods together eat up a .... ton of ram.

[Tynrael]

If you poke around the Asset files to see what textures are being used you may find a large number of texture resources that you do not care about. Combining this with parts in the GameData\Squad location that you do not care about, you could use TextureReplacer to overwrite the unwanted textures with tiny blank textures that use bytes of RAM instead of kilo or megabytes. There are hundreds of textures used, many that I have never seen and some that exist 6-9 times as the same exact texture with different names. For a time I thought about brute force dialing in what I did not feel was needed to reduce the memory imprint by a few hundred MB so I could play 32-bit, but the reality is with mods I would still be adding more than I could free up and it would be a time intensive task to map out the textures to even see which ones I did not want. The nice thing about temporarily overwriting these files with TextureReplacer means that when the game updates you won't lose your changes, like if you manually culled the Squad folder. I never use IVA for example, I currently overwrite those textures and all of the stock planets (I'm using new textures for those).

Given the option of playing with poor performance with midrange textures in openGL, spending unknown hours trimming the stock game, or using high resolution textures in x64-I went with 64-bit. I think with time I could cutout about 250MB from the stock game that would not impact my gameplay at all, but I'm using over 5GB of RAM now so that wouldn't balance the scales. It may be worth checking out the 64-bit version, it is labeled as unstable and not supported but it seems almost everyone who uses it has better performance and overlooks the few known inconveniences. It is probably assumed x64 is the problem if you are using x64, but if you also have a 32-bit install to check against many problems will end up being universal.