The following blocks have tile entities despite (to my understanding) not needing them:
beds
the base of an extending piston (or retracting sticky piston): the extension progress can be stored in a block state instead
all mob heads except player and dragon heads
potentially comparator: currently apparently used for power levels, which is only useful above 15 if used on a command block (which can be done better since 1.9) and when using subtracting comparators behind it
Related issues
is cloned by
Comments
tryashtar
FaRo1
Why would mob heads need a special renderer? Or beds? There was never a reason given for why MC-122532 is WAI. And why does that need tile entities?
Comparators don't need arbitrarily high output signals, it can at most be 15.
Crops also react to daylight, so why do daylight detectors need a tile entity to query it?
Retracting pistons can only be in a small number of progress states (pistons are complicated, but let's say it's for sure at most 5).
Conduits could be solved differently, but that would require a big change to the block update mechanism, which could be called a feature suggestion. Something like this seems to already be in the works internally, according to a few statements by developers.
tryashtar
I'm not entirely sure on why they need the special renderer for mob heads, but most likely so that it can do the same things that actual mob heads can do (translucent overlays etc). Oh and the dragon head needs to tick so it can animate when powered.
Here is an example of comparator output signal going above 15: https://www.youtube.com/watch?v=Y75KddhKAeI
Crops get randomly ticked, daylight detectors would prefer not to do that so that they work when random ticks are disabled, and so they work consistently instead of randomly.
Technically piston arm progress is a float so it uses the special renderer.
FaRo1
Comparator: So you need a bug to get the signal strength over 15 and it does almost nothing and behaves inconsistently with e.g. redstone dust? Then that is the bug, not the other way around.
Piston: It wouldn't need to be a float.
FaRo1
So, should this report be reopened with only piston base, zombie head, skeleton head, creeper head, comparator and bed?
muzikbike
I'd say so. Also include wither skeleton skulls, and maybe also mention wall signs - these would still need a block entity for text, but the rendering part could be replaced by a block model.
Pistons use a block entity to track their push distance while pushing; I believe it's the same one that the block being pushed uses.
Enchantment tables, end portals, end gateways, ender chests, mob heads, beds (MC-122532), and bells need to use the block entity special renderer.
Daylight detectors need to tick consistently to query the daylight.
Conduits need to tick consistently to check for blocks and attack mobs.
Comparators need to store an arbitrarily high output signal. And since block states are "enum-like" and pre-iterated, this would not be possible to include.