Chris Reeves

Reloading the chunks solves the bug.

Normal chests are subject to the same bug. Though they do not emit a signal to begin with, this bug will still prevent them from playing opening/closing sounds and animations.

Additional testing:

The bug manifests when the player is carried up by a soul sand bubble column, sinks in water, or rides by on a pig or strider.

It manifests inconsistently when the player is carried down by a magma block bubble column, is riding a boat pushed by water, descends a ladder, flies by with an elytra, or is blown away by an explosion.

CORRECTION: Falling does seems to manifest the bug, but only rarely.

The bug seems to manifest inconsistently when the player dies with a trapped chest opened; the first few test broke the chest, but many more subsequent tests yielded no bugged behavior.

All testing (in this comment and above), other than the death testing, was done in creative mode. Sometimes flying was used to create the initial conditions for the test or to access the chest after performing the test. In the inconsistent cases, flying before or after the test did not seem to affect the bug.

Images in order of date:

Trapped chest working properly, powering piston next to it.

Trapped chest displaying broken behavior; inventory accessed, but appears closed and is not powering piston.

Setup used to create bug: manifests when player gets at least 6 blocks from trapped chest via waterflow or minecart.

Wow, gg, I guess..

A horizontal stretch also seems to occur for the wooden bar only when the bell is between two blocks. It looks like this results from simply stretching the texture it has when attached only to 1 block (which is 12 pixels with a normal width).

edit: The wooden bar's texture has a slight stretch when attached to 1 wall. It spans 13 normally-spaced-pixels but there are only 12 pixels on the texture.

There is an example of the arms not lining up and of the pixel count being 15 along the vertical axis of the block. I didn't highlight it in my screenshots, but the texture on the bell itself also seems to be stretched vertically.

I will note that the texture is 16 pixels along the horizontal axes of the block, so the vertical spacing seems unintentional.

 edit: There is some horizontal stretching (see below)

Confirmed for 20w18a

Demonstrating the unintuitive nature of the way the selector currently works, the Minecraft Wiki currently (incorrectly) describes it working as x, y, z define the corner of a volume and dx, dy, dz define the opposite corner, relative to the initial position:

https://minecraft.gamepedia.com/Commands#Target_selector_arguments , Selecting targets by volume, 2nd example from Java edition.

Because the selector currently checks if ANY part of an entity's hitbox overlaps with the volume, if it worked as described on the wiki, it would be possible to detect of an entity's hitbox overlaps with single points, lines, or planes. This would add lots of valuable functionality to the selector (particularly for raycasting entity hit detection) and, as far as I can tell, would not break anything.

Because precise hitbox detection is currently so difficult, I think modifying the dx dy dz selector would make certain mapmaking tools much easier to implement.

I did actually see that report. Now that I know about voting (thank you!), I have also just voted for it.

The reason I made this report despite it being a duplicate is that MC-123441 was reported two and a half years ago and has yet to be resolved or even assigned. I was attempting to call attention to it again.

Other than voting, is there any other way to respectfully increase attention to MC-123441?

Thanks!

What I essentially would like to do with this selector is detect whether an entity is within the hitbox of another entity. I am teleporting area effect clouds along a given path and would like to detect when they intersect with players/mobs/etc.

The way the current selector works creates a large 'detection' region located asymmetrically relative to the position of the area effect cloud, which is imprecise and hard to work with. The alternative "distance" selector is also imprecise as distance is measured relative to the feet of entities, creating a large spherical 'detection' region centered at entities' feet.

The only solution I have come across involves calculating the bounds of the hitbox of each player/mob/etc and detecting whether the position data of the area effect cloud is within the calculated bounds. This, however, is relatively costly to run and just takes many more commands. Given that the dx dy dz selector already automatically calculates intersection with hitboxes, it seems like a waste to not be able to use it in this situation.

As a note for the unintuitive nature of the way the selector currently works, on the Minecraft Wiki, it has been (incorrectly) described to work in the way I suggested it should:

https://minecraft.gamepedia.com/Commands#Target_selector_arguments , Selecting targets by volume, 2nd example from Java edition.