I've noticed this fairly often too. I don't think sprinting specifically is the problem, I'm pretty sure its more that the pathfinding while leashed is really bad at understanding when to go up a block.
Sometimes it feels like the leashed mob is trying to get to the closest block to the player without increasing it's y-coordinate before it jumps, even if the path to get to such a position falls outside of the leads range.
I noticed that the Honey Blocks are effective in slowing the player’s descent if the camera is angled significantly upwards or downwards, as demonstrated by the honey particles showing and the Sticky Situation advancement being granted. Therefore, this issue only seems to occur when the player is facing forwards so I have updated the title of the bug to more accurately explain the issue.
No resource packs or datapacks are being used during this test
Here I made a contraption to demonstrate using the stopwatch command feature.
The top tripwire teleports me to my current position to negate any potential momentum, and making my camera rotation 0 0 to make both tests fair.
The middle tripwire resets the stopwatch I made for this test so the timer starts from 0 at the same point.
The lower tripwire queries the stopwatch to see the time it took to fall from the middle tripwire.
From the test in the video, you can see that the descent down a honey wall is the same as the descent down a regular block wall (which from testing a few times seems to happen every time, even if only by such a marginal fraction).
Five tests were run on each wall to help get an average for more accurate results, due to minor inconsistencies caused unknown reasons.
The average descent times to 3d.p. from each walls' five tests were:
Honey Block Wall: 2.013 seconds
Normal Wall: 2.019seconds
(The Honey Block wall seems to allow for a slightly faster descent, but with more tests the averages would likely be closer, if not identical.)
Bows also stay charged if arrows are removed from the player’s inventory with commands before releasing right click to fire the arrow. (Releasing right click behaves as expected, not shooting an arrow the player doesn’t have)
The description implies that the intended function isn’t to change two separate unrelated areas. Half of what is shown is the intended functionality (as inconvenient as it may be), and the other half of what I show in the video does not fit the description provided.
The bug isn’t the lack of precision (as I described understanding to be the intention within the “Observed Results”), the bug is the fabrication of parameters letting the command act completely independent and change an entirely separate and non-touching area in addition to the correct and intended area.
I haven’t tested them all but this seems to apply to every entity in the game. Some I have tested were boats, minecarts, falling blocks, items, area effect clouds, lightning bolts.
(Some of these must be spawned in with commands first, and in the case of the lightning bolt must also be killed with commands to ensure it has been killed in time before it naturally finishes striking)
I understand having a warning for invalid formatting, but this warning is false in several cases as the resource pack isn't broken or incompatible.
It works exactly correctly so the warning is inaccurate and should instead be something claiming it is a possibility it doesn't work, not outright denying any possibility that it could work.
First and third “Charge” attempts demonstrate this bug. The fourth (final) attempt demonstrates what should happen. (The second attempt can be ignored as I just missed it)
[media: pufferfishspear.mp4]
(Depth Strider 3 Netherite Boots equipped; Resistance, Saturation and Water Breathing potion effects applied; Repeating Command Blocks running to kill all items and remove any Poison from me)
First part makes sense, thank you for explaining. Is there a way I can see on a bug report if it is already actively known by Mojang?
Also on your original report title, I suggest changing it to something broader to better fit what happens, as it seems to occur for every vertical travel method where the players movement isn't interrupted, not just the two listed. (Such as Bubble Columns, Elytra seem to have the same issue too, and I'd assume Ender Pearls would be in the same boat as teleportation, but clarifying the uninterrupted movement part because this doesn't work on Twisting Vines, and presumably other vines + ladders)
Why would it be best to copy everything over to that report? All of the information is here already, and in the past older less accurate reports have been marked as duplicates in favour of marking the newer, more detailed report, presumably to avoid unnecessarily spending time copying stuff over. (I'm just confused)
I've noticed this fairly often too. I don't think sprinting specifically is the problem, I'm pretty sure its more that the pathfinding while leashed is really bad at understanding when to go up a block.
Sometimes it feels like the leashed mob is trying to get to the closest block to the player without increasing it's y-coordinate before it jumps, even if the path to get to such a position falls outside of the leads range.
I noticed that the Honey Blocks are effective in slowing the player’s descent if the camera is angled significantly upwards or downwards, as demonstrated by the honey particles showing and the Sticky Situation advancement being granted. Therefore, this issue only seems to occur when the player is facing forwards so I have updated the title of the bug to more accurately explain the issue.
No resource packs or datapacks are being used during this test
Here I made a contraption to demonstrate using the stopwatch command feature.
The top tripwire teleports me to my current position to negate any potential momentum, and making my camera rotation 0 0 to make both tests fair.
The middle tripwire resets the stopwatch I made for this test so the timer starts from 0 at the same point.
The lower tripwire queries the stopwatch to see the time it took to fall from the middle tripwire.
From the test in the video, you can see that the descent down a honey wall is the same as the descent down a regular block wall (which from testing a few times seems to happen every time, even if only by such a marginal fraction).
Five tests were run on each wall to help get an average for more accurate results, due to minor inconsistencies caused unknown reasons.
The average descent times to 3d.p. from each walls' five tests were:
Honey Block Wall: 2.013 seconds
Normal Wall: 2.019 seconds
(The Honey Block wall seems to allow for a slightly faster descent, but with more tests the averages would likely be closer, if not identical.)
This is also the case for the warm variants' horns, but that at least could still make sense
Bows also stay charged if arrows are removed from the player’s inventory with commands before releasing right click to fire the arrow. (Releasing right click behaves as expected, not shooting an arrow the player doesn’t have)
@tryashtar
The description implies that the intended function isn’t to change two separate unrelated areas. Half of what is shown is the intended functionality (as inconvenient as it may be), and the other half of what I show in the video does not fit the description provided.
The bug isn’t the lack of precision (as I described understanding to be the intention within the “Observed Results”), the bug is the fabrication of parameters letting the command act completely independent and change an entirely separate and non-touching area in addition to the correct and intended area.
An example of an unpleasant visual issue this causes.
Similar to MC-220397
I haven’t tested them all but this seems to apply to every entity in the game. Some I have tested were boats, minecarts, falling blocks, items, area effect clouds, lightning bolts.
(Some of these must be spawned in with commands first, and in the case of the lightning bolt must also be killed with commands to ensure it has been killed in time before it naturally finishes striking)
This also happens when attaching a mob to a fence with a leash, but not when unleashing the mob from the fence.
I understand having a warning for invalid formatting, but this warning is false in several cases as the resource pack isn't broken or incompatible.
It works exactly correctly so the warning is inaccurate and should instead be something claiming it is a possibility it doesn't work, not outright denying any possibility that it could work.
Durability is also taken from the Spear when a “successful” hit is made with this bug occurring.
First and third “Charge” attempts demonstrate this bug. The fourth (final) attempt demonstrates what should happen. (The second attempt can be ignored as I just missed it)
(Depth Strider 3 Netherite Boots equipped; Resistance, Saturation and Water Breathing potion effects applied; Repeating Command Blocks running to kill all items and remove any Poison from me)
This animation also incorrectly plays when a Spear ie being held and the player is throwing other items out of their inventory.
First part makes sense, thank you for explaining. Is there a way I can see on a bug report if it is already actively known by Mojang?
Also on your original report title, I suggest changing it to something broader to better fit what happens, as it seems to occur for every vertical travel method where the players movement isn't interrupted, not just the two listed. (Such as Bubble Columns, Elytra seem to have the same issue too, and I'd assume Ender Pearls would be in the same boat as teleportation, but clarifying the uninterrupted movement part because this doesn't work on Twisting Vines, and presumably other vines + ladders)
Why would it be best to copy everything over to that report? All of the information is here already, and in the past older less accurate reports have been marked as duplicates in favour of marking the newer, more detailed report, presumably to avoid unnecessarily spending time copying stuff over. (I'm just confused)
This also happens when standing on Shulkers