Robin Claassen

Yes, the issue is still manifesting itself if 1.12.2. Though it appears to be manifesting itself a little differently now. Instead of the paintings dancing between being displayed 1 block away from their actual positions indifferent directions, they're now disappearing entirely.

You can still observe this issue in the attached Clash of Elements 0.2.1.zip world. In order to do so, you need to restart the old-style redstone fill clock that's running the "/entitydata @e {NoAI:1}" command at 20hz, which is stopped when you first load the map in 1.12.2. In order to do so, you can enter the commands:

/setblock 66 4 -1277 air

then:

/setblock 66 4 -1277 redstone_block.

Wait a few seconds, and you'll see the paintings disappear. Any paintings that you place after that point will also disappear within a few seconds of placing them.

They still show up on the F3 entity count as entities that are within render distance but not being rendered (i.e. placing a single painting in the middle of nowhere over the void will make the entity count read as E: 0/1 after it disappears). When the wall that a painting that's been made invisible through this means has been placed on is destroyed, that painting will reappear as a painting item entity.

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.

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?

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.

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

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.

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.)

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.

I'm noticing that this issue is still marked at "unconfirmed". If I'm understanding your confirmation standards correctly, it should be easy to confirm by logging in to the attached

world, waiting 10 seconds or so for the issue to manifest itself, then breaking the command block with the "/entitydata" command at x:68.5, y:4.5 z:-1277.5, and then going back to the paintings to see that the issue is no longer present.

I had the same experience that Mario reported above. When I created a superflat world and tried to duplicate the "dancing paintings" issue there (

), I instead had most of the paintings turn invisible, so there must be some other factor at play that determines which of the symptoms appears.

I also tried testing the issue on SethBling's "Building Game" map (http://sethbling.com/TheBuildingGame), which is the map on which this issue was reported in MC-72888, and also had the paintings I placed disappear there. But we know from Sethbling's video (http://youtu.be/VtyUKFu6bl8?t=5m53s) that the offset issue can also occur on that map, so maybe the /entitydata command that affects paintings needs to run certain number of times before you get the affect of paintings appearing to be in positions that are offset from where they're really placed, and before that point you get the disappearing effect, or perhaps the world needs to be a certain age or greater.

If you'd like to see a world where you can see the offset effect, here's a download link for the world in which I first experienced the issue, and from which I took the screenshots above:

In that world, the command block that's giving the /entitydata command is located at: 68.5 4.5 -1277.5, if you'd like to verify that breaking that block makes the issue go away.

Also, it should be noted that the effect typically takes around 7 seconds or so after logging in, and after placing a painting on which you want to see it manifest itself on, before it actually manifests itself.

@Mario Welzig: Good observation! You just made me realize that I haven't seen any 1x1 paintings be affected by this issue either.

Below is a copy/paste of the comment I left on MC-72888, which appears to be a duplicate listing of the same bug. Kumasasa requested that I leave this comment here as well:

Confirmed for 1.8.6. This appears to be related to using the "NoAI" command. This bug was constantly occurring when I had a 20hz fill clock in my spawn chunks running the following command:

/entitydata @e {NoAI:1}

and it stopped as soon as I deactivated that clock.

Description of bug:

Some (but not all) placed paintings appear to "dance" around the locations where they were placed, alternating at an irregular rhythm (perhaps averaging 2 seconds between each state change) between 3-4 states, sometimes appearing to be where they were actually placed, sometimes appearing to be placed above, below, to the sides of, or in front of where they were actually placed, sometimes appearing to be imbedded in other blocks or placed in the air with no backing. All paintings that change states do so at same times, and all paintings that change states with the same facing appear to move in the same direction at the same time.

Attached are 3 examples, each with 3 screenshots showing the states that those particular paintings cycle through when the clock that activates the NoAI command is active. I also attached a report from a crash that I forced in a world where this issue was occurring.

Confirmed for 1.8.6. This appears to be related to using the "NoAI" command. This bug was constantly occurring when I had a 20hz fill clock in my spawn chunks running the following command:

/entitydata @e {NoAI:1}

and it stopped as soon as I deactivated that clock.

Description of bug:

Some (but not all) placed paintings appear to "dance" around the locations where they were placed, alternating at an irregular rhythm (perhaps averaging 2 seconds between each state change) between 3-4 states, sometimes appearing to be where they were actually placed, sometimes appearing to be placed above, below, to the sides of, or in front of where they were actually placed, sometimes appearing to be imbedded in other blocks or placed in the air with no backing. All paintings that change states do so at same times, and all paintings that change states with the same facing appear to move in the same direction at the same time.

Attached are 3 examples, each with 3 screenshots showing the states that those particular paintings cycle through when the clock that activates the NoAI command is active. I also attached a report from a crash that I forced when I looking at one of the paintings dancing in-game.

Also, this issue appears to be a duplicate of MC-80638.

Piston extension blocks may not have been "intended" for use by mapmakers, but there are many blocks in Minecraft that are commonly used for purposes that they were not intended for. One of the essential qualities of Minecraft that makes it great is the openness that allows players to use anything in it in ways that the creators of the game may have never considered.

I think that it's important to consider that piston extension blocks are very useful to mapmakers in many situations, including:

• Preventing players from building beyond a certain boundary in situations where you want to allow entities to pass through that boundary. Example: in the PvP map "Rampart", by the Whiskey Brigade (http://redd.it/23j676), the area underneath the course is filled with Block 36. This is to prevent players from bridging underneath the course (which the mapmakers determined had a negative affect on gameplay) while preserving the hazard of players falling into the void in area where creeper and TNT blasts had occurred (which the mapmakers determined had a positive impact on gameplay). Another way to theoretically solve this issue would have been to lower the bottom of the map to y = 0, but that would have introduced the issue of asymmetrical slime chunks between the two otherwise symmetrical sides of the map. (As a side note, if you could make slime chunks editable in the same manner that biomes are, that would be sweet.)
• Controlling liquid flow - This is notably useful for Race for Wool maps that contain unupdated water/lava blocks facing the void lane, that the mapmaker doesn't want to create a mess if and when they get updated during a match.
• Manipulating the mob AI - I admit that I don't know much about this particular usage of Block 36, but I've heard that Hypixel uses them for that purpose in some of their maps.
• Preventing players from accessing chests, brewing stands, etc... or breaking/placing blocks beyond a certain barrier when you don't want to totally cut them off from that area or put them in Adventure Mode.
• Filling up air blocks where the mob spawn calculation could start to prevent mobs from spawning in certain areas. Example: I'm working on a PvP map in which it's important for the starting platform to be above a certain area of the course itself which is set to the Nether biome. I couldn't prevent mobs from spawning on the starting platform by eliminating viable spawning areas on the starting platform (because I needed some of the horizontal surfaces to not be transparent), or by keeping the light level high (because Nether mobs can spawn in high light levels), so I solved the issue by covering the horizontal surfaces with carpet, and filling the surrounding air within a 13-block horizontal radius with Block 36.

If it would be prohibitively difficult for you to make piston extension blocks feasible for use by mapmakers again, I would encourage you to add a new block with the same functionality that doesn't have the lag issues that piston extension blocks have had since 1.8.

Thanks for your time, and thank you for all of you work making Minecraft the great game it is.