Zaggy1024

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.

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.

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.