Gerrygames

Can confirm the issue for AMD Radeon RX 9070 XT and that the mod does fix it

I can confirm for 1.20.1

Can confirm for 1.20.1.

As this was closed as "works as intended" I want to add a clarification:
I understand that the main issue here might work as intended.
However there is another issue within this "issue" then. The animation is triggered by the client riding the horse. That means that the server and thus other clients are not aware of this animation being played. So the client riding the horse sees the horse standing up, but other clients just see the horse and rider randomly standing still for a short time for no apparent reason. This is a desync issue and can't be classified as working as intended.
Maybe a new issue should be opened for this underlying issue?

Can confirm for 1.19

And regarding the statement about giving feedback on Discord or the feedback site:
The Minecraft Discord has reached the maximum user limit. So can't give feedback there.
And the feedback website has a post about this issue. But there is no response to it. Yeah but I guess nobody will respond here either.
Nice.

Regarding this post:
https://www.minecraft.net/en-us/article/last-call-voluntarily-migrate-java-accounts

I will not migrate my accounts until I am able to login with multiple microsoft accounts.
But now I will be force to do so?
Again: Mojang promised that there will not be any drawbacks when migrating my account. But this is a drawback.
This needs to be fixed before we are forced to migrate.
Also why is this closed as "Works as intended"?
This is a feature of the old launcher and is missing in the new launcher. This is not working as intended.

Seems like this was fixed in 21w18a.

How can this be a technical limitation if it works in the old launcher?
And this is not a feature request when the feature did exist in the old launcher and then got removed in the new launcher.
Also Mojang promised there would be no drawbacks if we migrate our account to Mircosoft. This is clearly a drawback and should therefor be fixed asap.

This issue is not 100% fixed in 1.18 pre-1. The items are still being ticked in the client when they are outside the viewing distance. The server just doesn't send any (position) updates anymore. This fixes that the projectiles/items are repeatedly teleported when outside the view distance. But there is still a desync between the client and the server. The projectiles/items continue to fly/fall in the client but not on the server. When the player moves such that the given entity is within the simulation distance again it will teleport back and fly/fall again.
Demonstration in this video:

Higher bitrate:
https://youtu.be/z0-zAKjRvbs

Can confirm for 21w41a

This is caused by this code in AbstractHorse:

@Nullable
  protected SoundEvent getAmbientSound() {
    if (this.random.nextInt(10) == 0 && !isImmobile())
      stand(); 
    return null;
  }

Neither the NoAI nor the Silent flag have any impact on this behavior.
Even modifying the server can't resolve this issue because getAmbientSound() gets called by both the client and the server.
This unfortunately breaks horse racing games.

Also confirmed for 1.17-pre4 (and presumably pre5 as well).

Caused by https://bugs.mojang.com/browse/MC-179952

Should be caused by MC-179952

The issue occurs when the player releases the sneak key before the first metadata update is received by the client.

This is what happens with low latency:
Sneak key pressed -> Player starts sneaking
Client receives metadata update with sneaking=true
Sneak key released -> Player stops sneaking
Client receives metadata update with sneaking=false

But with a latency higher than the time between pressing and releasing the sneak key:
Sneak key pressed -> Player starts sneaking
Sneak key released -> Player stops sneaking
Client receives metadata update with sneaking=true -> Player starts sneaking again
Client receives metadata update with sneaking=false -> Player stops sneaking again

It seems like the client isn't actually sneaking, only the point of view and player pose is changed.

Just fyi we were experiencing this issue on our 1.14.4 servers in the past few weeks very often. I decided to look into what changed between 1.14.4 and 19w36a (as this is the first version with obfuscation mappings). I noticed that the RegionFile class has been completely rewritten. So I decided to implement the new RegionFile code into the 1.14.4 server. At first this seemed to have fixed the issue, but today the issue appeared again. And yes I am using a custom server software, but the issue is extremely likely to be the vanilla issue and if the code changes that were mentioned above are those in the RegionFile class, it seems like they did not fix the issue. I will look into what else changed and see if I can implement that too. I noticed that there were some changes in chunk de-/serialization too, but I think this is only due to the changes in the biome format.
You won't have to tell me that I would need to reproduce this on a proper 1.15 server for a proper bug report. However I won't be able to do so. Worlds get loaded thousands of times per day on our 1.14.4 server which makes it way more likely for the issue to occur. I just don't have a similar setup for 1.15 yet.

As I already wrote in the initial post, I know that this is an intended feature. I asked for a setting to disable the feature, because it's annoying. Can't really see why this is closed as "works as intended". There is nothing that could work as intended (or not).

I can also confirm that the delay is still noticable in 1.14 pre release 1. 

(Un)Sneaking should not be handled serverside. If serverside checking is really necessary, the initial check should still be performed by the client and then can be corrected by the server. This does guarantee low latency in all cases that were checked correctly by the client. If the clients check fails unsneaking will be a bit weird, but it will end up in a correct state after the server updates it. 

I just found out what the technical reason is for this. The client does not update its own metadata when the player starts/stops sneaking. The metadata has to be updated by the server. Only after the metadata has been updated, the client displays the animation (and activates part of the functionality). The delay is caused by network delay and due to the server updating the metadata not until the next tick.

I guess the responsible developer will probably be aware of this, but I wanted to mention it anyway. Maybe it helps 🙂

FYI: I noticed this, because I wasn't updating the clients own metadata on my custom server software at all. This worked fine in versions prior to 19w14a (or at least in 1.13.2), but in 19w14b sneaking wasn't working at all. After removing the check for not updating the clients own metadata, the issue vanished (though sneaking is obviously still delayed).

I'm not dumb.