Some events / actions do not trigger observers

Sorry for my various reports (I thought I would repeat the reports of others, so I did not put the reports together) and thanks for putting together the reports in one 🙂. A greeting [Mod]CubeTheThird !!

Here are a few more types of block state changes that do not currently cause block updates:

• Opening/closing trapdoors and fence gates.
• Inserting/removing music discs in/from jukeboxes.
• Changing the water level of cauldrons with buckets and bottles.
• Placing glass bottles/water bottles/potions in brewing stands.
• Placing eyes of ender on end portal frames.
• Vine growth.
• Nether wart growth.
• Natural tree growth (currently only tree growth forced by bonemeal causes block updates).

Block update detectors are amazing, so let's get the most possible use out of them. Now that the developers are giving active support to BUDs by giving us observer blocks, this seems like a great opportunity to make all of the block state changes that really should cause block updates actually do so.

Confirmed in 16w39b

Yep, found the exact same things. Someone told me the opening and closing of things is due to the meta data values not changing on some block updates

Here are few more things that observer blocks should detect, but do not currently:

• Switching comparators between comparison and subtraction modes.

• Sleeping in beds.

• Opening ender chests. (It could be argued that the block state isn't actually being changed when you open an ender chest, and hence the observer block shouldn't detect it, but observer blocks do currently detect chests being opened, and that's useful, so it's not a feature that should be removed. If we keep that feature for chests, we should add it to ender chests as well, for consistency.)

Btw, there's a small typo in the bug description above:

"Observers to not detect the following:"

Should be:

"Observers do not detect the following:"

Or perhaps:

"Observer blocks do not detect the following block state changes:"

Thank you to the mods for your attention in compiling, maintaining, and improving this bug report.

item frames are no block in pc, so it's not a block update.

I said in my bug report that while this could be considered WAI, there is still a feature imparity that should still be settled somehow.

That pe handles them differently is pe's fault, both pc and ce have them as entities.

@unknown, please refrain from repeatedly editing your comments. An update email is sent for every edit, and I have over 30 emails from your edits alone.

[CubeTheThird]: Oh, sorry about that. I didn't realize that that happened.

NEW: The observer block not detecting when the player adds a plant to flower pot. 🙂 (It would be ideal to comparator according to plant 😉 )

Confirmed in 16w39c

I have four more changes to suggest for the bug description:

1. Observer blocks don't detect ferns growing into large ferns either, so:

"Grass grows to tall grass"

Should probably be:

"Grass/ferns growing into tall grass/tall ferns"

2. Neither adding nor removing bottles/potions to/from brewing stands causes block updates, so:

"Placement of a glass bottle (empty or filled) in a brewing stand [1]"

Should be something like::

"Placing/removing bottles/potions in/from brewing stands.[1]"

3. I'm sorry to say that I was incorrect when I reported above that natural tree growth didn't cause block updates. I've now tested this with all varieties of trees, including 2x2 dark oaks and jungle trees, and they all cause block updates at their bases (and I would assume to every other block adjacent to the blocks created when they grow) when they naturally grow.

When I tested this the first time, I used a single sapling next to an observer block connected to a note block. I must have somehow just missed the noteblock going off that time. I apologize for this mistake. I hope that I didn't waste any of the developers' time by giving that false positive bug report. I'll be more careful in the future.

4. I hesitate to mention the following, because I actually think that this is a great feature that shouldn't be "fixed", but I'm guessing that somebody else will add it on to this bug report at some point anyway if I don't. And if I add it, I can at least add an argument about why it shouldn't be "fixed":

When Lilacs, Rose Bushes, Peonies, Tall Grass, and Tall Ferns are placed or broken, the upper blocks of those plants to not update the blocks adjacent to them. This is the only remaining means I'm aware of by which we can create floating sand, gravel, anvils, and dragon eggs in survival mode (by placing the gravel or whatever on the block immediately above the 2-block high plant, against the side of another block, and then that breaking that plant). It's great ability to have for creating traps and interesting aesthetics, and I would suggest that it not be removed.

If the mod who adds this point to the bug description above could also add the argument for why this feature should not be removed (perhaps in parentheses), I would appreciate it. Thanks.

So, I mentioned in my last comment how players can take advantage of trait of 2-block high plants not updating the blocks surrounding their upper blocks when they're placed or broken to make floating gravity-affected blocks without the use of mods or external map editors. My primary purpose in mentioning that feature at all is that I saw it as likely being inevitable that it would be added to this bug report, and I hoped that by me being the one who brought it up, I could perhaps influence things so that when was listed, it was listed with some note of how some Minecraft players would like that feature to remain in the game. I hoped that it would be listed in the bug description as something like this:

"• The upper block of a 2-block tall plant (e.g. tall grass, rose bush) replacing/being replaced by an air block when that plant is placed or broken (MC-31038) (Some players would like this feature to remain in the game because of how they can use it to make floating gravity-affected blocks.)"

However, when it was added, it was simply added like this:

"• Placing/breaking top part of a double plant (MC-31038)"

I know that there are many players who appreciate this feature being in the game, and I would like that voice to be represented in some way here. I'm concerned that the developers might assume that this comment thread is just made up of us adding additional block state changes that don't cause block updates to the list, and miss the concern I expressed that about the idea of making the placing/breaking of 2-block high plants update all surrounding blocks. So I'd like to request that that concern be represented in the bug description, perhaps using the language I suggested above in this comment. Do you (the mods) feel that that's a reasonable request?

Add Observers can't detect the on/off of a button/pressure plate only when the observer is directly powering a dispenser/dropper. If the observer is connected to the dispenser/dropper by redstone it will detect the on/off and cycle twice. See MC-108745 for how to reproduce.

The growth of 2x2 spruce trees also doesn't trigger block updates. see MC-92630. All other trees are detected.

I suspect that chest, shulker boxes, and ender chests opening and closing are not meant to cause block updates, since the block itself doesn't actually change when this occurs.

The observer only detected upgrade top of the door if opened/closed with energy (button, lever, etc.), not with your hand.
Its bottom is always detected... But its top, only detects if opened/closed with energy; Opened/closed with hand is undetectable.
https://bugs.mojang.com/browse/MC-109659
Snapshot: 16w44a

Should add these to the list: (as changes to these states are NOT detected for the following blocks 1.11-pre1)

• Connecting / Orientation (north, south, etc) State for Cobblestone Walls

• Shape State for Stairs

• Snowy State for:

  1. Dirt

  2. Grass Block

  3. Coarse Dirt

  4. Podzol

  5. Mycelium

Something that that I think is worth noting is that the issue of observer blocks not detecting chests opening is a little different from the issue of them not detecting all the other block state changes listed in the description above, since opening a chest does actually update adjacent blocks (detectable through adjacent floating gravel blocks, budded pistons, unupdated water, etc...); it just doesn't activate observer blocks.

The issue of observer blocks not detecting all other listed block state changes above seems to stem from the underlying cause that those block state changes don't actually cause block updates in the current version the game (1.11). The issue of observers failing to detect chests opening seems to be uniquely different in that it's the only actual block update in the current version of the game that observers are unable to detect.

It would be my preference for this issue to be resolved by making observers detect chests opening (rather than by making opening chests stop causing block updates), since that's a useful, interesting tool for us to have, and why not. I recognize that if chests were made to stop causing block updates, we could still use trapped chests to do the same, and I guess that that would be fine, but on an intuitive level it makes sense to me that if we imagine the mechanic of block updates being disturbing carefully balanced systems (e.g. a block of water held together by surface tension that will begin to flow if disturbed, a stuck piston that will snap back into position if jostled, a mass of gravel barely holding together over a gap that will fall at the slightest vibration), opening a chest next to one of those systems would be enough to disturb it.

I was going to open a ticket for the pumpkin stems issue and found this one.

That's weird because observers do detect a stem getting older. I thought observers detected all changes of block data?

Some block states are read only and not saved server side yet, see MC-109591, that's why the stem's facing value has no effect.

Interesting! So that covers essentially all the data used for graphical/aesthetics details?

I would like to add to this list if possible: Clocks set in item frames. I'm not sure if intended, or not, but it did put a damper on an idea I had, where a daylight sensor wouldn't work, being underground. I ended up making an etho clock instead, which used up way more room than intended.

@@unknown Item frames are entities, not blocks.

@@unknown Maybe what @unknown was referring to is the fact that the change of time on a clock in an item frame cannot be detected currently, the event (questionable) not causing a block update. Which detecting the change of time event with a clock would be a nice feature I think.

That'd be a feature request and rather a weird implementation IMHO.

Apparently Dirt & Coarse Dirt no longer have a snowy state, thus observers cannot detect this state change.

The bug with activator and detector rails is not solved yet! I was playing 1.12.2 and the printer that uses observers with detector rails in front stopped working.

observers detect block state changes all what you have listed does not cause a block state change therefor the observer does not react

Confirmed 18w14a/b
Side note:
Now from 18w10d to lastest;
The water/lava doesn't make block update to the observer because of the new Water mechanic.

I would be really pissed off if Minecraft 1.13 came out without getting this fixed!
It's so easy to make Stone Generator with 1 Observer ：）
Last version with water/lava making block update is 18w09a
Here is a quick view of what is happening now:
https://youtu.be/sM7fzp62V0E
*Accidentally left my micro off, no voice sound.

Snapshot 18w22b: Observers do not detect "Nether portals be lit/activated" shown as fixed in 16w44a.

1.13.2-pre1: As far as I can tell the current list of affected blocks/events have no state that an observer could detect:

• Shulker Boxes opening/closing

• Chests opening/closing

• Ender Chests opening/closing

• When a command block is successful

• Changes to inventory of any blocks that comparators measure as containers

• Beacon activating/deactivating

• Something teleported by the end gateway

Perhaps additional states to these blocks could be added. Shulker boxes do change size where it can move entities. I think the (ds)active state of a beacon should be detectable.

Minecraft 1.13.2 and Snapshot 19w09a: Observers do not detect "Nether portals be lit/activated", shown as fixed in 16w44a.

Sapplings growing is also not detected. See https://bugs.mojang.com/browse/MC-131014

Confirmed for 1.14 Pre-Release 1 and 1.14 Pre-Release 2

Still in 1.14 pre-3, 1.14 pre-4 and 1.14 pre-5

Still in 1.14 Release

Still in 1.14.1 Release

Still in 1.14.2 Pre-Release 1 and 1.14.2 Pre-Release 2

Confirmed for 1.14.2, except: Opening and closing a shulker box now triggers an observer twice, once at the beginning of the opening/closing animation and once when it ends. Not sure this is intended.

Also need to add to the list, observers do not detect when a solid block becomes powered (or unpowered) by a redstone power source.

Observers only detect block state changes and powering or depowering doesn't change the state of a block
A normal block has no idea if its powered or not, unless it checks all the blocks around to see if a rep or dust is pointing into it

Observers also don't react to fences/walls/bars/panes that update their north/south/east/west states when a tree grows next to them. In contrast, observers do react to the state change of fences/walls/bars/panes when large mushrooms grow next to them. This has been an issue since at least 1.14.

Observers do not detect when brewing stands finish brewing a potion. 

Can confirm in 21w05b.

Can confirm in 21w07a.

Observers also dont detect setting spawnpoint in bed/respawn anchor (i know that the block state of the bed/repspawn anchor does not change but i thing that observers should send redstone signal when setting respawn point)

and also they dont detect opening/closing trapped chest

Can confirm in 1.17, except that "Grass blocks changing into podzol blocks when a 2x2 spruce tree grows" was fixed in one of the 1.17 development versions.

Can confirm in 1.17.1 Release Candidate 2.

Can confirm in 21w37a.

Can confirm in 21w44a.

Are observers meant to detect if a player punches a note block to make it play? If so, it is not detecting it in 1.17.1

Affects 1.18.1

— Observer blocks do not detect the following block state changes
This is incorrect. Since the following are not block state changes:

• Chests opening/closing - Block Entity

• Ender chests opening/closing - Block Entity

• When a command block is successful - Command execution in block entity

• Beacon activating/deactivating - Effect calculation in block entity

• Something teleported by the end gateway - onCollision() executed in block entity

• Ringing a bell by hand or by projectile - activate() in block entity. Although should be done in onSyncedBlockEvent()

• Brewing stands finish brewing a potion - Inventory change

• Ender dragon head being powered/unpowered - Block Entity tick()

• Left clicking a note block - Not a game mechanic, nothing happens when left-clicking a note block

Would be nice if we could change the description to properly group all these "events"

Grass blocks changing into podzol blocks when a 2x2 spruce tree grows seems to cause shape updates now, so observers can detect it

Can confirm in 1.19.3

Can confirm in 23w03a

Can confirm in 1.19.4

does this also affect piglin heads in the same way it does the ender dragon's?

can confirm in 1.20 Pre-release 1

Can confirm in 1.20.1 and 23w32a

Might like to add that interactions with decorated pots, despite displaying an animation, do not cause observer updates. This is in the same category as opening/closing chests as this is not a blockstate change but intuitively should cause a detectable update.