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)
Linked issues
relates to 2
Attachments
Comments 13
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.
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.
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.
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.
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.
I'm attached a video. So this should be needed. the comparator needs to reading the containers constantly.
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