When I place TNT down, I notice that the top texture of the TNT faces one particular direction. However, when I activate the TNT, the top texture rotates 90 degrees counter-clockwise.
Linked issues
is duplicated by 2
Attachments
Comments 24
Is this still a concern in the current Minecraft version 1.8.1 Prerelease 3 / Launcher version 1.5.3 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Instead of removing randomized rotations on the TNT model, why not have the client receive the location that the entity was primed from to get the proper randomized model? That way the server doesn't need to know anything about the resource pack, and custom resource packs' randomized models will work properly as well.
Because primed TNT (entity) rotation is server side, but placed TNT (block) rotation is client-side (resource packs can change it).
edit: Didn't read. It's probably because that takes too much effort to fix such a small issue.
Zaggy1024, removing randomized models wasn't needed, I'm not sure why it was removed since I uploaded that only to show Grum that the rotation on a non-rotated block of TNT and lit TNT didn't match (in other words, lit TNT added its own rotation).
The rotation itself is fixed as is, at least for non-randomized TNT. I'm not sure what redstonehelper is talking about though (unless it's different in SMP) because lit TNT takes the default rotation (or really, that entire first line) of block TNT.
A simple blockstate test:
{"variants": {"normal": {"model": "tnt", "x": -90 }}}
Notice that when you light the TNT, it stays exactly the same. If you have random options, the first is used. That means lit TNT simply inherits the default versions of TNT...
Another thing this means is that random TNT rotation can be added back with a resource pack... when lit, it won't match the random options but it will match the first.
Yeah, the reason it only uses one variant is because the rendering client side is calling a method that takes the first defined variant. It's a pretty simple fix, all they have to do is send the block position when the TNT is spawned, or even just round down the entity's position to get the originating block position when it spawns on the client. After that it's as simple as changing two renderer calls to use the block position to get a randomized model.
Just fixed this bug and the same bug with falling blocks (sand, gravel) in a Forge dev environment pretty easily in a few hours, simply by setting a BlockPos field in the entities the first time the entity ticks on the client, then using that to render the correct random variant.
The result:
https://dl.dropboxusercontent.com/u/30868783/ShareX/2015/12/2015-12-21_05-08-35.mp4
I feel like if it's this easy to fix, it should be done, for the sake of resource pack artists that want to use random variants for blocks that use these entities.
Note: I think using the first tick will work fine even after loading from NBT, because the player won't be able to see the random variant that it originally had. So long as the BlockPos doesn't change after the first time it's set, nobody will be able to tell it's not absolutely consistent.
Confirmed.