rbray89

All textures will always be "handled", that is, cached, but not resized unless there is a config for it.

Ah, well, it is possible (though unlikely with PF) that files are being re-used from elsewhere... What can happen is that the texture hash matches another texture perfectly, and it will re-use the texture in memory instead of loading it separately. You can uncomment the DBG=TRUE line in the main active texture management config file, and then re-upload the log. That should be able to give us a better picture of what is going on.

I actually meant the planet factory config for ATM, not the PF mod config Are there any textures in the Planet Factory folder in Gamedata? IIRC the the textures/configs are actually installed in StarSystems, but I could be wrong. ATM should cache ALL textures that have png, truecolor, tga, mbm and jpg extensions regardless if there is a config for them.

We'll need the contents of your PlanetFactory config, and ideally, a screenshot of your Gamedata folder. Textures should be cached regardless of weather or not there is a config file available. Also a screenshot of the cache directory would be beneficial.

look at other mods that DO modify those textures: Texture Replacer, and EVE Overhaul.

ATM Can't do that... those textures are not stored on disk as images, they are in the assets file.

So it looks like this is a win-32 issue (possibly with mono/unity runtime), and I don't think I can properly resolve it.

And I'm still looking for feedback on the beta: (no need to update cache) https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-4Beta

I can't imagine any reason why ATM would induce a memory leak. I know stock KSP seems to accumulate memory over time though. - - - Updated - - - There is no config entry for texture replacer, so not likely.

Hmmm... I'm afraid I may not be able to help then... I assume that the 32-bit version of windows doesn't like me allocating the large buffer array to manage the textures (a worst-case scenario of a 8k*8K RGBA32 texture with mipmaps)

It was a really good suggestion. Once it gets out of beta, your name will go into the credits & whatnot

Looks like you didn't install it properly. You are missing the config files.

Would you be able to change the layer it is on instead?

I edited the OP to clearly state: If you have any issues, we will need your output_log.txt file from KSP_Data folder. I will also need KSP version, window/linux/mac version and architecture, and memory size. Please don't post an issue without it. I will act as though you don't exist if you don't post this info. I'm just tired of asking the same questions over and over, so if you don't have the info, you don't exist from a support standpoint

Alright: So I may or may-not be able to help with the HEAP issue. New Beta: https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-4Beta It includes hashed texture re-use to save a bit more memory (64Mb on stock!), and an option to wait for operations to complete before initializing more tasks. To try and combat the issue, in the ActiveTextureManagerConfig.cfg file, add another option: "WAIT = TRUE" eg. ACTIVE_TEXTURE_MANAGER { DBG = TRUE ###Section for global settings would become this: ACTIVE_TEXTURE_MANAGER { WAIT = TRUE DBG = TRUE ###Section for global settings

Whenever someone mentions breaking workflow I can't help but think of XKCD: http://xkcd.com/1172/ I don't want to judge, but MS has officially dropped support for XP... Eventually you will "have" to upgrade

I'm really curious... Why the ancient windows versions??? XP and 2003 Server Edition? Heck, even a LiveUSB linux version would probably be a nice update for you

Yeah, ATM and TR seem to be at slight odds, though I'm not sure why at this point.

I just checked them. Couldn't find the windows version or the installed ram, or processor count. Would have been much easier had you just placed them here. KSP does have some info available: AMD Radeon HD 6290 Graphics Vendor: ATI VRAM: 1011 MB (via DXGI) This tells me you are running with an integrated graphics chipset with shared memory on what is likely a laptop. I will assume that because this is an older chipset and the username "student", you probably only have about 4GB of RAM so with the system, and graphics taking up RAM, you won't have much left to actually run KSP, let alone the caching mechanism. Try closing EVERYTHING but KSP, and try that, you may have more luck.

It is just a matter of opening up the config files (or creating them) and specifying what operations should be done to them. EVE already has one, you can base it off of that (BoulderCo). The cache is in ActiveTextureManagement. IIRC it is called textureCache. The cache will have the same hirearchy as the original, but again, deleting the cache won't help you. You also failed to post your output_log.txt file that I explicitly ask for in the OP, so if you want any further support, I'll need that file.

I'm afraid that Windows XP 32 will only let you go up so far in memory addressing, and the Pagefile won't help you at all. If I were in your situation, I'd be considering replacing your XP install with Linux.

How much memory do you have on your system? Is your graphics card integrated or dedicated? If it is integrated, then it likely borrows from your system memory, so if you have 4GB of Ram, a LOT of it is going into graphics memory.

That won't likely help. This (as I recall) is one of the symptoms when you are at the memory cap. Are you using Aggressive or Basic?

*AHEM* I still need this information. The log indicates you may not have enough RAM to use the caching mechanism. You may have to kill all other things when running KSP (browsers, power point, word, etc.)

Right now, my assumption for the errors is that KSP (mono) doesn't like me allocating thread objects that are processed, and we will likely have to scale back on them, either eliminating them entirely or only creating them as jobs are freed. - - - Updated - - - Did you restart KSP after the long initial load?