Blockbench pushed a fix in update 4.10.0 that fixed relative paths for textures. It originally treated the bbmodel file itself as a directory, which caused the relative path to contain an extra "../". Since this has been fixed, Figura tries to read textures as if the bbmodel is a directory (which it is not.)
This commit should fix this issue while still keeping compatibility with 4.9- models by doing the old method if a file at the relative path doesn't exist and the path starts with "../".
Gonna be honest. I kinda took the easy approach when making this. There's probably a better way of handling this but I don't wanna mess with Java's file path stuff too much.
The problems this issue caused are:
Paths to textures in the Lua runtime were extended with the path of the model file using the texture.
This would cause scripts that relied on paths being the same to break with a sort-of-vague error depending on how the texture path was used.
Textures were duplicated due to not being able to find the common file to use.
Avatar size increses caused by the above.
Unsure if the base64 version of the texture that Blockbench stores and Figura decodes would end up bigger than the external file that Blockbench is using. I didn't really test that.
The following was changed:
Resolves relative to the parent of the source file (which is hopefully the directory it is in) rather than the path of the source file itself.
This fixes the 4.10+ issues.
If the file does not exist, checks if the relative path starts with ../ and if so, tries again using the old logic.
This is done for 4.9- compatiblity.
If the compatibility is not wanted (1/10 would not recommend as this would break older avatars that still work in 0.1.4) then this code can be simplified to a single line change at L134.
Blockbench pushed a fix in update 4.10.0 that fixed relative paths for textures. It originally treated the bbmodel file itself as a directory, which caused the relative path to contain an extra "../". Since this has been fixed, Figura tries to read textures as if the bbmodel is a directory (which it is not.)
This commit should fix this issue while still keeping compatibility with 4.9- models by doing the old method if a file at the relative path doesn't exist and the path starts with "../".
Gonna be honest. I kinda took the easy approach when making this. There's probably a better way of handling this but I don't wanna mess with Java's file path stuff too much.
The problems this issue caused are:
This would cause scripts that relied on paths being the same to break with a sort-of-vague error depending on how the texture path was used.
Unsure if the base64 version of the texture that Blockbench stores and Figura decodes would end up bigger than the external file that Blockbench is using. I didn't really test that.
The following was changed:
This fixes the 4.10+ issues.
../and if so, tries again using the old logic.This is done for 4.9- compatiblity.
If the compatibility is not wanted (1/10 would not recommend as this would break older avatars that still work in 0.1.4) then this code can be simplified to a single line change at L134.