Riley McConnell

1.21 I just got jump scared by a stray cat spawning inside a path block nearby. I panicked because I thought it was one of my tamed cats.

Please take this issue seriously.  I accidentally turned narrator on while trying to paste (Ctrl+V) a structure name into a structure block.  Suddenly the narrator is loudly reading the UI contents to me.  Gave me a pretty bad jumpscare. I panicked (anxiety disorder... yay) because I didn't know this was a hotkey, didn't know how to shut it off, and it just kept talking at me.

Apparently the hot key will turn the narrator on while in an UI but won't turn it off while it is reading the UI?  I mashed Ctrl+B several times assuming that's what I accidentally pressed but it did not appear to alter the narrator setting while I was still in the structure block UI. (Although in my panicked state I couldn't actually parse what it was saying, maybe it did change the setting but I couldn't recognize it since it verbalizes the narrator setting changes.)

I had to exit the UI and go into Accessibility settings to silence the narrator before I learned Ctrl+B was the proper hotkey.

The lack of support for hotkey combinations in the keybindings settings is a problem.  Clearly combination hotkeys are supported in some way, are they hardcoded?

Lacking documentation of this hotkey (it isn't mentioned at https://www.minecraft.net/en-us/accessibility or https://help.minecraft.net/hc/en-us/articles/360061018612 or anywhere obvious in the in-game menus) is a problem.  Not having a way to change or remove this keybind is a problem.

Accessibility features are important, but it is equally important to have them fully configurable including the option to fully disable them.  Accessibility features that are useful for some people may be problematic for others.

I've learned from running a Paper server that fixing this "exploit" so cure discounts do not stack at all (and existing stacked discounts get removed) leads to player disappointment and frustration.  Hearing my player's frustration when I switched from Spiggot to Paper was not fun for me as a server admin.
Because of this, I have disabled Paper's exploit fixes in my server settings.

Players put a lot of effort into designing and building Villager trading halls with inventive redstone systems to make use of zombie cure discount stacking. There is a growing city on my server centered on one such Villager trading hall. This city likely would not exist if players on the server had not been interested in the discount stacking mechanic and collaborated to make use of it.

I feel this is an issue where emergent gameplay and what is more fun for players needs to be taken into consideration.  Removing discount stacking completely would ruin a game mechanic that players have made entire builds around.

While acknowledging the technical limitations that currently exist, it is interesting to note that Player Heads have default NBT data that is retained upon placement in the world and when broken and dropped as an item. Any custom data, like remaining or value placed on them, is currently lost.

Player Heads are broken when moved by a piston.

So, my understanding is that Player Head is a block that by default contains 1 NBT data tag that [should not be removed] when placed in the world and or broken and dropped as an item. Seems like a reasonable compromise to me; instead of being immovable just have customized blocks break when pushed as a trade-off for retaining custom data.

There is an open ticket MC-174496 to address the issue of Player Heads losing custom data.

As a server admin I have wanted to build special features in my world with blocks that have the "Enchanted" glow effect on them. This issue prevents us from doing that.

I understand this is a security fix, but it causes a lot of problems like player heads and custom items explicitly created by server admins and datapacks losing data when placed in the world by a player.

Please reopen this issue. There needs to be another way to prevent command exploitation by non-ops that doesn't erase perfectly valid data.

Yes, also MC-174496

The issue is about doors in strongholds being generated in the open position, not which side the hinge is on.

I thought this wasn't working but I have verified what others have said. The bug is visual only, repeaters are locking when locked by a comparator, and the visual bug can be temporarily fixed by switching the mode on the attached comparator. Screenshot of test added.
Client 14w10c

Mechanics should be functional for map makers, assuming players will not need to see the repeaters.

I don't see why they should fix this. I think having some doors randomly jammed open until someone comes along and interacts with them adds to the atmosphere of the strongholds. Maybe there was an earthquake that activated the button and some debris got lodged in the mechanism and by pushing the button you cause it to dislodge. Maybe a yet unknown monster could have forced the iron doors open (without breaking them the way Zombies do with wooden doors)... wouldn't that be frightening?!
The possibilities are endless.

From a technical perspective, it is possible to place iron doors in the open state using the setblock command. Each door facing has an open and closed datavalue. I have attached screenshots of myself placing an iron door in the open state with the setblock command. (I placed the door before taking the screenshots.)

Given this information it is conceivable that iron doors generating in the open position within strongholds could be working as intended.

It should also be noted that wood doors will exhibit the same behavior described if you manually open them and then apply a redstone signal.

Much better, thanks!

It might be helpful if the moderator note included something to the effect of, "the first block along a negative axis, while technically occupying space at player position -0.12345, must be rounded to the nearest full integer (-1). This causes the perceived discrepancy between player coordinates and block coordinates."

So technically a block at -1 occupies the space between -1 and -0.000...1.
Since 0 cannot be signed and block coordinates are whole integers a player standing at -0.765 is actually standing in block -1 along the given axis.

I'm not sure the information provided fully explains the discrepancy between block coordinates and player coordinates... at least not until the lightbulb in my head turns on.

After some thought I understand why this is the case, the first negative block must be rounded to a full integer. It makes sense but the explanation given could use some fleshing out for those who are bad at math or a bit stubborn like myself.

Also, I never noticed the parenthesized number in the coordinates before. So the link was helpful. I'm still glad the debug info has been reformatted to make the coordinate details easier to find.

More testing with 1.7.5 verses 14w08a. Both clients appear to report the player's location incorrectly (along the negative axis) or at least incorrect in regard to player's percieved position (i.e. "where I'm standing should be the block coordinate.")

The additional coordinate outputs for "Block" and "Looking at" in the 1.8 snapshots solve the issue.

Setblock placed block 1 off the desired X axis position. Taken in multiplayer.

I am experiencing this bug only when connecting via Multiplayer to a console server. I am using server 1.7.5 and client 1.7.5

I collected coordinates from the client where I want the block (-79 54 316) but when I execute the setblock command using these coordinates the block is set at -78 54 316.
Changing the setblock coordinate to -80 54 316 puts the block in the desired position.

This bug does not appear in my single player testing world but is 100% repeatable in my multiplayer world. Every time I have ran this command in multiplayer it is 1 block off on the X axis.

Still an issue in 1.7.4
I haven't checked any 1.8 snapshots yet.

I started a new game in snapshot 14w07a. First thing I do is chop trees. My usual method is to chop the bottom blocks, stand under the floating trunk, and chop upward.

Some of the wood drops (approximately 1 in 5) are appearing above the tree or even being thrown several blocks away from the tree. This most frequently occurs when the block broken is surrounded on 5 sides.

I saw someone's note about branch mining and the dropped blocks appearing on the surface. I am confirming this. Mining 5 blocks out of the ceiling of my dugout shelter, 3 of them dropped on the floor, 2 of them glitched up to the surface through 10~15 blocks.

This would be really aggravating if it happened while mining valuable resources.

Player recommendation: Until bug is fixed clear the space directly above any valuable resources before mining to avoid loosing them.