Fixed "readOnly" issue with GetMobileBillboardMaterial #2576
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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, wherereadOnly
was truetextureFile.Load
, called when the archive is a DF classic, wherereadOnly
was trueTryImportTexture
fallback, added by my above PR, called when the archive is outside DF classic, wherereadOnly
was 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.