MC-131564Models that have locked uv in blockstates ignore texture rotation
The bug
Models that have "uvlock" in blockstates set to true will ignore the "rotation" parameter (in models themselves) and therefore stretch the texture.
For example, if you add "rotation" to any element of the fence_side model, the texture won't rotate or will stretch (depending on the side the texture is on). But if you then set "uvlock" in the fence blockstates to false, everything works as it should.
Steps to reproduce
Install the test resource pack attached to this issue. I've used the default fence_side.json model, because it has uvlock set to true by default, and only added the "rotation": 90 tag to the uv.
Expected: texture would rotate and stretch to fit the side of an element.
Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
Linked Issues
Attachments1
Created Issue:
Fence side model does not support uv rotation
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
Steps to reproduce:
Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
Attachments1
fence side rotation bug.zip
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
Steps to reproduce:Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
The bug
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
The bug
Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
The bug
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
The bug
Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
The bug
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
How to reproduce
Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
The bug
The fence side model (fence_side.json and also custom ones with custom names) stopped supporting the uv rotation in 1.13. The fence post model works fine.
How to reproduce
Install the test resource pack attached to this issue. I've used the default fence_side.json model and only added the "rotation": 90 tag to the uv. Expected: texture would rotate and stretch to fit the side of an element. Result: nothing changes.
I've also done the same with the fence_post.json model t
o demonstrate that everything works as expected with it.
Fence side model does not support uvrotationModels that have locked uv in blockstates ignore texture rotation
The bug
Models that have "uvlock" in blockstates set to true will ignore the "rotation" parameter (in models themselves) and therefore stretch the texture.
For example, if you add "rotation" to any element of the fence_side model, the texture won't rotate or will stretch (depending on the side the texture is on).
The bug
Models that have "uvlock" in blockstates set to true will ignore the "rotation" parameter (in models themselves) and therefore stretch the texture.
For example, if you add "rotation" to any element of the fence_side model, the texture won't rotate or will stretch (depending on the side the texture is on). But if you then set "uvlock" in the fence blockstates to false, everything works as it should.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
The bug
Models that have "uvlock" in blockstates set to true will ignore the "rotation" parameter (in models themselves) and therefore stretch the texture.
For example, if you add "rotation" to any element of the fence_side model, the texture won't rotate or will stretch (depending on the side the texture is on). But if you then set "uvlock" in the fence blockstates to false, everything works as it should.Steps to reproduce
Install the test resource pack attached to this issue. I've used the default fence_side.json model, because it has uvlock set to true by default, and only added the "rotation": 90 tag to the uv.
Expected: texture would rotate and stretch to fit the side of an element.
Result: nothing changes.
I've also done the same with the fence_post.json model to demonstrate that everything works as expected with it.
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
relates to
relates to
relates to
Possibly a Duplicate of MC-131564
Seems to be fixed in 21w03a