Talk:Block entity

Other blocks

Would Redstone wires/torches/repeaters, maps, doors, levers, buttons and pressure plates be considered tile entities as well? Monchoman45 22:21, 9 June 2011 (UTC)

No, redstone-related items' state is stored in their 4-bit data field, or even by changing block ID (torches do that). Maps are never blocks. Open up your world in the latest MCEdit and it will highlight everything that's a tile entity in yellow. —KPReid 22:48, 9 June 2011 (UTC)

Is it just me, or is this sentence's wording hard to follow? "End Portals have tile entity data, if the frame its if the eye of ender is in or not, if not its unsolved." --24.251.190.43 04:04, 28 November 2011 (UTC)

i agree, will attempt to make the sentence more readable, if i can discern its meaning√Onion=Shallot 07:02, 12 April 2012 (UTC)

Wouldn't wheet have one aswell for which stage of growth it is at? Same with melon/pumpkin stems? Not %100 sure. Anyone know more?

No, they just have additional data as most blocks have. --☺ Sven ^{? !} 14:16, 2 July 2012 (UTC)

In the new snapshot cauldrons and End portal frames are Tile entities (the cauldron has been a tile entity before), so, soon there is a tile entity that can be pushed by a piston. --MinecraftChrizz 11:44, 20 June 2013 (UTC)

I cannot confirm this. What is the name of the tile entity for cauldrons? Cauldron is already being used by Brewing stands, and the end portal tile entities are useless (just a technical quirk). LB^(T|C) 02:11, 21 June 2013 (UTC)

Also, if a block moveable by pitons gets a tile entity, it will probably also automatically no longer be movable by pistons. Pistons check to make sure they're not about to move a tile entity. LB^(T|C) 02:13, 21 June 2013 (UTC)

There is a Tile-Entity-Update-Detector (BUD#History there's a link to a video in the last sentence.) It detects all placements and updates to tile entities. In 1.5 it detected all the items from the list. In 13w15c however it also detects the placement and updates to a cauldron and an End portal frame. --MinecraftChrizz 07:03, 21 June 2013 (UTC)

The TEUD is actually responding to block updates caused by redstone signals, not tile entities themselves. Cauldrons and end portal frames produce signals detectable by comparators, as do jukeboxes, note blocks, and all sorts of container blocks. Detector rails (redstone signal, no tile entity) also trigger this device, but monster spawners (tile entity, no redstone signal) do not. -- Orthotope ^talk 09:43, 21 June 2013 (UTC)

The TEUD detects both normal updates and Tile entity updates, this is why it also detects redstone signals. After some testing it seems that it only detects Tile entities that can update in-game (so it won't detect block like enchantingtable and enderchest) Anyway, I'm not 100% sure if the Cauldron and the end portal frame have tile entities now, but at least something changed, because in 1.5 the TEUD doesn't detect them and in the snapshot they do. Also it's not true that the TEUD only detects blocks that can be taken a comparatoroutput from, it also detects the placement of signs. --MinecraftChrizz 13:52, 21 June 2013 (UTC)

It doesn't detect cauldrons and end portal in 1.5 because they didn't produce a signal until 13w18a; see Redstone Comparator#History. I'm not sure why it reacts to the placement (but not removal) of signs. -- Orthotope ^talk 17:34, 21 June 2013 (UTC)

What I think is that the TEUD only detects blocks that can be changed in-game, also it's not a surprise that it detects detector rail, because you can take a comparator-output from it. (maybe detector rail is a Tile-entity as well or maybe it is an exception to all other blocks that you can take a comparator-output from) Anyway, I don't know how to check if something is 'officially' a Tile-entity, but I think my explanation makes sense. --MinecraftChrizz 18:38, 21 June 2013 (UTC)

You can check if it's officially a tile entity by making a superflat world that nothing else generates in (e.g. redstone ready with generate structures off) and place the block in question. Then save the game and open it with something like NBTExplorer, and search for a tag named "id" ("id" is used for both entities and tile entities, be careful) and check the coordinates. LB^(T|C) 20:55, 21 June 2013 (UTC)

Jukebox

The Jukebox now have tile entities? Was it changed with Beta 1.8 or was the old information just wrong? --☺ Sven _{Kein Schwein ruft mich an!} 16:25, 21 September 2011 (UTC)

Yes. How the Jukebox play the specific music without it being a Tile Entity? 112.200.104.11 03:07, 16 June 2013 (UTC)

Jokeboxes have a tile entity to properly store the record and any proeprties (such as having been renamed with an anvil). See Chunk format#Tile Entity Format and look at the information for RecordPlayer. LB^(T|C) 15:18, 16 June 2013 (UTC)

Blocks Moved By Pistons Error

The page says Every tile entity cannot be moved by Pistons. Blocks moved by Pistons are as usual, already moved by a piston.

Please correct it. 112.200.104.11 03:07, 16 June 2013 (UTC)

Block 36 just has the very unfortunate name of "block moved by piston". It actually just saves a moved block temporarily because blocks can't be moved like entities. Instead the block disappears and appears one block further away. --☺ Sven ^{? !} 09:57, 16 June 2013 (UTC)

Yes, as Sven said, that's just the name of the special block that Minecraft uses to create the visual of moving the block. It can not be moved by pistons, instead it is used by pistons to move other blocks. LB^(T|C) 15:18, 16 June 2013 (UTC)

Block entity vs. tile entity

The history says the phrase "block entity" comes from the debug screen, but I can't find it. Does anyone know how to find that phrase in Minecraft? We're still using the phrase "tile entity" in , chunk format, etc. —munin · File:Grid Book and Quill.png File:Grid Stone Pickaxe.png · 20:04, 28 August 2014 (UTC)

Mojang doesn't seem to have made a big deal about the name, but they have used the term "block entity" in some release notes, such as 14w07a. There's also the BlockEntityTag NBT tag. Haven't been able to find it anywhere else in-game, though. -- Orthotope^talk 20:34, 28 August 2014 (UTC)

After searching for "tile entity" and "block entity" in crash reports on bugs.mojang.com, it looks like "tile entity" tends to occur in older reports (mostly 20k-ish and under) and "block entity" occurs in newer reports (30k+). That makes me feel more confident about using "block entity". —munin · File:Grid Book and Quill.png File:Grid Stone Pickaxe.png · 20:03, 21 September 2014 (UTC)

To continue with the discussion: the NBT structure for tile/block entities still uses "TileEntities". It could be that Mojang just isn't going to change that name, but should it be changed everywhere on the wiki to "block" when it's called "tile" in the structure? Personally I don't think it should deviate from its technical name, especially when used on a technical page. Skylinerw (talk) 00:33, 8 December 2014 (UTC)

Having various tags that refer to them both as 'tile entities' and 'block entities' (see my comment above) complicates this somewhat. Since Mojang seems to be using 'block entity' nowadays, I think that should be the primary term we use here, while noting that both terms are valid (e.g., "Block entities (also called tile entities) ..."). Changing the names of old tags can be done, but it's a lot more trouble than it's worth in this case, which is probably why Mojang hasn't renamed them. -- Orthotope^talk 03:32, 8 December 2014 (UTC)

Tile entity ticks

@Template:Ping: MCP 1.9, class World, method updateEntities. That's covers "tickable tile entities" (AKA member variable tickableTileEntities), the list of which can literally only contain classes extending TileEntity and implementing the ITickable interface (which, as far as "blocks" are concerned, is only implemented for tile entities). The major difference between tile entity updates and regular non-tile entity updates is limit. All tickable tile entities will be ensured to be ticked every tick. Normal block updates, such as for command blocks & frosted ice, have a limit of 65536 blocks per tick (while random updates for blocks like fire/ice are dependent on the randomTickSpeed gamerule). So yes, it is very much a valid point that is necessary to state. If you have any source evidence against this, please state. Skylinerw (talk) 01:39, 9 April 2016 (UTC)

Looking at it further, you probably are partially right. But scheduling block updates is not a tile entity function. It's a world function that does queue itself. 1000 items in the queue are processed each tick (not 65536 / 0x1000), after which they are removed from the queue and put into a separate list (pendingTickListEntriesThisTick). That processing happens in World.tickUpdates. Scheduling updates isn't a Tile Entity function; it's used for all block updates (both delayed and normal). The scheduled update receives a callback on Block.updateTick, also used by random updates. Note that this is on the block and not the tile entity.

However, ITickable is for stuff that should happen every tick. But not all tile entities update each tick, only some (for instance, TileEntityBanner doesn't do per-tick updates and doesn't implement ITickable).

And "normal" block updates do something else as well. They don't go through the queue but instead immediately update upon nearby blocks changing. This can be seen in World.setBlockState(BlockPos, IBlockState, int) which calls World.notifyNeighborsRespectDebug (there are other methods that also call this, such as when a golem spawns), which then calls World.notifyNeighborsOfStateChange, which then calls World.notifyBlockOfStateChange on all surrounding blocks, which then calls Block.onNeighborBlockChange. That's entirely separate and unqueued.

Overall, are right about updateTick not being what I thought it was; it isn't a per-tick function but instead an update-like function. I blame MCP for that (it's a confusing set of names probably caused by a confusing set of distinctions which have lost their comments). I still don't think it's a core characteristic of tile entities that they receive per-tick updates, but nonetheless I agree that it should be mentioned in some way. Perhaps phrased like this:

“

Additionally, some block entities receive updates to perform actions each tick (such as updating smelting progress in a furnace or changing the current signal strength in a daylight sensor).

„

TLDR: Scheduled updates aren't a tile entity function, though they are queued. Block updates from nearby blocks are not queued. And some tile entities do receive an update each server tick, but not all of tile entities do this. --Pokechu22 (talk) 02:51, 9 April 2016 (UTC)

Based on the fact that normal blocks cannot schedule their own ticking, I think it is worth noting that tile entities can perform that function. Yes, the function is not exclusive, but it is more important to state that the function cannot be done without them.

The fact that scheduled ticks for tile entites is opt in (for the sake of performance) I think is a point worth stating on the article rather than something that means it should not be stated at all, as again blocks without tile entities cannot opt in at all. –KnightMiner ^t/_c 19:13, 9 April 2016 (UTC)

Misleading/incorrect use of terminology - "block entity"

Paragraph one says "A block entity ... is extra data ..." Paragraph two ends with "Block entities can be moved by pistons.‌" This makes no sense whatsoever. Data cannot be moved by a piston. I assume the author meant to say that blocks with entity data can be moved by pistons. If that were the intention, it still makes little sense. Why would the presence (or absence) of "extra data" make a block (im)movable? Atypicaluser (talk) 11:59, 25 February 2020 (UTC)

In Bedrock edition, chests, furnaces,... which have block entities are movable by piston, while in Java edition they are not, because the developers haven't considered implementing that yet. But I do agree that the wording is a bit wrong. Lê Duy Quang (Make some words | Contributions) at 12h03:01 – 3 | 25/2/2020 (UTC)