lassipulkkinen

Sure lol, just wanted to see what would happen.

Can confirm in 24w38a. Also happens in multiplayer.

While this report isn't directly applicable to 24w34a, here's a setup with similar issues on that snapshot:

Two things to note here:

• The left side preference doesn't carry over to the updates produced by the redstone torch. This is pretty much to be expected based on the release notes, and I'm not sure how a "fix" for this could be implemented in practice, but it's still potentially undesirable.

• The same problem as before – the directional preference is chosen independently for the two torches. To fix this, there's always the option of making the choice globally for each tick.

edit: Here's a proper demonstration of the second point, since in the original setup it gets overridden by the fact that the pistons are oriented on different axes :/

For reference, the easiest way I could come up with to invoke the randomness is to place a continuous wire on top of the pistons (supported by blocks, of course), then place a redstone torch in the gap between the pistons.

This happens when you press the button again while the left piston is retracting. In this state the block position in the middle is unoccupied but the left piston cannot extend yet, so the right piston can extend instead. So, no bug here.

edit: Also, it's basically a duplicate of MC-275318, where this was already explained.

Oh, sorry for the noise. Maybe you need to add the eat_sound then?

edit: The command did actually work for me though... So sorry for even more noise I guess.

The way the move packet rate limit is implemented is kind of misguided in general, since it allows a sustained rate of 5 packets per tick. The client has no excuse to send more than 20 per second, so sending 5 in one tick should require 5 skipped packets soon afterwards. (The purpose of the limit is presumably to account for network fluctuations, not for clients running at 100 TPS.) Also, it should be based on wall clock time, not TPS. Because the maximum speed is scaled by the number of received packets (actually the square root of that number due to an algebra mistake in the code), this leniency increases the speed limit to 5x (actually 2.24x) the intended value.

That said, I don't know if the specific behavior this report is about is actually problematic. It kind of makes sense to count rotation-only packets, since the client will on each tick send either a packet that contains the position, or one that doesn't, so they both follow the same tick rate. And of course, an increased rotation packet rate could give an aim/reaction time advantage in combat.

edit: As long as it only affects the speed limit it indeed doesn't make that much sense; and I don't think the vanilla server checks that you're actually aiming at the entity you're hitting either (shouldn't be too hard to store entity positions a few ticks back, then check those against the rotation and an estimate of the currect latency (based on pings and the client's send rate); but still way more involved than anything in vanilla anticheat). I still think the idea of rate limiting rotation packets would make sense if it actually had any effect, but oh well.

It's too long to fit in the chat box. Try putting it in a command block.

As an aside, weird how a report for 1.19-pre3 can be marked as a duplicate without causing this to be reopened...

Just discovered this on 1.20.4 while testing a custom server and looking at the angles sent by the client; definitely still unresolved.

After setting mouse sensitivity to HYPERSPEED!!! and disabling raw input (with mouse acceleration enabled system-wide), I was able to reach a yaw value below -2²² (~-4 million) in a reasonable amount of time, for some definition of reasonable. As shown in the attached video, this number is large enough to show visible quantization in the debug screen yaw display. It also causes a very noticeable "screen edge" effect blocking horizontal mouse movement when the motion delta since last frame is less than 0.5 degrees, also shown in the video.

Yeah, that's also how I did it (except on the loopback interface). Should probably have included that.

I don't think so. Based on the fps graphs shown in the screenshots, the lag spikes in this issue are more severe than those in MC-170091, whose description doesn't even mention lag spikes, but a stable decrease in fps. Secondly, this issue is specific to Wayland GNOME (and maybe some other compositors), but the debug overlay in MC-170091 screenshots doesn't mention Mesa, so it's probably not on Linux. (Compare to the screenshots in this issue for reference.)

Yes.

I forgot to mention, this apparently does not occur on Sway (with Xwayland enabled), so it's probably a problem with GNOME's implementation of Xwayland support, not with Xwayland itself. Also, all versions since 1.15 (not sure which snapshot) are affected; 1.14.x is fine. Maybe the "Affected version/s" should be expanded?

I'm also using GNOME on Wayland and can confirm. This only seems to affect fullscreen mode, so I thought, a borderless windowed "fullscreen" (which many games offer as an option, but not Minecraft) would probably be unaffected, too. I tried putting the game window in such a state remotely, which didn't help as it seems GNOME or Xwayland detects such trials and puts those windows in the "real" fullscreen mode, or something. Except, if the window is made borderless before resizing it (then made borderless again, because otherwise the resize won't apply, not sure why), the problem magically goes away. The window becomes seemingly fullscreen, although Minecraft itself doesn't realize that (tbh it doesn't when using the wm's (i3, etc.) built-in fullscreen feature, either.) Toggling fullscreen in-game once does nothing except make the game realize that it's enabled, and after that it toggles between a broken fullscreen with the top bar visible ("windowed") and a normal fullscreen; windowed is broken, but fullscreen stays unaffected by this issue. Here's the Python script I used to pull this off (I have no idea why this works):

#!/usr/bin/env python

import sys
import os
from gi.repository import GdkX11

display = GdkX11.X11Display.open(os.environ["DISPLAY"])
window = GdkX11.X11Window.foreign_new_for_display(display, int(sys.argv[1]))
geometry = display.get_monitor_at_window(window).get_geometry()
window.set_decorations(0)
window.move_resize(geometry.x, geometry.y, geometry.width, geometry.height)
window.set_decorations(0)

This expects the window id of Minecraft as an argument. You can find that out using, for example, xdotool as shown here:

xdotool search -name '^Minecraft\*? [0-9]+\.[0-9]+\.[0-9]+'