Block pattern finder

[Dark-Phoenix-01]

There already is /cfindblock feature. Can we have a feature that integrate it to do something more? Like maybe find blocks pattern (Specific bedrock pattern) or even double/tripple spawners?

I understand implementation of this feature might be challenging considering how dynamic the pattern search could be. Maybe scripting could help with it and having some predefined script templates for popular searches.

[Earthcomputer]

I have thought about this a lot, the main blocker is coming up with a 3D regex-like syntax that is powerful enough that it can represent shapes like rectangles. I've dug through some research papers on it but never found anything satisfactory. If anyone knows of any good format do let me know.

A turing machine is a format that can represent any computable pattern, it's equivalent to scripting and we know from 80 years of developing software that something resembling a modern programming language (functional or procedural) is the most user-friendly format we have available for representing a turing machine. However I don't want to add scripting back to clientcommands, I already removed it a few years ago in favour of using an alternative mod, JsMacros.

[Dark-Phoenix-01]

There could be something. It'll still be complex too. However, any pattern mostly always have a reference point or can have a reference point. Hence thereby using relative co-ordinates we can define the pattern itself. So, if we think like this,
A rule set for a pattern: Starts with a reference point. Then accepts multiple rules that defines the pattern corresponding to the reference point. That way we can have some working structure.
Going into detail:
Reference point will accept optional co-ordinate but will use itself as origin for pattern calculation. It can accept block nbt as well.
Now for the rules set, each rule will accept:
Block nbt.
x,y,z co-ordinates relative to the reference. eg x+2,y-10,z+6
Condition check. This is more like condition check for the relative co-ordinate. Can be = or != or range (>,<)
If condition check is range, then accept upper range and lower range, match count under that condition where 0 means no match in the range, 5 means 5 matches in the co-ordinate range and (5+) means 5 or more matches.
A checkbox to inverse the match rule if needed.
And finally rules matching condition. eg (rule1 & rule2) or rule3

This is just a rough idea. I am sure refinements will be needed to make it robust. But as example of how to use the above design to define some specific patterns:
Tripple spawner finder:
Origin> any block any co-ordinate. (Origin is user feet for all spawner activation)
rule 1> block(zombie spawner); Co-ordinates(<x+16 & >x-16,<y+16 & >y-16,<z+16 & >z-16), match count(2+)
rule 2> block(skeleton spawner); Co-ordinates(<x+16 & >x-16,<y+16 & >y-16,<z+16 & >z-16), match count(1+)
Rule matching> rule1 & rule2

Wither trapper bedrock pattern:
Origin > netherrack, any co-ordinate.
rule 1> block(bedrock); Co-ordinates(x+1,y,z)
rule 2> block(bedrock); Co-ordinates(x,y+1,z)
rule 3> block(bedrock); Co-ordinates(x,y,z+1)
rule 4> block(bedrock); Co-ordinates(x-1,y,z)
rule 5> block(bedrock); Co-ordinates(x,y,z-1)
rule 6> block(bedrock);[inverse=True] Co-ordinates(x,>y-3 & <y+0,z), match count(all/3+)
Rule matching> rule1 & rule2 & rule3 & rule4 & rule5 & rule6

Nether roof access passage finder:
Origin > Netherrack (x=any, y=126,z=any)
rule1 > block(bedrock);[inverse=True] Co-ordinates(x,>y-4 & <y+0,z), match count(all/4+)

Now, I am not sure if it covers possible usecases. Also, user learning curve will be a lot high for this. And wrong conditions might cause into infinite search with never matching it. Still, its just a concept. Can be improved as well.