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

Thanks! I guess TextureReplacer doesn't like the way I'm loading textures. I'll see what I can do to fix it.

Start your game with aggressive ATM, make the first build, restart without ATM, tweak settings and rebuild again. The second rebuild overrides any scaling ATM has done. The problem is that the normal map detection only works after KSP loaded all parts. That's the reason ATM needs config files for all the mods... But you don't need to rebuild instantly as uncached textures are still loaded by KSP. ATL creates logs (in KSP.log and GameData/atl.log). Please send them to me and I can take a look at why it's crashing.

I don't think it has anything to do with that as my posts go through moderation. I'm going to create a new thread...

yeah, i just changed the title to include the KSP version and now the content is gone -.- @mods: do i need to create a new thread or can this be fixed somehow? i can't edit anything Edit: Thank you, DYJ!

Note: Downloads for recent versions temporarily suspended AlternativeTextureLoader 0.1.4 This mod replaces/augments KSP's texture loader to dramatically improve loading time. ATL supports texture compression, scaling and has automatic normal map detection. Why should I use it? ​It's really fast It saves more RAM than ATM: [TABLE=class: outer_border, width: 1000] [TR] [TD]Config[/TD] [TD]Memory[/TD] [TD]Load time[/TD] [TD]Notes[/TD] [/TR] [TR] [TD]KSP1[/TD] [TD]2.77GB[/TD] [TD]45s[/TD] [TD][/TD] [/TR] [TR] [TD]KSP1+ATM[/TD] [TD]1.60GB[/TD] [TD]56s[/TD] [TD]compression, 1/2 normal maps with max. 512x512[/TD] [/TR] [TR] [TD]KSP1+ATL[/TD] [TD]1.59GB[/TD] [TD]23s[/TD] [TD]compression only[/TD] [/TR] [TR] [TD]KSP1+ATL[/TD] [TD]1.40GB[/TD] [TD]23s[/TD] [TD]compression, 1/2 normal maps with max. 512x512[/TD] [/TR] [TR] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [/TR] [TR] [TD]KSP2[/TD] [TD]-[/TD] [TD]-[/TD] [TD]Out of Memory[/TD] [/TR] [TR] [TD]KSP2+ATM[/TD] [TD]2.73GB[/TD] [TD]138s[/TD] [TD]compression, 1/2 normal maps with max. 512x512[/TD] [/TR] [TR] [TD]KSP2+ATL[/TD] [TD]2.23GB[/TD] [TD]48s[/TD] [TD]compression, 1/2 normal maps with max. 512x512[/TD] [/TR] [/TABLE] Test system: Win7 x64, i5-750, 8GB RAM, SSD How does it work? It saves already compressed/mip-mapped textures in a single file (that's also compressed with LZ4), called the cache. That allows to skip every post-processing step that KSP normally does while loading. It interfaces with DirectX (and now also Mono/Unity) in order to do that. Supported plattforms Windows XP/Vista/7/8/8.1 32/64-bit, DirectX, 32-bit KSP only Features DXT1/DXT5 compression depending on actual alpha channel usage Configurable scaling with upper/lower limits LZ4 compression of the cache "Fake" start-up routine for bootstrapping Usage Install ATL (copy contents into GameData) Start KSP Wait until main menu Set your desired settings Hit "Rebuild cache" Restart KSP Enjoy Repeat this process whenever you install/remove mods Settings ​Scaling: How much the textures should be scaled while building the cache Min. dimensions: Neither side of a texture will be scaled down lower than this. Textures are never upscaled Max. dimensions: Neither side of a texture will exceed this size after scaling, even with 1/1 scaling Scaling always maintains aspect ratio config.cfg (created after first start): compressColor/compressNormal [true/false] Normal-map compression may lead to lightning artifacts and needs to be activated manually Download ATL 0.1 binary Source (v0.1; License: None, aka all rights reserved, until further development) Note: Current version will be back up soon! Possibly Asked Questions Do I still need ATM for bootstrapping? Nope. ATL now performs a memory saving dummy start on first usage and whenever you delete your cache! Do I really need to rebuild when I remove/add mods? No, you actually don't. Added textures will be loaded by KSP and removed textures are simply not loaded at all (but still in cache) What is this "native.dlz" file and why is it so big? It's a native DLL written in C++ and has this weird file extension so that KSP doesn't try to load it as an add-on. It contains the native portion of ATL dealing with DirectX/Mono/Unity and is statically linked with the size inflating CRT. Known incompatibilities ATM Texture replacement mods, e.g. TextureReplacer All mods that need access to texture data ​EVE, LoadOnDemand etc. Temporary fix: Uninstall these mods and everything they modify, rebuild the cache, reinstall them and hope it works. Log messages like "Texture ' ' has no data" mean that there are still cached textures they need to access. 0.1.3 has rudimentary support for EVE (it's always super cloudy ) Known Problmens Textures that have an alpha channel for no ********** reason prevent the usage of DXT1 That can only be solved by the creators of those textures (not SQUAD, they only use alpha when needed ) Roadmap Taking control of UnityEngine.Texture2D transparent handling of GetPixel/SetPixel calls etc needed to get texture replacement mods working first steps done since 0.1.2 [*]Incremental/offline cache build Incremental: append only, the file format doesn't allow for removal [*]KSP 64-bit support [*]Texture upload to Video RAM [*]perhaps OpenGL/Linux support Credits rbray89, the creator of ATM, for the inspiration JetBrains dotPeek, it allowed me to figure out how KSP works internally When stuff goes wrong ATL creates a log file called atl.log in GameData. Post/Send it together with the regular KSP.log file and I'll see what went wrong. Changelog = 0.1.4 ========================== - memory saving first start-up by replacing every texture with a dummy -> no dependency on ATM! = 0.1.3 ========================== - fixed bug that made unmanaged normal-maps load ultra slow = 0.1.2 ========================== - fake EVE support (clouds are different) -> Texture2D.GetPixel() & Texture2D.GetPixelBilinear() calls are now intercepted for every managed texture -> everyone who calls GetPixel() gets solid black -> everyone who calls GetPixelBilinear() gets a random shade of light gray (EVE's using that to determine cloud color) = 0.1.1 ========================== - removed useless log messages - fixed compatibility with ProceduralParts/StretchyTanks -> ATL didn't set UnityEngine.Texture.name = 0.1 ============================ - initial release