[WIP][0.23.5] AlternativeTextureLoader 0.1.4 | Temporarily suspended

[Space_Kraken]

I have a bug report:

[velve]

Interesting will be keeping my eye on this, until most of the bugs are squashed.

ATM does not do enough for me, it sure helps but im constantly riding my Vram to the limit and anything extra to ease that is a welcome addition.

[NasenSpray]

I have a bug report:

https://mediacru.sh/IbgDiq-CJIK8.png

https://mediacru.sh/lMyOH5mxdCBQ.png

https://mediacru.sh/2MOgZfw9ut5b.png

Does it persist when you rebuild the cache?

[Gaalidas]

Interesting mod here... however I have run into some confusion. I installed the mod, ran the program, and faced my usual super-long loading time, which I expected on the first run with this mod. However, I am finding no way to set anything up, or rebuild a cache. I can find no GUI, or an extra button in the toolbars, or anything that would give me any kind of hint. I admit that it is easy for me to miss something obvious in a readme file, which I tend to habitually ignore (the down-side of becoming a true geek) so... anyway... confused!

[NasenSpray]

Interesting mod here... however I have run into some confusion. I installed the mod, ran the program, and faced my usual super-long loading time, which I expected on the first run with this mod. However, I am finding no way to set anything up, or rebuild a cache. I can find no GUI, or an extra button in the toolbars, or anything that would give me any kind of hint. I admit that it is easy for me to miss something obvious in a readme file, which I tend to habitually ignore (the down-side of becoming a true geek) so... anyway... confused!

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

[Hexx]

Whenever I try to rebuild the cache it says: "failed to open cache file", any ideas?

[NathanKell]

Very intriguing.

The killer feature, for me, is the "use DXT5 only when necessary" bit--no sense in compressing pure-white alphas to DXT5.

[NasenSpray]

Whenever I try to rebuild the cache it says: "failed to open cache file", any ideas?

I need your ksp.log/atl.log files, there are different possibilities. Are you running at memory limit?

Very intriguing.

The killer feature, for me, is the "use DXT5 only when necessary" bit--no sense in compressing pure-white alphas to DXT5.

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)

Edited July 1, 2014 by NasenSpray

[problemecium]

Will this improve framerate? Because my computer has tons of extra RAM and doesn't take terribly long to load, leaving my only serious bottleneck to be FPS.

[NasenSpray]

Will this improve framerate? Because my computer has tons of extra RAM and doesn't take terribly long to load, leaving my only serious bottleneck to be FPS.

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.

[Gaalidas]

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

I think I know what's happening here. Texture Replacer has a feature that unloads textures from RAM (or something like that, it all makes really no sense to me) and things like this which render menus and such are affected by this feature. As a result, custom menus will sometimes collapse into non-existence.

However, I am unsure if this is the culprit considering the window is showing up, it's just so freakishly tiny that nothing is appearing inside it. It's literally just a tiny little box, about as large as the screen-space needed to render a capital letter such as "H" in it. I plan to dive into my ksp.log to see if anything helpful shows up (or anything I don't already understand.) I'll keep you updated.

[NasenSpray]

I think I know what's happening here. Texture Replacer has a feature that unloads textures from RAM (or something like that, it all makes really no sense to me) and things like this which render menus and such are affected by this feature. As a result, custom menus will sometimes collapse into non-existence.

However, I am unsure if this is the culprit considering the window is showing up, it's just so freakishly tiny that nothing is appearing inside it. It's literally just a tiny little box, about as large as the screen-space needed to render a capital letter such as "H" in it. I plan to dive into my ksp.log to see if anything helpful shows up (or anything I don't already understand.) I'll keep you updated.

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 )

Edited July 2, 2014 by NasenSpray

[NathanKell]

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)

Wait, are you *stripping* alpha? I thought you were compressing to DXT1+1bit alpha, which can be done for the same price as DXT1 IIRC.

[gimpzilla76]

I am having a little trouble. I get the settings window and I am able to interact with it. Changing the settings does not seem to update the settings cfg file. And when I click on 'rebuild cache' the buttons grey out and nothing else happens. There is no atl log file created. I looked into the ksp.log file and this seems to be where things go wrong:

[WRN 19:45:21.859] File 'GameData/AlternativeTextureLoader/config.cfg' does not exist

[LOG 19:45:21.861] [ATL] Creating new config

[LOG 19:45:21.869] [ATL] Config init done

[LOG 19:48:52.768] [ATL] BUILD ALL

[EXC 19:48:52.772] MissingMethodException: Cannot find the requested method.

Any assistance would be greatly appreciated.

[NasenSpray]

Wait, are you *stripping* alpha? I thought you were compressing to DXT1+1bit alpha, which can be done for the same price as DXT1 IIRC.

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.

Edited July 2, 2014 by NasenSpray

[NathanKell]

I thought DXT1+1bit alpha detected alpha = 0 or 1 based on the ordering of the colors, but I see that in fact that just switches between DXT1-normal and 3color+1bit alpha. Well shoot.

[Gaalidas]

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 )

Alright, theory was completely and utterly false. I had the plugin installed incorrectly. Got that sorted out once I saw the error that said something along the lines of "could not locate dll-name.dlz in the expected path." Long story short... well actually short story made shorter, I moved it and it's working. New problem, and a possible solution.

So, as it begins to build its cache, it reaches that EVE texture that I have called "duna1" and then stalls. I actually get absolutely no errors to speak of, even in the logs (either of them) nor in the debug console, which I kept open during the entire cache generation process. so, I got to thinking about how Texture Replacer does its thing, and how in configs for that mod you can specify which pathways should be ignored when unloading the textures from ram. Could a similar override list be created for this mod as well, which would simply tell the mod to completely ignore certain textures either by name, or by a folder-path? That way no entry into the cache would be entered and no modification to the texture loading process would be attempted for the specified textures. This might allow for Texture Replacer to function as well as EVE, though there could be some extra complications when Texture Replacer users make use of the gamedata override feature, but honestly I find that just clutters things up anyway, so you could just warn users of this mod to not use that specific feature, much like the warning for users of that load-on-demand mod.

I will say this though, upon reloading my game the partially built cache already shaved off a bit of time from my loading process. Granted, it's only managing ~500 textures out of over ~3000 of them total, but it's a success either way. If I could just get it to move past these certain textures that it has issues with then we'd be in business.

[Neutrinovore]

Hmm, this all seems very complicated. One of the main reasons that I like ATM (other than the fact that it lets me have more mods installed, duh) is the 'install it and forget it' ease of use. But with this mod, am I to understand that after every time I install, remove, or alter ANY mod in my library, I need to start the game, fiddle with a GUI to activate ATL, then quit the game, restart it, then reload a texture cache, and now it's working? Or is that just the first time after installation? Also, doesn't reloading the database pretty much eliminate the ability to use Module Manager? Because I'm pretty sure that still doesn't work when reloading the database from within the game.

Anyway, no thanks, I'll stick with ATM. At least until this mod gets to a 'plug and play, install and forget' level of utility.

[NasenSpray]

I am having a little trouble. I get the settings window and I am able to interact with it. Changing the settings does not seem to update the settings cfg file. And when I click on 'rebuild cache' the buttons grey out and nothing else happens. There is no atl log file created. I looked into the ksp.log file and this seems to be where things go wrong:

[WRN 19:45:21.859] File 'GameData/AlternativeTextureLoader/config.cfg' does not exist

[LOG 19:45:21.861] [ATL] Creating new config

[LOG 19:45:21.869] [ATL] Config init done

[LOG 19:48:52.768] [ATL] BUILD ALL

[EXC 19:48:52.772] MissingMethodException: Cannot find the requested method.

Any assistance would be greatly appreciated.

Your directory structure should be

GameData/ATL.dll

GameData/atl.log

GameData/AlternativeTextureLoder/native.dlz

If atl.log is missing that means that it couldn't find or load native.dlz.

---

I thought DXT1+1bit alpha detected alpha = 0 or 1 based on the ordering of the colors, but I see that in fact that just switches between DXT1-normal and 3color+1bit alpha. Well shoot.

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...

---

Alright, theory was completely and utterly false. I had the plugin installed incorrectly. Got that sorted out once I saw the error that said something along the lines of "could not locate dll-name.dlz in the expected path." Long story short... well actually short story made shorter, I moved it and it's working. New problem, and a possible solution.

So, as it begins to build its cache, it reaches that EVE texture that I have called "duna1" and then stalls. I actually get absolutely no errors to speak of, even in the logs (either of them) nor in the debug console, which I kept open during the entire cache generation process. so, I got to thinking about how Texture Replacer does its thing, and how in configs for that mod you can specify which pathways should be ignored when unloading the textures from ram. Could a similar override list be created for this mod as well, which would simply tell the mod to completely ignore certain textures either by name, or by a folder-path? That way no entry into the cache would be entered and no modification to the texture loading process would be attempted for the specified textures. This might allow for Texture Replacer to function as well as EVE, though there could be some extra complications when Texture Replacer users make use of the gamedata override feature, but honestly I find that just clutters things up anyway, so you could just warn users of this mod to not use that specific feature, much like the warning for users of that load-on-demand mod.

I will say this though, upon reloading my game the partially built cache already shaved off a bit of time from my loading process. Granted, it's only managing ~500 textures out of over ~3000 of them total, but it's a success either way. If I could just get it to move past these certain textures that it has issues with then we'd be in business.

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

---

Hmm, this all seems very complicated. One of the main reasons that I like ATM (other than the fact that it lets me have more mods installed, duh) is the 'install it and forget it' ease of use. But with this mod, am I to understand that after every time I install, remove, or alter ANY mod in my library, I need to start the game, fiddle with a GUI to activate ATL, then quit the game, restart it, then reload a texture cache, and now it's working? Or is that just the first time after installation? Also, doesn't reloading the database pretty much eliminate the ability to use Module Manager? Because I'm pretty sure that still doesn't work when reloading the database from within the game.

Anyway, no thanks, I'll stick with ATM. At least until this mod gets to a 'plug and play, install and forget' level of utility.

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

Edited July 2, 2014 by NasenSpray

[gimpzilla76]

>Your directory structure should be

>GameData/ATL.dll

>GameData/atl.log

>GameData/AlternativeTextureLoder/native.dlz

>If atl.log is missing that means that it couldn't find or load native.dlz.

The native.dlz is in the correct location. I have ATL.dll in GameData, and native.dlz in GameData/AlternativeTextureLoader/ (as well as the config.cfg after the plugin is loaded for the first time. I have made sure to delete all of these files before trying each of the updates you have posted. After digging through the ksp.log I did find a reference to the native.dlz, but the file is located exactly where it says that it cannot find it.

[LOG 19:40:23.139] AddonLoader: Instantiating addon 'ATL' from assembly 'ATL'

[LOG 19:40:23.155] [ATL] ATL Version =

[EXC 19:40:23.174] DllNotFoundException: GameData/AlternativeTextureLoader/native.dlz

Still scratching my head..

[NasenSpray]

The native.dlz is in the correct location. I have ATL.dll in GameData, and native.dlz in GameData/AlternativeTextureLoader/ (as well as the config.cfg after the plugin is loaded for the first time. I have made sure to delete all of these files before trying each of the updates you have posted. After digging through the ksp.log I did find a reference to the native.dlz, but the file is located exactly where it says that it cannot find it.

[LOG 19:40:23.139] AddonLoader: Instantiating addon 'ATL' from assembly 'ATL'

[LOG 19:40:23.155] [ATL] ATL Version =

[EXC 19:40:23.174] DllNotFoundException: GameData/AlternativeTextureLoader/native.dlz

Still scratching my head..

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

[gimpzilla76]

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

I am using Windows 7 (x64) and the standard 32-bit ksp.exe (0.23.5).

[NasenSpray]

I am using Windows 7 (x64) and the standard 32-bit ksp.exe (0.23.5).

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?

[gimpzilla76]

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?

These are the very first two log entries:

[LOG 19:40:20.608] Load(Assembly): /ATL

[LOG 19:40:20.609] AssemblyLoader: Loading assembly at F:\KSP_win\GameData\ATL.dll

F:\KSP_win\ is the root folder of my KSP install.

[blizzy78]

Is it correct that the link to the source in the OP is linking to 0.1, but the current download is 0.1.4? Please provide the source to the latest version.