TheAfroOfDoom
- TheAfroOfDoom
- theafroofdoom
- America/New_York
- Yes
- No
MC-19771![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
Low![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
While hitting any slab with an axe, the slab is destroyed fast, & doesn't drop however. It doesn't matter if the slab is stone or wood based material.
Axes Break Stone Based Slabs Fast
I am still having this issue in 1.10.2
This seems to be somewhat related to MC-76184, but not entirely the same. If you have a floating Armor Stand (or any other mob) with a Zombie (or any other mob) passenger, the Zombie's rotation acts extremely strangely.
Here is a video demonstrating the bug.
I should note that Guardians function logically; they do correctly update their rotation even while floating/riding an Armor Stand (or other mob). When riding boats, zombies (mobs that aren't Guardians) also update their rotation semi-correctly if the boat is on the ground. If the boat is grounded, the zombie updates its rotation in jerked motions, even though the model appears to follow the villager smoothly. When the boat is airborne, the Zombie's rotation functions as it does in the video, and the model does not even appear to follow the villager.
The pitch appears to be updating correctly; only the yaw seems to be bugged.
This seems to be somewhat related to MC-76184, but not entirely the same. If you have a floating Armor Stand (or any other mob) with a Zombie (or any other mob) passenger, the Zombie's rotation acts extremely strangely.
Here is a video demonstrating the bug.
I should note that
Guardians function logically; they do correctly update their rotation even while floating/riding an Armor Stand (or other mob). When riding boats, zombies (mobs that aren't Guardians) also update their rotation semi-correctly if the boat is on the ground. If the boat is grounded, the zombie updates its rotation in jerked motions, even though the model appears to follow the villager smoothly. When the boat is airborne, the Zombie's rotation functions as it does in the video, and the model does not even appear to follow the villager.The pitch appears to be updating correctly; only the yaw seems to be bugged.
This seems to be somewhat related to MC-76184, but not entirely the same. If you have a floating Armor Stand (or any other mob) with a Zombie (or any other mob) passenger, the Zombie's rotation acts extremely strangely.
Here is a video demonstrating the bug.
I should note that guardians and spiders function logically; they do correctly update their rotation even while floating/riding an Armor Stand (or other mob). When riding boats, zombies (mobs that aren't Guardians) also update their rotation semi-correctly if the boat is on the ground. If the boat is grounded, the zombie updates its rotation in jerked motions, even though the model appears to follow the villager smoothly. When the boat is airborne, the Zombie's rotation functions as it does in the video, and the model does not even appear to follow the villager.
The pitch appears to be updating correctly; only the yaw seems to be bugged.
In 17w15a, my custom resource pack sounds (not just changing vanilla sounds, the ones I've added and included in the sounds.json) do not play a sound when /playsound(ed). I went back to 17w14a and they played fine.
The custom models in the pack loaded; so that proves the pack is actually loading. Just the sounds are not.
In 17w15a, my custom resource pack sounds (not just changing vanilla sounds, the ones I've added and included in the sounds.json) do not play a sound when /playsound(ed). I went back to 17w14a and they played fine.
The custom models in the pack loaded; so that proves the pack is actually loading. Just the sounds are not. Vanilla sounds work fine.
Confirmed for 17w16a.
The bug
Since 17w15a custom resource pack sounds (not just changing vanilla sounds, the ones you have added and included in the sounds.json file) do not play a sound when /playsound(ed). This used to work fine in previous versions.
How to reproduce
- Download the attached resource pack 17w15a Sound Bug.zip
and load it
- Use the following command to try playing a custom sound
/playsound sound-bug master @a→ The sound is not played; additionally an error message appears in the log indicating that the sound could not be played
Note: The provided resource pack modifies the nether quartz ore texture as well, therefore you can check if the resource pack was loaded correctly by looking at a nether quartz ore block.
Assuming a scoreboard objective rotation with type dummy, if the command execute as @a at @s store result score @s rotation run data get entity @s Rotation[0] is ran in an Always Active repeating command block, it is expected that the Vertical Rotation of each player will be set to their rotation score. This does occur, but it is inconsistent, ranging from -360 to 3
60.I believe this happens due to Rotation NBT not actually capping it's value, instead the value being given to rotation is the result of Rotation % 360 where % is modulus and Rotation >= 0. This isn't the worst thing, but the issue arises when Rotation NBT is negative and rotation then is given the value of Rotation % -360. Rotation NBT seems to not have a cap (and is inconsistent when being translated to rotation because if you continually rotate clockwise (angle is increasing), rotation will loop from 0 to 359. If you rotate from 0 to 720 (two full rotations), it then takes 2 rotations back (720 to 0) to begin getting a negative rotation score.
Assuming a scoreboard objective rotation with type dummy, if the command execute as @a at @s store result score @s rotation run data get entity @s Rotation[0] is ran in an Always Active repeating command block, it is expected that the Vertical Rotation of each player will be set to their rotation score. This does occur, but it is inconsistent, ranging from -360 to 359
I believe this happens due to Rotation NBT not actually capping it's value, instead the value being given to rotation is the result of Rotation % 360 where % is modulus and Rotation >= 0. This isn't the worst thing, but the issue arises when Rotation NBT is negative and rotation then is given the value of Rotation % -360. Rotation NBT seems to not have a cap (and is inconsistent when being translated to rotation because if you continually rotate clockwise (angle is increasing), rotation will loop from 0 to 359. If you rotate from 0 to 720 (two full rotations), it then takes 2 rotations back (720 to 0) to begin getting a negative rotation score.
Oh okay, sorry :l
Yes, it still affects 1.11 (and the current snapshot).
Confirmed to affect 17w14a and 17w13b.
I have done so. I replaced the quartz ore texture with a darker iron block if you want to know if the pack has loaded. To play the sound use "/playsound sound-bug master @a". I tested it and the sound played in 17w14a, but not 17w15a.
@Denis, I tested the command with those extra parameters and it still did not work.
Confirmed for 1.14 pre-release 1.
Confirmed for 1.14.1.
i'd like to point out that if this is "fixed" then that would lead to a pretty substantial difference in what your cursor is pointed at when you have View Bobbing on/off and are moving
that seems like a really bad side effect of this issue being fixed