XFactHD
[Bug]: frames on create trains sometimes end up with incorrect texture coordinates with some other mod blocks, but not vanilla blocks
Minecraft version
1.21
(Neo)Forge version
21.1.164
FramedBlocks version
10.3.1
Describe the bug
In some rare occurrences framed blocks on create (version 6.0.4) trains will have incorrect texture coordinates for their associated blocks, however vanilla minecraft textures are unaffected.
This only seems to occur rarely, but could be triggered when other unrelated mods are updated, but none of the mods associated with the issue, ie this mod, create and the mods of which blocks are used are completely unchanged.
Simply clicking the train disassembly-reassembly on a station immediately corrects the issue.
How to reproduce the bug
unknown what the exact cause is, but could be to do with mod updates changing the texture atlas
Expected behavior
framed blocks on create contraptions should just load in correctly with the correct texture coords
Additional details
No response
Crash log
No response
This is caused by an interaction between a network optimization in FramedBlocks and a network optimization in Create. At the moment there is nothing I can do about this, this can only be solved by a change in Create. Keep an eye on the linked Create issue for more details and progress.
mkay but why would this affect singleplayer and remains identically corrupted after world exit and re-enter? like is it because create stores the contraption as an optimised mesh on creation and never updates it after?
This also happens in singleplayer because this happens on a layer of the networking that is unaffected by the differences between singleplayer and multiplayer.
The reason it's persistent like this is also fairly simple: the data FramedBlocks uses to send the camos assigned to a framed block to the client is only guaranteed to be valid as long as the game (i.e. the server in multiplayer, the client in singleplayer) is not restarted (in practice it's almost always valid across restarts as long as the mod list and configurations stay the same). However, when you assemble a Create contraption then Create stores this volatile data to re-use it later. When the mod list and configurations stay the same, then this ends up working fine. When you change the mod list though (such as updating mods) then that data becomes outdated and the camos go haywire on the client. Since the mod list stays the same again after the updates, the data FramedBlocks uses stays the same again and therefore also the difference between the data assumed by Create's retained data and the actual data which is the visual difference you see.