MC-12959TNT mesh rotated wrongly placed vs primed
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
Changed Description:
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
'.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.
Added Affects Versions: 1.8.1-pre3 1.8
Added Linked Issues:
relates to
Deleted Comment:
Here is a GIF of the glitch
Added Attachments:
Added Affects Versions: 15w39c
Added Assignee: ![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png)
[Mojang] Grum (Erik Broes)
[Mojang] Grum (Erik Broes)Added Attachments:
Added Fixed Versions: 15w46a
Added Affects Versions: 15w46a
Added Linked Issues:
relates to
Added Linked Issues:
is duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Added Linked Issues:
is duplicated by
Removed Linked Issues:
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
![[Helper] gaspoweredpick](../../../data/avatars/users/80904.png){kind=small}
Confirmed.
Still a concern in 1.7.4/5 and 1.8
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.
Still an issue, with alternate blocks turned off.
Still in 1.8.8 and all 1.9 snapshots.
Still an issue in 15w38a
Still an issue in 15w39c
Still an issue in 15w43b
The model gets assigned randomly in the world, not possible to sync this up.
Actually, the TNT is still rotated 180 degrees when random rotation is disabled. Please reopen.
Random rotation can't be disabled anymore (unless you use a resource pack, in which case you might as well make a resource pack to fix the issue yourself).
The resource pack I attached disables rotation. If you try it, you'll see that when the TNT is ignited it does a 180, so it's the entity's processing rotating TNT's model (people have seen this with custom models, too).
I'm not aware of a guaranteed way to fix this issue , but I'd guess that you'd need to trick the system using random models (with the first possibility having 0 weight so it will never show in-world but lit TNT will use it) but frankly that shouldn't be needed since there is no reason for it to rotate TNT's model when it is ignited.
This can not be fixed fully: lit TNT rotation is decided server-side but resource packs are client-side.
Of course it can be fixed. I'm not asking for lit TNT to match the resource pack's rotation, I'm asking it for the default rotation to be 0.
EDIT: Furthermore, it already inherits whatever model TNT uses by default, including its rotation, and then adds more rotation which is pointless.
Thanks, Grum!!
Can confirm it's not fixed in 15w46a.
I can confirm this too.
in 15w46a any potion (also the lingering potion ) it will use as an awkward potion (creates no effect on Player)
Fueler, that's
MC-92559Instead 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.