Pattern viewer for forum threads

[confocaloid]

From my testing, period maps in [R]Extended appear to work just about perfectly, with the important exception of the [R]Extended cells themselves, as they either render as background cells, p1 cells or p2 cells when they shouldn't.

I need to better understand which StateInvestigator states are on and off. From looking at Rule:StateInvestigator it doesn't appear to define whether state 14 is on or off. Also states 17 to 20 are problematic since whether they are on or off depends on whether we're calculating births or deaths. So if I see a state 17 cell in a pattern do I add it to the population as a live cell?

As a side note it would have been better if the odd numbered states were ON and even OFF as for [R]History and [R]Super.

As a possibility, maybe count *only* state-1 cells for the statistics? Since only state-1 cells can be affected by other cells in the pattern, it would make sense to ignore cellstates >= 2 when counting population (or count them separately).

I believe state-14 cells are neither "on" nor "off". (Assigning either "on" or "off" to them would be arbitrary and would not affect the evolution, because a state-14 cell always changes all adjacent state-1 cells to state-0 cells and all adjacent state-0 cells to state-1 cells, and never changes any other cells.)

Code: Select all

#C A test pattern; settles into a p14198 oscillator
x = 16, y = 20, rule = B36/S23Investigator
15CP$E3.8B3.P$E14.P$E10.F3.P$E14.P$E14.P$E14.P$E14.P$E3.H10.P$E14.P$E
14.P$E2.G11.P$E8.I5.P$E14.P$E9.N4.P$E14.P$E2.C11.P$E14.P$E14.P$4E12O!

Code: Select all

#C A test pattern; settles into a p24 oscillator
x = 41, y = 29, rule = B3/S234cInvestigator
19.6E$16.3E6.6E$14.2E15.2E$13.E18.2E$11.2E20.2E$10.E2.8C13.E$8.2E3.8B
13.E$5.4E5.2A4.A14.E$4.E13.A11.F4.E$2.2E32.E$.E34.E$.E21.A12.E$E21.A.
A11.E$E20.A.H.A11.E$E4.G32.E$E16.2A3.3A14.E$E16.3A19.E$E16.AI2A19.E$.
E15.4A7.3A9.E$.E26.ANA9.E$.E26.3A9.E$2.E36.2E$2.E36.E$3.11E24.E$14.3E
19.2E$17.2E17.E$18.2E14.2E$20.2E8.4E$21.9E!

(edited to update rulestrings)

[rowett]

This seems to crash consistently at T 774:

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

What is it that causes this to become asymmetric anyway, whereas the range-1 algorithm doesn't?

It now doesn't crash consistently at T 774.

Note the minimum DELETERANGE for HROT rules is 3 and is now silently enforced.

[rowett]

In Help > Info > Pattern, if the RLE specifies the dimensions of a pattern to be 0, said values are converted to 1, even though the RLE did not specify 1. Is this intended behaviour?

Yes.

[rowett]

Identify on bounded grids now returns the bounding box of the oscillator rather than the size of the bounded grid like it did before.

Fixed, thanks.

Help > Info > Identify also displays a value for "Back" even if no background cells are present in the period map.

Fixed, thanks.

I've also noticed that downloaded period maps don't use the expected colors, resulting in minor artifacts. If you use the in-viewer button to download the period map for this after identifying it, then open up the file in mspaint and use the fill option to fill in some regions, you'll probably encounter a few pixels of slightly differing colors that didn't get filled in. What exactly is causing this, and is it fixable?

No idea, can't reproduce it. Perhaps desktop scaling on your machine?

Finally, an inconsistency: most bounded grid types do not accept negative zero as a size, even though they accept normal zero. Toruses accept it just fine.

Negative zero is not valid as a dimension. It's being "accepted" because it looks like a shift of zero (for the types that support one).

[rowett]

I don't think these cells should become state 2 when border killed?

Nor do I, fixed.

[rowett]

For long period tables, it's possible to scroll far enough that the lowest period (in this case, 1) is at the top of the list. This is a bit inconsistent with the top, since you can't scroll up to a state where the highest period is at the bottom with empty space above it. Scrolling should probably be capped such that the lowest period cannot move any higher than the lowest entry on the list.

I prefer the current behaviour.

[rowett]

For some reason, autofit + historyfit zooms incredibly far out on this pattern:

Fixed, thanks.

At T=255, despite there being nine deaths, only seven "died in this generation" cells are visible instead of nine. This only affects the triangular grid - enabling Use Rectangles will show all nine dead cells as expected.

Fixed, thanks.

"New pattern" and "Invalid pattern!" are capitalized consistently with each other

Fixed, thanks.

Finally, can support for Niemiec states be reimplemented?

No, not for [R]Super. I don't want to encourage legacy formats.

[rowett]

Using Identify on something with a loop command that dies out will cause "Identifying..." to persist instead of there being a "Life ended at" message.

Fixed, thanks.

Clicking on Show in Viewer on this pattern seems to cause everything to crash

Fixed, thanks.

Identify no longer seems to be able to detect spaceships in higher-range multistate rules at all.

Fixed, thanks.

For some cell colors that don't apply to a given rulespace, customising these via RGB will have the green and blue channels incorrectly misinterpreted as invalid commands instead of as part of the specified colors.

Fixed, thanks.

If we identify this oscillator without explicitly closing the error, then go to the periods table or period map, then press Settings twice, some elements of the Identify UI will be hidden, but not all of them will.

Fixed, thanks.

I should also mention that the script error page, despite overriding most of Identify, does not do the same for Graph.

Yes, this is intended.

Could Identify's period limit be increased for sufficiently small patterns?

No.

The way this zooms out does not appear to be completely smooth, especially at the end where it suddenly changes to fit the pattern

Looks good to me.

Finally, the "true cell state" number at the bottom left is back again. Can this please be kept as a toggle in Advanced Settings somewhere instead of removed entirely?

Yes, Settings->Advanced->State Number will now toggle this.

[rowett]

I am not sure why, but Identify appears to take far, far longer for [R]History patterns than [R]Standard or [R]Super:

Code: Select all

x = 156, y = 75, rule = B3/S23History
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!

Identify performance with [R]History patterns is now significantly improved.

[muzik]

From my testing, period maps in [R]Extended appear to work just about perfectly, with the important exception of the [R]Extended cells themselves, as they either render as background cells, p1 cells or p2 cells when they shouldn't.

I need to better understand which StateInvestigator states are on and off. From looking at Rule:StateInvestigator it doesn't appear to define whether state 14 is on or off. Also states 17 to 20 are problematic since whether they are on or off depends on whether we're calculating births or deaths. So if I see a state 17 cell in a pattern do I add it to the population as a live cell?

As a side note it would have been better if the odd numbered states were ON and even OFF as for [R]History and [R]Super.

Seconding confocaloid's opinion on this topic - states 2 and up aren't "alive" in the same sense that state 1 is alive, as they function fundamentally differently from state 1 even if they behave identically under certain specific contexts. I think that a value for "number of state 1 cells" is considerably more valuable to have than "number of cells that a state 0 or 1 cell would consider to be alive when deciding what it should do for the next generation".

This question might get a bit more blurry if [R]Func support (suggested here) got implemented, but that's something we can deal with if we come to it.

[muzik]

For long period tables, it's possible to scroll far enough that the lowest period (in this case, 1) is at the top of the list. This is a bit inconsistent with the top, since you can't scroll up to a state where the highest period is at the bottom with empty space above it. Scrolling should probably be capped such that the lowest period cannot move any higher than the lowest entry on the list.

I prefer the current behaviour.

For comparison, Help pages exhibit the "other" behaviour: manually scrolling down will only allow the very bottom line of the given Help page to remain at the bottom of the viewer - you can't scroll to a point where the bottom line is at the top like is the case in the periods list.

It's actually possible to surpass this with "jump to section" buttons, however: going to Help > Scripts and pressing the button for the Randomize section will put the viewer in a state where it's possible to scroll back up, but impossible to scroll back down to the position the button puts you. This might be intended, but I'm not sure since it's been the case for a long while.

[muzik]

If an oscillator contains exactly thirteen, fourteen or fifteen distinct periods, it is impossible to scroll in the periods table to view the lowest values.

Code: Select all

x = 55, y = 71, rule = B3/S23
38b2o11b2o$38b2o11b2o$37bo2bo9bo2bo$38bobo9bobo2$37b3o11b3o$37bo2bo9bo
2bo$36bo2bo11bo2bo$37b2o13b2o$26b3o$25bo3bo7b2o13b2o$25bo3bo6bo2bo11bo
2bo$26b3o8bo2bo9bo2bo$37b3o11b3o2$38bobo9bobo$37bo2bo9bo2bo$26b3o9b2o
11b2o$25bo3bo8b2o11b2o$25bo3bo$26b3o3$28bo$29bo$27b3o$39b2o6b2o$38bo2b
o4bo2bo$38bo2bo4bo2bo$38bo2bo4bo2bo$39b2o6b2o4$12b3o3$2o23b2o6bo6b3o$
2obo19bob2o6bo$4bo8bo8bo9bobo8b2ob2o$bo11bo11bo7bo8bobob2o$2bob2o7bo7b
2obo8bo7bo$4b2o7bo7b2o10bo7bo4bo$12b3o18bo7bo4bo$11bobobo16bobo6b2o2bo
$11bobobo17bo7b2o$12b3o18bo$13bo10b2o$22bobo$21bo5bo$22bo3b2o15b3o$35b
o7bob3o2bobo$24bobo7bo4b5obo2bob4o$25bo9b4obo2bob5o4bo$36bobo2b3obo7bo
$43b3o$18bob2o6b2obo$19bob2o4b2obo$19bo3b4o3bo$21b2ob2ob2o$23b4o$20bo
8bo$20bobo4bobo2$20bobo4bobo$20bo8bo$23b4o$21b2ob2ob2o$19bo3b4o3bo$19b
ob2o4b2obo$18bob2o6b2obo!

Code: Select all

x = 3, y = 26, rule = M0,8,4,3,2,5,9,7,1,6,10,11,12,13,14,15
b2o2$b2o2$b2o2$b2o2$b2o2$b2o2$b2o$b2o2$b2o2$b2o2$b2o2$b2o2$b2o2$b2o!

This pattern seems incredibly laggy when we open it. Perhaps this is due to Fast Lookup being on, even though the pattern is invalid?

Code: Select all

x = 10, y = 10, rule = MarBlocks7-OT-2x2-minimal:T10000,10000
5bo2$19bo$2bo$bo6b6o$7b8o$6b10o$o4b11o$5b2ob5ob2o$5b11o$5b2ob8o$5b2ob
o3b3o$6b3obob2o6bo$7b6o$o18bo$bo$17bo$3bo9b2o$5bo4b4o!
[[ SHOWTIMING EXTENDEDTIMING ]]

In this pattern, some historical dead cells are replaced with cells of the was-never-on type:

Code: Select all

x = 3, y = 3, rule = B03-ck4y6a/S2-n35r
o$obo$2o!
[[ PASTEMODE AND PASTEDELTA -1 1 PASTET EVERY 4 1 PASTE b! 3 0 PASTET EVERY 4 3 PASTE b! 1 -1 ]]

It does not appear to be possible to use Settings > Pattern > Change Rule to change this following pattern to the same rule "bzero" with a valid bounded grid (e.g. "bzero:T20") - it just stays with an error about some invalid rule name. The SHOWGENSTATS command does not appear to be respected either.

Code: Select all

x = 2, y = 2, rule = bzero
2o$2o!
#C [[ GRID MAXGRIDSIZE 9 SHOWGENSTATS ]]
@RULE bzero
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,0,1
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,1,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,0,1,1,1,1,1
0,0,0,0,1,1,1,1,1,1
0,0,0,1,1,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
0,1,1,1,1,1,1,1,1,1

[muzik]

This seems to crash consistently at T 774:

It now doesn't crash consistently at T 774.

Note the minimum DELETERANGE for HROT rules is 3 and is now silently enforced.

This one, however, freezes at T 321 (and loses symmetry just before that point, which it ideally should not as the input pattern is D8_4 symmetric with respect to the entire grid):

Code: Select all

x = 4, y = 4, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

Here's the same pattern in the range-1 algorithm. It remains symmetric, and you can even use Identify on it which recognises it as an oscillator (which was also the case for the general-range pattern until a build or two ago).

Code: Select all

x = 4, y = 4, rule = B1357/S02468
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

And as a rule table, symmetry is still lost and we can't identify it, but at least there's no crash:

Code: Select all

x = 4, y = 4, rule = rlrep
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]
@RULE rlrep
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,1,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
1,1,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,1,0,0

Even if we set DELETERANGE to 3 for the latter two, no crash happens:

Code: Select all

x = 4, y = 4, rule = B1357/S02468
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 3 ZOOM -1 ]]

Code: Select all

x = 4, y = 4, rule = rlrep
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 3 ZOOM -1 ]]
@RULE rlrep
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,1,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
1,1,0,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,1,0,0

[rowett]

Note: From build 1046 (hard refresh your browser to ensure you have it) the [R]Extended name has been replaced with [R]Investigator. You'll need to update any patterns you've posted accordingly.

[muzik]

And since StateInvestigator is an alias for LifeExtended, it might be a good idea to have it (as well as any others that apply) listed in Help > Aliases.

I believe it's just StateInvestigator but if I've missed other potential aliases please let me know. It's not actually handled as an alias for some exciting technical reasons so won't appear in the alias list.

Almost forgot about this one: "LeapInvestigator" should be converted to B2n3/S23-qInvestigator.

Example post: viewtopic.php?f=11&t=4267&p=119459#p119459

[PHPBB12345]

Almost forgot about this one: "LeapInvestigator" should be converted to B2n3/S23-qInvestigator.

Example post: viewtopic.php?f=11&t=4267&p=119459#p119459

EightInvestigator: viewtopic.php?f=11&t=1272&p=133727#p133727
PedestrianInvestigator: viewtopic.php?f=11&t=1661&p=134240#p134240
MerryInvestigator: viewtopic.php?f=11&t=5823&p=151738#p151738

[rowett]

Almost forgot about this one: "LeapInvestigator" should be converted to B2n3/S23-qInvestigator.

Example post: viewtopic.php?f=11&t=4267&p=119459#p119459

EightInvestigator: viewtopic.php?f=11&t=1272&p=133727#p133727
PedestrianInvestigator: viewtopic.php?f=11&t=1661&p=134240#p134240
MerryInvestigator: viewtopic.php?f=11&t=5823&p=151738#p151738

Fixed, thanks!

[rowett]

This one, however, freezes at T 321 (and loses symmetry just before that point, which it ideally should not as the input pattern is D8_4 symmetric with respect to the entire grid)

Fixed, thanks. Also DELETERANGE 1 is available again for all rule families.

[PHPBB12345]

Reversible secondorder rule

Please give some examples or links to a specification.

https://en.wikipedia.org/wiki/Second-or ... _automaton

Code: Select all

var n_states = 4;
function updatefunc (sw, s, se, w, c, e, nw, n, ne) {
	return ((c & 1) << 1) | (((c >> 1) & 1) ^ lookuptable[
		((sw & 1) << 8) |
		((s & 1) << 7) |
		((se & 1) << 6) |
		((w & 1) << 5) |
		((c & 1) << 4) |
		((e & 1) << 3) |
		((nw & 1) << 2) |
		((n & 1) << 1) |
		(ne & 1)]);
}

[muzik]

This one, however, freezes at T 321 (and loses symmetry just before that point, which it ideally should not as the input pattern is D8_4 symmetric with respect to the entire grid)

Fixed, thanks. Also DELETERANGE 1 is available again for all rule families.

Crash fix confirmed but something related to boundary deletion now seems to be interfering with patterns before they even get close to it. Compare:

Code: Select all

x = 4, y = 4, rule = B1357/S02468
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 ZOOM -1 STOP 127 ]]

Code: Select all

x = 4, y = 4, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 ZOOM -1 STOP 127 ]]

Also, is DELETERANGE "how close a pattern can get to the edge of the grid before cells start getting deleted" or "how close a cell can be to another cell deleted by the border such that it gets deleted as a larger connected pattern"? Are both customizable?

[muzik]

Some performance tests:

Code: Select all

x = 73, y = 3, rule = B3i/S5i
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = B3i/S5iHistory
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = B3i/S5iSuper
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = B3i/S5iInvestigator
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = marg2-RuleLoader
$b72o$b72o!
@RULE marg2-RuleLoader
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,1,1,1,1
1,0,0,0,0,0,1,1,1,0
1,0,0,0,0,1,1,1,1,0
1,1,1,1,1,1,1,1,1,0

Code: Select all

x = 73, y = 3, rule = M0,0,0,15,0,15,0,0,0,0,15,0,15,0,0,0
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = R1,C2,S5,B3
$b72o$b72o!

Go To Gen 174762b:
- [R]Standard: 1.5s
- [R]History: 1.8s
- [R]Super: 4.9s
- [R]Investigator: 43.1s
- Ruletable: 11.7s
- Margolus: 2.0s
- General range: 6.0s

Identify:
- [R]Standard: 8.7s / 11.0s
- [R]History: 9.2s / 11.5s
- [R]Super: 19.2s / 25.0s
- [R]Investigator: 93.3s / 139.6s
- Ruletable: 39.7s / 54.0s
- Margolus: 9.4s / 12.3s
- General range: 22.2s / 29.1s

Since oscillators like these have a mod half of their period a part of me wonders if an Identify optimization could involve checking when the initial phase reoccurs with a rotation/mirror transformation and detecting periodicity based on that, although this would only apply to isotropic rules. This definitely seems like something that has already been thought of.

[rowett]

Some performance tests

Build 1051 has a minor performance improvement for [R]Investigator.

My results are similar to yours with two exceptions: your [R]Investigator and RuleTable results are much slower. Are you using iOS?

Windows 11, AMD3950X, 64Gb RAM, Chrome 116.

Go To Gen: 174762b:

• [R]Standard: 2.1s (1x)
• [R]History: 2.1s (1x)
• [R]Super: 7.9s (3.8x)
  
• [R]Investigator: 11.6s (5.5x)
• RuleTable: 4.8s (2.3x)
• Margolus: 2.0s (1x)
• General range: 9.7s (4.6x)

[rowett]

... something related to boundary deletion now seems to be interfering with patterns before they even get close to it.

Fixed, thanks.

Also, is DELETERANGE "how close a pattern can get to the edge of the grid before cells start getting deleted" or "how close a cell can be to another cell deleted by the border such that it gets deleted as a larger connected pattern"? Are both customizable?

The second one. The first one is specific to each algorithm.

[unname4798]

Some performance tests

Build 1051 has a minor performance improvement for [R]Investigator.

My results are similar to yours with two exceptions: your [R]Investigator and RuleTable results are much slower. Are you using iOS?

Windows 11, AMD3950X, 64Gb RAM, Chrome 116.

Go To Gen: 174762b:

• [R]Standard: 2.1s
• [R]History: 2.1s
• [R]Super: 7.9s
  
• [R]Investigator: 11.6s
• RuleTable: 4.8s
• Margolus: 2.0s
• General range: 9.7s

Results on my tablet (Lenovo, Android 10, RS Browser):
Go to Gen 65536b:

• Standard - 6.2s
• History - 6.2s (1x)
• Super - 21.5s (3.46x)
• Investigator - 35.1s (5.67x)
• RuleTable - 15.6s (2.52x)
• Margolus - 6.5s (1.05x)
• HROT - 33.5s (5.4x)
In this case, Investigator and HROT are much slower.

[rowett]

If an oscillator contains exactly thirteen, fourteen or fifteen distinct periods, it is impossible to scroll in the periods table to view the lowest values.

On my machine it doesn't need to scroll.

screenshot.png (149.45 KiB) Viewed 3439 times

This pattern seems incredibly laggy when we open it.

Fixied, thanks.

In this pattern, some historical dead cells are replaced with cells of the was-never-on type

Fixed, thanks.

It does not appear to be possible to use Settings > Pattern > Change Rule to change this following pattern to the same rule "bzero" with a valid bounded grid (e.g. "bzero:T20") - it just stays with an error about some invalid rule name.

It's because a valid pattern was never loaded. I'll probably grey out Change Rule in this case.