NasenSpray

Nevermind, I expected that to happen after you told me about my oversight Yes, it's only the source code of 0.1. Whom should I contact regarding questions to those rules? I originally planned to use helper libraries developed at my job that I'm only allowed to use/distribute statically linked/in binary form in non-commercial projects. As it stands, your interpretation of the rules seems to prohibit that, right?

Exactly how much do I need to provide? Am I forced to include the source code of external depedencies like the native dll?

What does it say where it loaded ATL from? [LOG 23:32:38.572] Load(Assembly): /ATL [LOG 23:32:38.573] AssemblyLoader: Loading assembly at C:\[...]\KSP\GameData\ATL.dll The first line, is it the same for you?

That's odd... you're using Windows and 32-bit KSP, right?

Your directory structure should be If atl.log is missing that means that it couldn't find or load native.dlz. You're right, the ordering determines if the block is 4 color or 3+1. Even if DirectX detects it correctly, it's still premultiplied alpha aka. transparent black. That would result in ugly texture filtering artifcats... What came after the "[ATL] Processing ... duna1" message in the log? There should be an exception, I hope? I'm going to add a folder based exclude list soon as a stopgap meassure. I really don't like the thought of mod specific configuration files, though. Part of my motivation for ATL is the curiosity to find out if it's possible to do without them. I like reverse engineering, I'm already manipulating the runtime You don't need to do a rebuild everytime you alter anything, except when you modify already cached textures. ATL looks which textures KSP is going to load and then loads everyone of them it has in it's own cache. That means that new textures are still loaded by KSP and removed ones are simply ignored. The database is never reloaded because as you said, that breaks MM and other stuff. I don't know if it's ever going to be an "install and forget" experience. Users should be aware of what ATL does because I don't want to break stuff silently. And besides, it's still alpha

I actually don't know for sure how DirectX handles ARGB->DXT1 conversion. I hope it ignores alpha because DXT1+1bit alpha means you only have 3 instead of 4 colors per 4x4 block. Edit: ATL is going to do the conversion itself soon, just to be sure.

Thanks for the update, that sounds really strange. I'm pretty sure your theory is wrong, though, and would really appreciate it if you could send me your log. Btw, "unloading textures from RAM" means deleting the extra copy Unity keeps around for convenience. Unity depends on this extra copy to provide texture manipulation on-the-fly, but that feature isn't used by many mods. Textures loaded by ATL don't have this copy to begin with and that's the reason why EVE and co don't work correctly with it. EVE for example uses texture lookups to determine cloud density/color and right now I'm just returning slightly random light gray values (nobody wants black clouds )

It's possible in theory but I haven't meassured it and wouldn't expect it to be noticeable either. KSP is severely CPU-limited.

I need your ksp.log/atl.log files, there are different possibilities. Are you running at memory limit? Thanks! You can also check atl.log after a rebuild if you want to know which textures got their alpha channel removed. But you may need a second rebuild because ATL doesn't analyze textures that were already compressed, i.e. by other mods (the second rebuild reloads everything from disk)

There should be a window at the upper left in the main menu. If not, could you please send me your KSP.log file?

Does it persist when you rebuild the cache?

Thanks for reporting, fixed in 0.1.1

Wow, thanks for the help! EVE is an issue because it needs to (afaik) modify textures on the fly. Unity's way of providing access to textures is to hold onto a copy of the raw texture data. But I'm loading the textures directly using DirectX and hand them to Unity as external textures. The only solution is either to exclude every texture from ATL that needs to be modified or to trap calls to the texture manipulation functions... the former needs config files that are a pain in the ass to maintain, but the latter can be done by replacing Unity's internal calls and should work universally.

Every mod that needs access to texture data (LoadOnDemand, EVE etc) won't work with ATL right now because Unity doesn't care to give access to DXT compressed textures even though they are still in RAM. I'm working on EVE and TextureReplacer (that will take some time, I need to hook Unity), but I don't think LoadOnDemand will ever work.

Thanks for reporting. I hope I can solve that