Crucially, for TextureReplacement.GetMobileBillboardMaterial, we read textures in three points:
LoadFromCacheOrImport, called when the billboard material is in cache, where readOnly was true
textureFile.Load, called when the archive is a DF classic, where readOnly was true
the TryImportTexture fallback, added by my above PR, called when the archive is outside DF classic, where readOnly was implicitly false
This issue therefore mostly hits mods like Daggerfall Enemy Expansion and Vanilla Enhanced and "DEX - DREAM patch", which provide textures for mobiles outside the classics. They generally don't need the mobile textures to be readable, but this new code path I added accidentally demanded it.
There is no reason for keeping this inconsistency, that was a mistake in my original PR from lack of understanding. There is no conceivable world where a mod relies on the mobile material being readable/writable only if it's a custom archive.
The fix is on line 628 and 634. The rest is either readability/documentation, or new overloads for mods to use.
When using mods that provide lots of texture replacements and new textures, logs are filled with the message "Texture {name} is not readable."
The root of this is a change I made in 2021 in this PR: https://github.com/Interkarma/daggerfall-unity/pull/2160/files#diff-19063ddd0d72895174af2f1e16dd67e9c31329b6c2b66995d076184724e2991dR550
Crucially, for
TextureReplacement.GetMobileBillboardMaterial, we read textures in three points:LoadFromCacheOrImport, called when the billboard material is in cache, wherereadOnlywas truetextureFile.Load, called when the archive is a DF classic, wherereadOnlywas trueTryImportTexturefallback, added by my above PR, called when the archive is outside DF classic, wherereadOnlywas implicitly falseThis issue therefore mostly hits mods like Daggerfall Enemy Expansion and Vanilla Enhanced and "DEX - DREAM patch", which provide textures for mobiles outside the classics. They generally don't need the mobile textures to be readable, but this new code path I added accidentally demanded it.
There is no reason for keeping this inconsistency, that was a mistake in my original PR from lack of understanding. There is no conceivable world where a mod relies on the mobile material being readable/writable only if it's a custom archive.
The fix is on line 628 and 634. The rest is either readability/documentation, or new overloads for mods to use.