rbray89

it *Can*. If you are using the basic (not aggressive) config, and have lots of png based textures, it will generate them when previously they were not present.

Not sure yet. I don't have a Jenkins server, so I probably won't do that. I'll probably just post updates as I make progress.

I'll just keep them in this thread as DEV updates.

Thanks, Will do.

Right. I have a small bug to fix, and then I'll post a link to the next iteration for you to try.

The Negative "gain" is usually due to mipmap generation when there previously was none, or a conversion to ARGB32 for normal maps.

Hmmm... that is VERY odd. I'll have too look into it. There should be a Button for every mod that you have a config for, and an additional "unmanaged" button for mods that don't have a config. When selected, the button should indicate the amount saved per folder, with a display below indicating the total amount saved. The weird thing here is that only the squad folder showed up. WHY? Hmmm... very interesting/confusing. I Just looked and found the reason why you get the indexOutOfRangeException, As for why you only have the one folder for squad I don't know. Do you have any of the "default" mods that there are config files for?

Looks like you are running out of memory: DynamicHeapAllocator out of memory - Could not get memory for large allocationCould not allocate memory: System out of memory! Trying to allocate: 178956976B with 32 alignment. MemoryLabel: Texture Allocation happend at: Line:388 in Memory overview May I recommend: http://forum.kerbalspaceprogram.com/threads/59005-0-23-Release-2-15-Active-Texture-Management-Save-RAM-without-reduction-packs%21

hmmm... If you want, you can try an interim build out, just replace the dll in the folder with this one (click "raw", it will let you download it): https://github.com/waka324/TextureCompressor/blob/master/GameData/BoulderCo/Plugins/TextureCompressor.dll has the GUI that will display on the main menu and allows you to check how much memory should be saved by each folder.

Yeah, the config in the next update will now use altitude, as the "radial ratio" was a bit difficult for people to use.

Yeah, One thing that always bugged me was that the clouds didn't "run" into the mountains. Even when they should. This will fix that.

My guess is that the config isn't being overwritten properly if it reports the same ammount. The next version will be adding a gui that pops up after loading to show how much memory is being saved and where.

Do you have the log file?

Looks like the mod is running correctly. Check your memory at the main menu using a resource monitor. Could be that you have more ships in memory, or some other mod is adding to the memory usage.

Were you always using the Basic config? That's what it looks like you are using.

Would you be so kind as to post the log please? That is quite suspicious.

You are running out of memory. Looks like you are running with an outdated version of this mod.

What mods do you have installed? I noticed some issues with moduleManager and buggy mods that did something similar once. I re-installed the mods from the forums and that seemed to fix it.

Did you modify any of the configs at all?

Errmm... Hmm... City lights works, but the clouds don't? Usually when something like this occurs, I recommend trying to remove all traces of the plugin and perform a clean install. The folder tree should be something like: KSP_mac/GameData/BoulderCo/...

I like this. Maybe something that allows users to configure mods without altering configs? Sure. Next release.

You can check the logs, or look in the cache folder to be sure. Make sure that the name matches the folder exactly. The system is case sensitive.

Merging will work just fine.

1 - I am actually not sure on this one. I'm not sure how squad performs the scalling. I assume it is through the unity render engine, which would scale textures in render, rather than in memory. I would probably recommend using my mod to manage textures, simply because I know how well the scaling algorithm works. 2 - I do believe the settings would stack. 3 - Yes, this is what I would do. The KSP settings would be applied on top of the mod settings. 4 - PC SYSTEM memory would be used. The graphics card driver would allocate more memory from the system in a driver and hot-swap it in. This of-course is MUCH slower than on-board graphics memory. However, the algorithms tend to keep textures in memory that are being used. Ie. You could a gigantic ship in LKO, and JUST be at the memory limit of your graphics card. If you switch views to a station orbiting Jool, the Jool texture would be loaded into memory, and likely bump the Kerbin texture out, so it would have a one-time frame hit while that texture was loaded out of system memory. B - It would free up a bit of system memory, but you probably wouldn't notice it, and it wouldn't effect the number of mods you could use. 5 - No, there are no real differences in loading times. All of KSP's textures are loaded into memory at-runtime. That is why it uses so much ram. However, smaller textures and compressed textures (DXT format) do RENDER faster, so frame-rate is positively impacted. MipMaps also help with this too.

Most user's won't need to touch or modify the configs. It is only if you need to use advanced parameters to handle additional packs. WarpPlugin is a good example of a config. BoulderCo/textureCompressorConfigs/textureCompressor.tcfg is thoroughly documented with examples.