rbray89

Only if you want additional memory savings. - - - Updated - - - alright, sounds good. Thanks for your cooperation

Please read the front post with the big text that says "If you have any issues, we will need your output_log.txt file from KSP_Data folder. Please don't post an issue without it."

Ok, could you provide the one with 4.1 now? (I Know, you would have to re-cache...) I think I have an idea of where the issues might be stemming from, but not 100% certain.

That is exactly what I'm trying to figure out. Can you post your output_log.txt file for me? Is it possible you accidentally downloaded aggressive? or there is still a config in ActiveTextureManagement? (it should have moved to BoulderCo)

No... you would have to create a folder entry for every folder in GameData that doesn't already have a config.

Well... TBH, it shouldn't save that much memory. The only difference would be that normal maps would not be compressed. Everything else should be.

Sorry, but this doesn't really tell me anything. I need your output_log.txt file to be able to do any sort of diagnosis. Pretty much, though the normal map resize is the basic config. Aggressive will half all textures. CPU is either overheating or PSU can't supply enough power. 4-2 loads the cores up to 100%, so your computer needs to be stable at max usage.

no... textures *should* recache automatically, aside from those that had the size issue.

Actually, now that you mention it, I'm not so sure about 3.2. I recall that 3.2 was where people started having issues though.

I don't think you should need to. However, trying it and reporting back would be good to rule it out.

No parts should be hidden. - - - Updated - - - 3.2 is the cap for KSP apparently. Aggressive will make a huge difference. Sounds like you have a few too many mods to run with basic.

All textures will always get a cache file. It was faster/easier for me to do this than not. It should also mean no memory leaks in loading other formats.

It was a default value in the dll. I'll have to add a config item for this I think. In 4-1 all textures were compressed to dxt regardless.

Also: In KSP.log or output_log.txt there should be lots of information about the loaded textures. Looking at those should help people discover where they can trim memory or add configs.

no... though, that makes me think about what happens with unhandled mods... Could be where the additional memory usage is coming from. could be anything depending on the mod. Some use resource maps or read to get information (eg. EVE uses them as a map for volume cloud spawning). OS? Machine specs? You may have to delete the cache for those files with the update to 4-2.

Vector2 doesn't work for me, and color is supported as well. Any classes that are added with the persistent tag and have persistent members are converted to a config item.

With 4-2? did the same thing happen with 4-1? what if you run without ATM? Have you run with Astronomer's Visual Pack before? That one I'm not sure about. Likely resource maps and similar things. You would have to find the configs that say "compress = false" to "compress = true" - - - Updated - - - with 4-2? do you have logs?

That is a log entry I forgot to remove. It indicates processor count.

Memory usage might be up a bit for two reasons: 1) uncompressed textures are supported again. I had forgot about them during DXT caching, so they would always compress. Now, if the config says they shouldn't, they wont. 2) Very Large textures will actually load instead of being skipped (hence the missing clouds) Since these textures are HUGE, they add a good bit to the memory usage (EVE Kerbin 1 would use 8k*8k bytes... so about 67MB in memory. Astronomer has similarly sized textures too...

Get it here: https://github.com/rbray89/ActiveTextureManagement/releases/tag/4-2 Also, Sarbian is awesome, he implemented the multithreded portion of the update. Give him all the rep!

Just the large textures... good news is that on my quad core machine, it only took 5 minutes as opposed to 30.

Alright, I discovered what the issue was... I'll be releasing a new version shortly that should fix the issue, and re-add the ability to choose uncompressed textures.

basic or advanced? what OS?

Ah... hmmm... Then I'm not sure... Are you using aggressive or basic?

Awesome! Now we can tell people to do this before installing I think. Tried to design it so it wouldn't need to be this way, but I guess that didn't work out. Sounds good! Yeah, I think I'll drop the Nvidia one. Between that, and the fact that the Nvidia port isn't *quite* operational yet, I think libsquish is the way to go. I could see that. Those textures are massive. I think the suggestion of multi threaded compression is a good one. Especially if it works No worries Though part of me would wish that squad would implement some of this on their end The big reason I choose MIT license is so that others can use my code in commercial products (Squad, if you are reading this *HINT* *HINT*)