Comparators have tile entities to store their power level. This is different than all other redstone components, for example redstone dust.
The only case where this might get used is if a chain of subtracting comparators with nothing in between was placed on a command block that outputs a signal strength of more than 15 (using redstone in command block contraptions is discouraged anyway and I've never seen this special arrangement being used) or when trying to read a power level over 15 from a trapped chest (which can only happen if at least 16 players open the same trapped chest at once, which should be an extremely rare occurrence).Having a tile entity in comparators *might* also be needed to read the rotation of an item frame or the fill percentage of a minecart chest/hopper, but it might not be needed, this was discussed in the Eigencraft Discord, but not with no clear conclusion.
If this extremely unlikely case can be ignored and the third one does not need a tile entity, then performance can be improved by saving the power level in a block state instead.
(split off of MC-159902)
Related issues
clones
relates to
Attachments
Comments
migrated
RedCMD
Loading and unloading a block entity is very laggy
Having a few hundred comps in a chunk can cause massive lag spikes when loading/unloading that chunk
NeunEinser
Comparators do definitely not need BEs for reading item frames or detector rails. I happen to know the related code quite well.
That the signal of a comparator can exceed 15 is a bug and does not need to be kept.
NeunEinser
Added patch file witch shows the needed diff for the removal. Additionally, the block entity class and its reference in BlockEntityType should be removed as well.
I tested item frames and detector rails in particular with this, and they still work.
Needed to adjust AbstractRedstoneGateBlock and RepeaterBlock slightly, because AbstractRedstoneGateBlock currently holds the reference for the POWERED block state, which is not needed for comparators anymore.
Mostly moved some code from AbstractRedstoneGateBlock to RepeaterBlock, which should have been defined there in the first place. The ComparatorBlock actually overwrites most of these methods anyways, making them only apply for RepeaterBlock in the first place.
Note: It's recommended to view that file in a text editor that supports syntax highlighting, in particular for .patch files.
pulpetti
In 1.16.1
migrated
Overloaded comparators (signal exceeding 15) being removed is a shame, it is a very useful feature with many applications (such as with encoded storages). That being said, better performance would be appreciated.
My main concern is how this change may effect redstone machines which make use of technical properties of comparators. For example, would this change remove instant comparator lines? They are an essential part of many encoded machines. Would this change effect comparator updates? They are essential for many storage devices.
Please try to keep the comparator's feature set the same throughout this change whenever possible. The comparator is a fundamentally important component.
FaRo1
I looked up "overloaded comparators encoded storages" and the only useful result was this: https://www.youtube.com/watch?v=R5VuagERLWA
It uses a bug to stack books and mentions using this in a storage system somehow, but wouldn't you only get up to power 15 unless you intentionally cause buggy stacks?
4ebugger
This one might be needed, because items in item frame or tile entity's data changing do not update the nearby block. Comparators need a tile entities to make the redstone signal updating constantly, when the nearby tile entity's data changed or item frame updated.
FaRo1
Plenty of entity actions update blocks, for example pressure plates. No constant checks are needed for that.
Narnianknight
Another reason to not fix is that observers would detect changes in signal strength. Many storage devices detect changes in compator state, and signal strength state changes would break them.
4ebugger
The Item frame detection is might not needed, but the storage detection is must needed that. The items in the storage needs to be checked constantly, if the tile entities was been removed, the comparators will no longer check the items in the storage that being transferred by hoppers.
kelianor
Affects 1.20.5
4ebugger
I'm attached a video. So this should be needed. the comparator needs to reading the containers constantly.
FaRo1
The video shows that inventory changes do not cause the regular old block updates, but many things already do not rely on those anymore. NeunEinser tried it and it seemed to work, so I would consider this report proven valid.