[Feature Request] use tags for Blocks

[end-user]

It would be great if we could use tags instead of block ids. For example #beds or #shulkers rather than adding all the different colors.

Alternatively, if the Blocks could have groups that share settings and be en/disabled together.

Also, be able to reorder the list.

[Zergatul]

I was thinking about this in the past. I was also very annoying for me to add all shulkers, or beds, or all type of signs. But I didn't come up with good idea how to implement this without rewriting big part of block esp code.

[end-user]

The point you do the comparison is on BlockFinderController, line 206, right? Maybe if the block could be compared to a list of ids; like if (blockList.contains(state.getBlock()) I think the tag list can be pulled from the Registry. One challenge though is I think servers can define their own tag lists. I don't know if the client can see or use them. But being able to group blocks together would be useful, for example, suspicious sand and gravel do not have a tag, but should be searched together.

[end-user]

The other thing that would be helpful (though it's pretty minor) would be block state compare too. That would let you separate, for example, chests from double chests. JsMacros does it through creating filters for the comparison.

Getting a little off-topic, another feature that would be nice would be finding buried treasure and desert temples. These would have to be hard-coded searches; the buried treasure is a single chest in the 9x9 chunk location (though you'd need to limit Y depth). The desert temple is a stone pressure plate with a single chest 2 blocks in each direction. Or, test for 3x3 tnt 2 underneath.

[Zergatul]

The code you pointed out runs only if you are ingame and you added new block to the list. Method private void checkBlock(BlockState state, BlockPos pos) checks for block in all other cases, like when server sends you a chunk, or when server sends you block update packets. The second reason I didn't add this feature was it requires a lot of UI code changes, possibly even more than java code.

I don't know if the client can see or use them.

Normally client can see all tags. But nothing prevents you from implementing mod that adds new tags that are visible only on the server side.

I don't know if the client can see or use them. But being able to group blocks together would be useful, for example, suspicious sand and gravel do not have a tag, but should be searched together.

I was also thinking about this, but again this requires tons of UI changes.

[Zergatul]

The other thing that would be helpful (though it's pretty minor) would be block state compare too.

I had similar idea to add script where you can write custom conditions for block search. Like checking neighbor blocks, or filter out blocks by Y coordinate.

[end-user]

Well, the first step would be just to establish the block config as containing a list of blocks rather than just one. The rest of the properties could still apply (color, tracers, etc). Then, the UI would need to nest those blocks under the property config.

I don't know if the tags are present/queriable from the client. It could be they're exposed on a wiki api somewhere. If so, you could let the user choose from known tags and populate the block list from that. Though most of the tags aren't useful for block finding (no one is going to want to highlight #wood).

[Zergatul]

Block groups added. For other things you can create separate topics.