lassipulkkinen

Just more evidence that this bug confuses people and should be fixed. Do you really want players to have this experience? https://youtu.be/jjaTovMVNJQ?si=ZPafdeZ11ngqTgnA&t=1840

I wish that there was at least a reason given for the decision to keep this as “won’t fix” (in MC-303513). Really makes no sense to me.

Commands or creative mode are not necessary to reproduce this. Normally if items are added into a dispenser (or dropper) that is already receiving power, it will not activate until the power is temporarily removed. However if a dispenser is placed next to a power source, and items are placed inside afterwards, the dispenser will fire upon receiving a block update.

Also affects the default key combinations with F3, like F3+1 or F3+B.

There are two separate bugs here. While a block is moving, it is always possible to focus the block behind it, because MovingPistonBlock.getShape() is overridden to return Shapes.EMPTY. The block becoming visually transparent is a less common bug and for sure has a separate cause.

In practice this is extremely annoying; now i need to either type blind or close the debug charts every time before typing in chat. I can’t think of any justification for it to be this way, other than “it happened to work out this way when we made F3 work in menus and fixing it would feel like a hack”. That’s not WAI, that’s won’t fix because muh clean code that does the wrong thing.

Hmm yeah this probably should’ve been a comment on that issue; I think I missed the part in the description where it calls out that doing it while holding a stack still works, and thought there may have been a time when it didn’t.

Anyway though, I think the analysis I’ve provided should demonstrate that Dinnerbone’s rationale for closing that issue was factually incorrect. It is not the first click that is the problem, it’s the second, or at least you get to pick which one; and at that point you do know whether it’s a double click. There is no inherent unfixable problem here, it is a straightforward bug that can be fixed in 10 minutes once it is understood.

Even if this was impossible to fix (which it demonstrably is not, or even difficult), it would still seem wrong to leave the half-functioning code lying around forever. I think we should at least have someone from Mojang take another look at this before upholding the Won’t Fix resolution from 12 years (!) ago; either by keeping this open or by reopening MC-6870.

This happens because this logic in AbstractContainerScreen.mouseReleased assumes that the slots belonging to the same “quick move group” as the targeted slot can be found by finding all slots belonging to the same container, when in the player inventory the two groups, being the 9x3 inventory and the hotbar, are both part of the player inventory:

					for (Slot $$6 : this.menu.slots) {
						if ($$6 != null
							&& $$6.mayPickup(this.minecraft.player)
							&& $$6.hasItem()
							&& $$6.container == $$1.container
							&& AbstractContainerMenu.canItemQuickReplace($$6, this.lastQuickMoved, true)) {
							this.slotClicked($$6, $$6.index, $$0.button(), ClickType.QUICK_MOVE);
						}
					}

As a result the code will always trigger a “shift click” on all items of the given type in both the inventory and the botbar, regardless of where you click. The actual shift click behavior in the container menu implementations on the other hand is hardcoded to move items from certain slot ranges to others, without regard for Slot.container.

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.