[1.12.2] Recalculate comparator output of a block every tick without a tile entity

[Aarilight]

I want to make a block that updates its comparator output every tick, preferably without having to create a tile entity for it (because it can be used as a building block and for beacon bases as well... making a tile entity for all of them and updating all of them every tick sounds like an issue). Is this possible?

(I've already Overridden hasComparatorInputOverride and getComparatorInputOverride)

Edited December 25, 2017 by Aarilight

[Aarilight]

I saw another thread (from a long time ago, tho) which recommended I use setTickRandomly(false);, set the tickRate to 1, and use onUpdate, but I couldn't figure out what onUpdate was referring to. Is this what I should be doing to update the comparator? If so, what is onUpdate referring to? It doesn't seem to be updateTick, as that seems to only be called by random ticks, which I'm disabling.

[Aarilight]

Hmm, okay. Is it possible to only create a tile entity if there's a comparator that's connected to it? I doubt there's official methods for that, so do you think it would be worth it to attempt to do that?

[Aarilight]

onNeighborChange only seems to be called when I destroy a comparator, not place it, and it doesn't work if the comparator is placed two blocks away. Is there another event I could use to detect this? I could switch to the comparator blockstate when hasComparatorInputOverride or getComparatorInputOverride are first called, I think that would be fine, but would detecting the comparator being destroyed only be possible via looping through all the valid comparator locations?

[jabelar]

Why don't you want to use a tile entity? This is exactly what they are meant for. There really isn't a more efficient way, because you'll end up basically making your own tile entity system. You can't get around the performance impact of having multiple blocks checking multiple locations around themselves every tick. 

 

When people say that tile entities cause performance problems they don't mean that tile entities themselves are a problem, it is just that whenever you want lots of blocks doing complex logic every tick it costs performance.

Edited December 25, 2017 by jabelar

[Aarilight]

I'm not really worried about a few blocks, but I like the look of the block and want to keep it as a viable building block. Having a tile entity in each of them just sounds really inefficient when it doesn't have to be that way. The comparator functionality is just a fun quirk I wanted to add to the block, not the sole purpose of it.

[jabelar]

2 hours ago, Aarilight said:

I'm not really worried about a few blocks, but I like the look of the block and want to keep it as a viable building block. Having a tile entity in each of them just sounds really inefficient when it doesn't have to be that way. The comparator functionality is just a fun quirk I wanted to add to the block, not the sole purpose of it.

Our point is that a tile entity is NOT inefficient, it is actually super efficient. If you want a block to do something every tick, then you need to scan the world every tick to find all the blocks, then fire their update() code. To find all the blocks you'll want to avoid cycling through all the blocks in the world so you'll create a collection to keep track of all the locations where you placed a block. Once you've done that you've basically created the tile entity! Basically you can't do what you want to do any more simply or efficiently than using a tile entity.

 

Also, why are you mentioning that you "like the look of the block and want to keep it as a viable building block"? Having a tile entity doesn't prevent that. A tile entity is really just a way to tag blocks (that can also act like regular blocks) as also having tickable code. That's it.

 

I think you think tile entities are complicated because some people do complicated logic with the tickable code. For example, you can run a container to make a furnace, or you can create an animated model. But even if you just want a simple variable to record the player that placed the block, you should use a tile entity. 

 

[Aarilight]

But instead of having each of my blocks in a list of tile entities, which are updated every tick, I can instead elect to not have them be in the list unless they actually need to be. It may not be necessary optimization but it's not hard so I don't see the point of not doing it. And it's implemented, so....

Also, aren't tile entities saved to disk, whether or not you save any data in them? Doesn't this technically reduce file size as well?