rbray89

WOW! This is why I wrote this mod. I was hoping people would take the artistic side up, like what happened with universe replacer. Well done good sir.

What version of the mod are you using?

If you could provide the full log and version of texture manager that would be great.

Ok, updated the mod to avoid the crash due to memory usage at startup.

See: http://forum.kerbalspaceprogram.com/threads/55905-0-23-Release-6-7-Visual-Enhancements-Clouds-City-Lights?p=904225&viewfull=1#post904225

That's what I thought... until I just tried it out. No crash at all, and I'm running with a ridiculous number of mods. During loading never gets above 2.1GB. Before it would usually keep increasing until the main menu, at which point it would go down. I'll be uploading this release today.

hmm... i'll look into this, but with the number of problems people are currently having still, I like the idea of all the configs being easy to find, rather than to check in each mod's folder to ensure that they have a config or not.

The system is running out of memory. I'm looking into why right now. I think garbage collection may need to be forced. I have a heavily modded game folder that runs at the main menu at just 1.2GB, but it can get up to 3.xx and crash just as easily.

the problem is case sensivity. Fustek != FusTek. I am used to finding these in code

It should be.

You simply change the "MainTex" (or other texture name fields). Use the original layers as examples.

Ah. Will do.

If you could take a look at the test version and let me know if it works as expected, I'll upload the changes. The RasterpProp changes are ones I'm very interested in.

there is a new TEST release for those pesky 1x1 pixel images, WarpPlugin, and JSI https://github.com/waka324/TextureCompressor/releases/tag/2-13-test

Model nodes? Please elaborate. I'm not sure what you mean here.

Ah, OK. I'll be sure to add the exception in the next release.

So... We do know what texture don't have config files. I just compress those now. The real problem stems from GUI textures, and normal maps. If the texture is named ending in _NRM or has the normal map MBM bit flag set, then all is good. Otherwise, we have to know to convert it to a normal map and set the Boolean flags for the texture to let KSP know that it is a normal map. The only way I have found how to do this currently is in the logs. I've toyed around with trying to hook into the part loading to detect normal textures there, but so far, no luck.

Looks like it is a small bug on my end. Code to keep small textures from being scalled too small tried to make it really big by dividing by zero. I'll have a fix this evening uploaded.

I definitely considered it. I have been trying to figure out how to do it, but I'm not entirely sure it is possible.

Yup, the extra configs are basically ignored if you don't have the mod.

Hmm... I didn't see those in any of my logs. I'll have to look closer.

I updated the config list with a LOT more entries, and created exceptions for the gui textures I could find.

I'll go ahead and download all the mods and try them out. Once that's done, I'll add the configs.

That is about what to expect. It only saves about that much on a stock install. Glad to hear it is working out better for you. Let me know if that changes though.

I don't even know how... those are stock parts? Does that happen in the vab? Are you using aggressive or basic? Did you modify the configs at all?