ICE

Still most definitely an issue in 1.20.30, along with the 1.20.40 preview.

Still definitely an issue in 1.20.30. It’s the same issue ever since this bug report was made

I still have problems on my RTX 2060. Though vsync enabled improves input delay, there is still input delay. For me, the lower the fps, the more input delay there is. One of the many issues of render dragon is that RTX GPUs generally perform worse, and it may be due to something with DirectX usage.

Still an issue, can be kinda worked around with custom items with the armor component, as it has a knockback resistance stat attached to it. Though the knockback resistance is slightly inconsistent, meaning it causes some hits to slightly vary in knockback.

pat_, thank you, vsync being on used to be slightly better than when it was off, at least in my experience. Though, one thing that I have observed is that when my framerate is lower, there is more input delay, meaning that I still get slight input delay even when vsync is off. Also, when my framerate is capped, it tries to produce fewer frames than it really should, meaning that it barely meets the certain FPS cap for some reason. Though because of render dragon still, I get around half the FPS that I normally would, and one of the issues may be that it's forcing dx12 on my PC.

I run 90fps (1.18.31 + vsync on) with significant input delay on renderdragon while playing hive skywars. Without renderdragon (1.18.12 x86 + vsync off), I run around 300fps on the same map with absolutely no input delay. 

Main Specs:

Intel i7 8700
RTX 2060

Those specs ($1200 PC) should not be only producing 90 FPS with 100ms input delay (rough estimation) on a pixel block game. Unacceptable.

Might also (in certain ways) be related to a DirectX 12 issue, as my GPU supports it, and render dragon forces that directx version.

If it stops 50 blocks away, that means your world's simulation distance is at 4 chunks. By changing it to 12, the range will be significantly further. Or just add a ticking area, which would make it work anywhere in the world.

+ RTX 2060

If there needs more clarity, let me know.

This issue was primarily made to notify (if not already), the devs. If I were to create a suggestion, who knows if it would have ever been seen by any higher up. There is no indication anywhere that this problem will or will not be fixed. You can mark it as invalid, but at least do something more than just deleting this report.

This sums it up (but nothing has happened in the last 2 years): https://feedback.minecraft.net/hc/en-us/community/posts/360061484772-iPads-should-support-120Hz-refresh-rate-and-support-for-more-input-devices

For me, it seems like there's no real way to make change for minecraft bugrock. None of my bug reports have been fixed yet, which makes me very frustrated, and disappointed. Doesn't this pretty much defeat the purpose of this website? 

Yea, delete this comment or whatever because it breaks the rules, I just hope you understand how frustrating this is.

Yes, the issue still occurs

Yes, theres a server developer that removes render dragon and releases the appx to the public, that’s our solution, and it only applies to the windows 10 players, it being the 32 bit version of windows 10 edition.

This 100% has to do with the model's gui rotation value. I have yet to determine specific values it happens at, but any model I have set to "rotation": [30, 45, 0], [30, 225, 0], or anything else close to a default block's rotational value, no longer looks dark in the gui. This becomes rather frustrating however, as having a model always displayed at or near the same gui rotational value as a block is very much not ideal as many custom models, especially tools, are much better displayed at a more "flat" angle as opposed to an isometric angle.

Hopefully this can get a fix soon as it ruins the look of many cool things in custom resource packs.

asofold is the project lead of NoCheatPlus of which I am a team member. We call this phenomenon "lostground" internally, and an unfortunate amount of time gets spent trying to account for it.

Unfortunately, there isn't a simple way to replicate this without logging packets, positions each tick, etc. It took me quite some time to figure out exactly what was causing this, initially thinking it was an issue with how Bukkit fired move events.

The solutions asofold suggested above would allow us to more accurately detect and prevent movement exploits. Additionally, if you look at my other open issues, there are other, somewhat related issues that also directly affect our ability to provide quality anticheat software to the multiplayer community 🙂

Here's an example that shows the bounding boxes during a series of movements. In this example, the player is moving right to left, and is bunnyhopping onto the slabs and into midair where the trace ends.

https://i.gyazo.com/644b9a70b60902ad780a325602e2d3ed.png

You will notice that the player never actually lands on the slab (second box from the left), but still jumps into the air (the far left bounding box). This is because when the move is actually being made, Y translates first from the position of the previous move, and the player collides with the slab setting onground to true. Then, X and Z happen which translate the player off of the slab and into midair without rechecking onground afterwards.

This is a client-side issue. The client calculates onground immediately after the Y portion of a move, which occurs before X and Z. This means that a move can (and often does) move a player off of a block and into midair, while the client still thinks it's onground. Since onground is only calculated during a move, this means that the next move will behave like it's on the ground and will allow jumping even though the client is in midair.

This is nearly impossible to see visually, but it translates to odd movement mechanics server-side making anticheat systems use convoluted workarounds ("player COULD have hit the ground during the Y portion of this move so they might not be cheating").

I mentioned it in #mcdevs 😛