Pattern viewer for forum threads

[muzik]

I've recently been exploring self-inverse 2-state rules on bounded grids. In these rules, as is widely known, the roles of dead cells and alive cells are functionally equal, and patterns do not behave any differently under black-white reversal. That is, making a distinction between "stator cells" and "background cells" is effectively irrelevant in this context since they're both period-1 cells in a bounded universe integral to the function of the pattern.

Could an option of some sort be implemented that, when switched on, treats all "background" cells as "stator" cells? This would mean that they'd be counted as stator cells when calculating volatility, and would be displayed as gray on period maps instead of black.

Here's some example patterns:

Code: Select all

x = 28, y = 28, rule = B34e678/S34-c678:C28
13obo$14o$5o3b6o6b3o$6o2b5obo5b2o$13obo$2ob11o11bo$2o2b10o10b2o$2o2b7o
2bob2o7b2o$12o2b2o$13obo$13obo$7ob3obobobo3bo$7o2b3obobo3b2o$b2o2b3o4b
obob4o3b2o2bo$o2b2o3b4obobo4b3o2b2o$7b2o3bobob3o2b7o$7bo3bobobob3ob7o
$13bob13o$13bob13o$12b2o2b12o$2b2o7b2obo2b7o2b2o$2b2o10b10o2b2o$2bo11b
11ob2o$13bob13o$6b2o5bob5o2b6o$5b3o6b6o3b5o$14b14o$13bob13o!

Code: Select all

x = 28, y = 28, rule = B34e678/S34-c678:C28
b13o13bo$14o$14o$14o$13obo$13obo$14o$13obo$13obo$14o$12obobo$11o3b3o$
6o3bo3bob3ob3o$4ob6obobobo6bo$4bo6bobobob6ob4o$6b3ob3obo3bo3b6o$11b3o
3b11o$12bobob12o$14b14o$13bob13o$13bob13o$14b14o$13bob13o$13bob13o$14b
14o$14b14o$14b14o$o13b13o!

Code: Select all

x = 16, y = 16, rule = B13j567/S045-j68:T16
2b2o2b2o2b2o2b2o$4b4o4b4o$o3b3obo3b3o$o3b3obo3b3o$b3o3bob3o3bo$b3o3bo
b3o3bo$4o4b4o$2o2b2o2b2o2b2o$2b2o2b2o2b2o2b2o$4b4o4b4o$o3b3obo3b3o$o3b
3obo3b3o$b3o3bob3o3bo$b3o3bob3o3bo$4o4b4o$2o2b2o2b2o2b2o!

----

If we take this pattern and paste it into viewer.html, load it, use Identify, and then click "View" a second time while it's in the process of identifying, the viewer will enter a glitched state where it doesn't seem to be possible to interact with it. It'll look like a newly loaded pattern with the main difference being that the "Cancel" button remains.

Code: Select all

x = 1, y = 4, rule = M0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15:T512,510
o3$o!

----

The bounding box calculated for this oscillator is slightly too big. This can be seen in the period map, where there is a two cell thick gap of background cells at the top and left instead of the expected one layer thick more commonly seen.

Code: Select all

#CXRLE Pos=-238,-238
x = 4, y = 4, rule = B2a3i/S
2b2o2$o$o!
[[ MAXGRIDSIZE 9 ZOOM 8 ]]

I assume this is due to cells being born and then immediately dying in the same generation. However, the following pattern also has cells which are immediately born into the dead state at the side of its hitboxes, and yet the calculated bounding box and generated period map for this one are the correct size.

Code: Select all

x = 36, y = 29, rule = B3/S23
24bo$22bobo$12b2o6b2o12b2o$11bo3bo4b2o12b2o$2o8bo5bo3b2o$2o8bo3bob2o4b
obo$10bo5bo7bo$11bo3bo$12b2o19$21b2o$21b2o!
[[ KILLGLIDERS ]]

[muzik]

There appear to still be some remaining issues with selections not being able to be created in unloaded tiles if the input pattern is empty:

Code: Select all

x = 1, y = 1, rule = W0
!
[[ MAXGRIDSIZE 9 ZOOM 1 ]]

Also, following up on the previously-reported, ultra-low-priority selection visuals thing: the selection box can visually bleed into adjacent cells slightly when using a square grid, in contrast to it not covering up the other cell types enough.

Code: Select all

x = 10, y = 10, rule = B/S0:P10
o9$9bo!
[[ COLOR UIBACKGROUND Red ]]

Also, if we then press the play button, the box that displays the current selection size stays visible, even though the coordinate display box which is usually to its left becomes invisible during playback. Is this intended?

This is hard to reproduce if your viewer window doesn't resize automatically when scrolling like it does on my end, but if you change the rule from within the viewer to a repository rule table, and then scroll while it's looking for that rule such that the popup window size changes, once it finally loads and sets the rule, the UI buttons can sometimes shrink. The same can be done with an invalid rule name in place of a repository ruletable.

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ SHOWGENSTATS COLOR BACKGROUND White ]]

If you reproduce this with an invalid rule name, there's further issues that can be seen: the "cell coordinates and state under cursor" box does not show up at the bottom left at all, and the space where the rule name would be is a blank rectangle. Mousing over this blank rectangle gets us an empty space where the rule name would be, and it tells us it uses the Moore neighbourhood (a "none" would be expected here instead).

----

If AUTOFIT is active, cells are manually drawn at the edges of the window, and the pattern is not currently playing, the zoom level will not be updated to account for these new cells unless you manually exit AUTOFIT mode and reenter it.

Code: Select all

x = 9, y = 1, rule = W0
o7bo!
[[ AUTOFIT ]]

If we click on the Settings button in the following pattern, close inspection reveals that the "close viewer" and "close script error" buttons are in the exact same position simultaneously. This seems incorrect. Interaction reveals that the former takes priority.

Code: Select all

x = 1, y = 1, rule = W0
o!
[[ THEME Inverse H ]]

Could the upper limit for GRIDMAJOR intervals be increased? 16 seems a bit low.

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ ZOOM 16 GRID COLOR GRIDMAJOR Yellow GRIDMAJOR 16 ]]

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ ZOOM 16 GRID COLOR GRIDMAJOR Yellow GRIDMAJOR 17 ]]

----

Finally for this post, I've been running into some annoying issues when modifying patterns on bounded grids. For the following pattern, select and cut the two leftmost columns on the bounded grid. Then Select All and nudge everything that remains to the left by two cells. If we then try and paste the two columns we cut earlier, the paste preview reveals that something completely different is in the clipboard instead.

Code: Select all

x = 16, y = 16, rule = B13j567/S045-j68:T16
2b2o2b2o2b2o2b2o$4b4o4b4o$o3b3obo3b3o$o3b3obo3b3o$b3o3bob3o3bo$b3o3bo
b3o3bo$4o4b4o$2o2b2o2b2o2b2o$2b2o2b2o2b2o2b2o$4b4o4b4o$o3b3obo3b3o$o3b
3obo3b3o$b3o3bob3o3bo$b3o3bob3o3bo$4o4b4o$2o2b2o2b2o2b2o!

Also, if we attempt to paste a pattern outside of a bounded grid, all of the constituent cells that ended up outside of it will instead be pasted at the very edge within the bounded grid. This is inconsistent with Golly and this behaviour is far more annoying than useful, and does not seem intentional.

Code: Select all

x = 3, y = 3, rule = B3/S23:T7,7
o$obo$2o!

[rowett]

If we take this pattern and paste it into viewer.html, load it, use Identify, and then click "View" a second time while it's in the process of identifying, the viewer will enter a glitched state

Fixed, thanks.

The bounding box calculated for this oscillator is slightly too big.

It's because cells are killed at the grid boundary.

[rowett]

There appear to still be some remaining issues with selections not being able to be created in unloaded tiles if the input pattern is empty

Fixed, thanks.

the selection box can visually bleed into adjacent cells slightly when using a square grid

Fixed, thanks.

Also, if we then press the play button, the box that displays the current selection size stays visible, even though the coordinate display box which is usually to its left becomes invisible during playback. Is this intended?

Yes.

If AUTOFIT is active, cells are manually drawn at the edges of the window, and the pattern is not currently playing, the zoom level will not be updated to account for these new cells unless you manually exit AUTOFIT mode and reenter it.

Fixed, thanks.

If we click on the Settings button in the following pattern, close inspection reveals that the "close viewer" and "close script error" buttons are in the exact same position simultaneously.

Fixed, thanks.

Could the upper limit for GRIDMAJOR intervals be increased? 16 seems a bit low.

What do you suggest?

For the following pattern, select and cut the two leftmost columns on the bounded grid. Then Select All and nudge everything that remains to the left by two cells. If we then try and paste the two columns we cut earlier, the paste preview reveals that something completely different is in the clipboard instead.

Fixed, thanks.

if we attempt to paste a pattern outside of a bounded grid, all of the constituent cells that ended up outside of it will instead be pasted at the very edge within the bounded grid

Fixed, thanks.

[muzik]

If AUTOFIT is active, cells are manually drawn at the edges of the window, and the pattern is not currently playing, the zoom level will not be updated to account for these new cells unless you manually exit AUTOFIT mode and reenter it.

Fixed, thanks.

Confirmed fixed, but if you press the Undo button after making such changes it still stays zoomed out. I'd expect it to zoom back in again if the bounding box size decreases.

Could the upper limit for GRIDMAJOR intervals be increased? 16 seems a bit low.

What do you suggest?

Assuming "arbitrarily high" isn't an option I'd be fine with 30 (2*3*5).

[muzik]

Golly accepts the following pattern as valid, but LifeViewer does not.

Code: Select all

x = 3, y = 3, rule = B3/S23:K6,5*+1
o$obo$2o!

Should "COLOR BOUNDED" be removed from Help > Scripts > Colours if the current rule does not use a bounded grid? I believe this would be more consistent with other rulespaces if it were removed.

I'd expect the three following patterns to behave identically, with the only difference being that they're n cells thick (which is irrelevant since the input pattern is one-dimensional). However, the first pattern dies out instead. It should not.

Code: Select all

x = 3, y = 1, rule = R2,C2,S,B5:T1,20
3o!

Code: Select all

x = 3, y = 1, rule = R2,C2,S,B5:T2,20
3o!

Code: Select all

x = 3, y = 1, rule = R2,C2,S,B5:T3,20
3o!

For the following pattern, if we Select All and try to rotate it, we get the message "Rotation does not fit in bounded grid". However, if we nudge it one cell upwards, it becomes possible to rotate it. This is despite the fact that in both cases, the line is five cells away from one edge and four away from the other.

Code: Select all

x = 10, y = 1, rule = R5,C2,S2-3,B3:T10
10o!

The "phantom cell" issue I demonstrated a few days ago using PASTET 0 can also be triggered using CXRLE Pos.

Code: Select all

#CXRLE Pos=-240,-240
x = 4, y = 4, rule = B2a3i/S
2b2b2$o$o!
[[ MAXGRIDSIZE 9 ]]

If we create a rectangle-shaped selection in the middle of this bounded grid and then rotate it, a bunch of dead cells appear as a result. This behaviour is probably to be expected, but it's caused a bit of irritation when experimenting with self-inverse rules on bounded grids.

Code: Select all

x = 20, y = 20, rule = B/S012345678:P20
20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o
$20o$20o!

On the topic of bounded grids: could background cells be included in the periods table and period map legend if the pattern being identified is a bounded grid? Having a count of how many never-alive cells there are in an oscillator is a much more useful statistic for bounded grids, since a given pattern isn't living in an infinite ocean of them like is the case for "unbounded" grids.

For a simple example using a self-inverse rule, this period-626 agar would list in the table that there are a total of 380 cells, colored in black, inside of the bounded grid which never turn on at any point.

Code: Select all

x = 42, y = 42, rule = B2c3-i4ew678/S34-cq5i6-c78:C42
21o$o20b20o$o17bo2b2ob17o$o17b2obo2b17o$o17bo2b2ob17o$o17b2obo2b17o$o
18bobob18o$o18b2o2b18o$o18b2o2b18o$o18bobob18o$o18b2o2b18o$o18bobob18o
$o18b2o2b18o$o18bobob18o$o17b2obo2b17o$o14b5obo5b14o$o14b3obobobo3b14o
$o14b4o2b2o4b14o$ob4o8b2ob3obo3bo2b8o4bo$o2bob12ob2obo2bo12bob2o$o6b2o
bobo8b8obobo2b6o$b6o2bobob8o8bobob2o6bo$b2obo12bo2bob2ob12obo2bo$bo4b
8o2bo3bob3ob2o8b4obo$b14o4b2o2b4o14bo$b14o3bobobob3o14bo$b14o5bob5o14b
o$b17o2bob2o17bo$b18obobo18bo$b18o2b2o18bo$b18obobo18bo$b18o2b2o18bo$
b18obobo18bo$b18o2b2o18bo$b18o2b2o18bo$b18obobo18bo$b17o2bob2o17bo$b17o
b2o2bo17bo$b17o2bob2o17bo$b17ob2o2bo17bo$b20o20bo$21b21o!

[rowett]

Golly accepts the following pattern as valid, but LifeViewer does not.

LifeViewer is correct. The Golly documentation says: "A Klein bottle can only have a shift on the twisted edges and only if that dimension has an even number of cells.".

Golly is just silently ignoring the shift. I prefer LifeViewer's behaviour: it's good to know the rule is not valid.

For the following pattern, if we Select All and try to rotate it, we get the message "Rotation does not fit in bounded grid". However, if we nudge it one cell upwards, it becomes possible to rotate it. This is despite the fact that in both cases, the line is five cells away from one edge and four away from the other.

LifeViewer is correct and Golly concurs. You need to check the center of rotation to see why.

[rowett]

I'd expect the three following patterns to behave identically, with the only difference being that they're n cells thick (which is irrelevant since the input pattern is one-dimensional). However, the first pattern dies out instead. It should not.

Actually all three patterns are invalid. The minimum bounded grid size for HROT/LtL patterns is twice the range. LifeViewer wasn't checking this.

The "phantom cell" issue I demonstrated a few days ago using PASTET 0 can also be triggered using CXRLE Pos.

Fixed, thanks. I've improved checking for patterns with a position specified. In this case the pattern is too close to the border.

[rowett]

if you press the Undo button after making such changes it still stays zoomed out

Fixed, thanks.

Could the upper limit for GRIDMAJOR intervals be increased? 16 seems a bit low.

Upper limit is now 32.

[rowett]

You can now scroll the legend with arrow buttons or Page Up and Page Down. The Home key will go to the top and End will go to the bottom.

Can it be made scrollable via click/tap and drag like the Help pages are?

Yes, done.

[muzik]

You can now scroll the legend with arrow buttons or Page Up and Page Down. The Home key will go to the top and End will go to the bottom.

Can it be made scrollable via click/tap and drag like the Help pages are?

Yes, done.

Also, could the "scroll one unit down/up" buttons be repurposed to "jump to top/bottom"? Buttons for just moving one unit in a direction don't seem particularly useful for me if we can now scroll "normally".

Could scrolling be added for the period map key if it's also too long?

[muzik]

I'd expect the three following patterns to behave identically, with the only difference being that they're n cells thick (which is irrelevant since the input pattern is one-dimensional). However, the first pattern dies out instead. It should not.

Actually all three patterns are invalid. The minimum bounded grid size for HROT/LtL patterns is twice the range. LifeViewer wasn't checking this

For cases like these, Golly automatically resizes the bounded grids to fit the minimum allowable size for that given range. Should LifeViewer also do this for parity's sake, or is rejection preferable?

Another thing I should point out: earlier, the "canonical" notation for square Klein bottles was made to always include both dimensions, since the twist indicator depends on there being two numbers. I'd say that square tori with a shift should be handled in the same way: if one side is shifted, the pattern should always save both numbers. When using "Save Pattern", this happens for the first pattern, but not the second (it becomes "T20+5"). Non-shifted square tori can still collapse down to one number.

Code: Select all

x = 3, y = 3, rule = B3/S23:T20,20+5
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:T20+5,20
o$obo$2o!

[rowett]

Deathforcer cells do not appear to work in [R]History when at the edge of the grid.

True. It's how the algo works.

[rowett]

Also, could the "scroll one unit down/up" buttons be repurposed to "jump to top/bottom"?

No, but I've made them move multiple lines at a time.

Could scrolling be added for the period map key if it's also too long?

No.

[rowett]

For cases like these, Golly automatically resizes the bounded grids to fit the minimum allowable size for that given range. Should LifeViewer also do this for parity's sake, or is rejection preferable?

I prefer rejection, rather than having a tool silently change things. If you silently change it's allowing an incorrect pattern to propagate across different tools and you're assuming they all will make the same silent change.

Another thing I should point out: earlier, the "canonical" notation for square Klein bottles was made to always include both dimensions, since the twist indicator depends on there being two numbers.

I've changed it so the canonical form is both width and height for all Bounded Grid types except Sphere.

[rowett]

this pattern with a PASTE command doesn't paste the requested cells as expected

Fixed, thanks.

[muzik]

Deathforcer cells do not appear to work in [R]History when at the edge of the grid.

True. It's how the algo works.

There's another couple of things with state 6 at the edge that I've noticed. I assume these have much the same root cause?:

For the following, if we draw a state 6 cell inside of the pre-block such that all four cells fit in a 2x2 square, and then advance it by one generation, the gray cell uses the history trail overlay if layers are enabled.

Code: Select all

x = 2, y = 2, rule = B3/S23History
!
[[ SHOWGENSTATS MAXGRIDSIZE 9 GRID X -255 Y 5 PASTE 2o$bo! -256 0 LAYERS 10 ]]

And for the following two patterns, if we place a state 6 cell one cell to the left of the middle cell of the blinker and then advance one generation, the first doesn't die out immediately but the second does.

Code: Select all

x = 2, y = 2, rule = B3/S23History
!
[[ SHOWGENSTATS MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -254 0 ]]

Code: Select all

x = 2, y = 2, rule = B3/S23History
!
[[ SHOWGENSTATS MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -255 0 ]]

The birth statistics for these are weird as well, since it seems to count births that would be made into state 6 as proper births. In normal bounds, this no longer happens.

----

On the topic of the boundary, there's a few more oddities I'd like to point out. For example, for the following case, we can use Select All and then rotate the pattern 90 degrees. Doing this would result in one of the cells being placed in the boundary region that can't be drawn in, resulting in that cell being deleted. I don't think this behaviour is desirable - could a "Rotation does not fit" message be displayed instead and the rotation blocked, like what happens on bounded grids and the edges or non-bounded grids for other rulespaces?

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -253 0 ]]

For this rulespace, it might also be desirable to block selections from being made that extend into said "forbidden region": said selections will never be able to modify anything in a desirable way (random fill, inversion, flipping, etc.) and can cause unwanted deletion of cells. It should hit a "wall", again like bounded grids and the edges of non-bounded grids.

Another thing to point out with selection manipulation: for the first pattern, using Select All and then trying to nudge the contents of the selection to the left will give "No room to nudge selection", despite the fact that you can draw there just fine and rotate selections into it. For the second pattern, you can in fact nudge the selection to the left, but this results in all cells being deleted. I'd expect the opposite results for these two patterns: the first one should allow you to nudge that one cell more, and the second should forbid you from doing so.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -255 0 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -253 0 ]]

Also on the topic of selections, it's possible to start making a selection if your click begins in the gray "boundary" region, in which case it will be made at the farthest possible point in bounds. This is consistent with how selections are made in Golly outwith bounded grids, but it's inconsistent with how LifeViewer does it in bounded grids, and you've already said that changing LifeViewer's behaviour to Golly's in that situation is undesirable.

Some rulespaces still cause phantom cells with PASTE at high distances:

Code: Select all

x = 1, y = 1, rule = LifeSuper
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -253 0 ]]

And should changing the color of the boundary and/or the bounded grid edge create a custom THEME, or not? It does for [R]History states, which don't have theme-dependent colors, but still allows for changing back to a different theme to set the colors back to their defaults. I'd expect either these two "cells" to also result in a custom theme being specified, or for [R]History states to not create a custom theme since they aren't defined differently for each theme.

Code: Select all

x = 1, y = 1, rule = Life:P480
!
[[ SHOWGENSTATS MAXGRIDSIZE 9 GRID ZOOM 16 X -255 COLOR BOUNDED Yellow COLOR BOUNDARY Orange ]]

[muzik]

There appear to be issues with drawing in grids bounded in only one dimension. If we click in a region which has a negative coordinate in the direction the grid is unbounded (upwards for the first, and to the left for the second), nothing will be drawn. Only when we drag the cursor into the positives on that axis will things actually be drawn, and we can drag the cursor back to the negatives to draw there.

Code: Select all

x = 2, y = 2, rule = B3/S23:T10,0
2o$2o!

Code: Select all

x = 2, y = 2, rule = B3/S23:T0,10
2o$2o!

Here's some further reasons why I think that Identify should output the total number of "never becomes alive" cells in the periods table when identifying oscillators on a bounded grid: for patterns like the following, the proportion of "alive regions" to "dead regions" would be useful information.

Code: Select all

x = 40, y = 40, rule = B3678/S34678:T40,40
2o3bob2o5bob2o4bobo4b3o3b2ob2o$b3o3b2o2bo2b2ob2o3bobo4b2o2bo4b2o$2b2o
bo3b2o2b3ob4o3bob2o4b3o3b2o$3ob5obo5bob3ob2ob2ob2ob3o2bo$o3b2obo2b2o2b
2ob2o3b4obo2bo3b2obobo$ob2o3b2ob3obob3obo2bobo2bobo2bo2bo2bo$o2bobobo
bo2b2ob8o2b2obobo2b3ob3o$b4ob5obobobob2obo2b3o2b2o2bo2bo2bo$bobo3bob2o
b3obo3bob4ob5ob2ob3o$ob6o4b5o2b4o2bobo3b2ob2o$2bo2bob2ob7obob2obobob3o
3bo2bo$2bob3o3b2obobob3ob3obo2b3obob2ob2o$bo3b2ob3obob3o2b2ob2o3bo2b7o
b2o$2o6bob2o2bo2b5ob2obob4ob2ob4o$b2obob2obo5bob3ob2ob4o2b2o2bobo$bob
2obo2b4o3b5o3bo4bobo4b2obo$b2o11b3obo2bo2bobobo2bo4b2o$2bo2bobobobob3o
bobobo5bo4bob2ob3o$2b4obob2obo2b2obo2b2obo2bob2ob6obo$bo5bob5o2bobo2b
ob6ob2o2bo2b2o$b2o4bo2bobob3o2bo3b2ob2obob4ob2o$o2b2ob4o3bobo2b2ob2o2b
2o4bob2obob2o$4bobo2b2o3b3obo3bobo2bo4bo3bob2o$3bo3bob3obo2bobob3o2bo
2bobo5b2o$b2ob4o3b2o5b2o4b2o4b3o3b2obo$3o3bobobo4bo2b3o2bo3b3ob3obobo
bo$b2o2b2obobobo2b3obob4obo2b5o$ob5obob3ob2o4b3ob2o2b2obo2b4o$bob2o5b
o2b2o2b2obobobo4bobobo2bob2o$2o2bob2o4b2ob7obob6ob2o5bo$2ob7ob2obobo5b
ob2obo2bob5obo$bob2o2b6o3bobo5bo3b3obo6bo$2bo3bo3b2o3bobob2o3bob2obo6b
3o$2o3bo2b6obo2bobob3o2bo2bobo5b2o$ob2ob2o3bobobobobob3ob3o2b3obob3o$
b4ob2ob2ob3ob2o2bo2bobobo2b2ob2o4bo$3o2bobob2ob4o2b2o2bo3bo4bobob3o$3b
2o2bob3ob3o2b3obo5b2obob3ob3o$b2ob2ob3obo4bo4bobo2b2obo4bob3o$bob2o3b
obobobo2bobobo6b5o!

And for cases like the following, it'd output the total number of spaces which would never be visited by the glider.

Code: Select all

x = 3, y = 3, rule = B3/S23:T20,20+5
o$obo$2o!

Now that we can scroll through the table of periods, would it be possible to visually truncate it at the bottom so that it doesn't visually go under the playback buttons and such? All of the listed periods can be read by scrolling now, so having them render there no longer serves a use (and is unsightly).

Code: Select all

x = 155, y = 144, rule = B3/S23
96b2o48b2o$97bo48bo$84b2o11bobo44bobo$83bo2bo11b2o9b2o22b3o8b2o$84b3o
20b2o2bo19bo3b2o$83bo3bo19bo2b3o2b2o10b2o2bobo2b2o$82bob4o19bo4bo2b2o
10b2obo5bo$69b2o11bobob2o20b5o18b5o$70bo12bobobobo$70bobo12b2obobo17b
5o18b5o$71b2o3bo8b4obo16bo4bo2b2o10b2obo5bo$77b2o6bo3bo17bo2b3o2b2o10b
2o2bobo2b2o$77b2o7b3o18b2o2bo19bo3b2o$66b2o5bo3bo3bo4bo2bo8b2o9b2o22b
3o8b2o$71bobo3bo3b3o3b2o8bobo44bobo$65bo3bo6b2o3b3o13bo48bo$64bo4bo6b
2o4b3o11b2o48b2o$63bobobo5b3o4b2o$62bobobo7b3o3b2o$56b2o2bo4bo8b3o3bo
3bobo31b2o6b2o$56b2o2bo3bo11bo3bo3bo32bo2bo4bo2bo$70bo2bo5b2o36bo2bo4b
o2bo$52bo9b2o6bo8b2o36bo2bo4bo2bo$51bobo15bo4bo6bo3b2o31b2o6b2o$52bo
15bobo2b2o10bobo$56b3obo5b2obo17bo$55bob2ob2o25b3o7b2o15b2o16b2o$55bo
5b2o27bo6bo17bo16bo$55b2o5bo3bo2bo19b2o4bobo17bob2o10b2obo$56b2ob2obo
5b2o25b2o19bo3bo6bo3bo$57bob3o29b3o12b2o13bo4bo$65bo25b3o11bo2bo8bo3bo
4bo3bo$64bobo38bobobo11bo4bo$65bo3bo18b2o16bo2bo6bo3bo6bo3bo$68bobo16b
obo4b2o14bo4bob2o10b2obo$60b2o6bobo16bo6bo12bobo5bo16bo$60b2o4b3o2b2o
13b2o7b3o16b2o16b2o$65b2o2bobo8bo16bo16bo38b2o$64bobob2o2bo6bobo15bob
2o10b2obo21bobo2b2o6b3o2bo$62b3obo3b2o3bo13b2o7bo3bo6bo3bo21bo2bo2bobo
8b2o$54b2o5bo4bob2o5bo2bo2bo4b2o2bo12bo4bo10b2o15b2obo3bo4bo$54bobo4b
2o3b2obo4bob2o7b2ob2o9bo3bo4bo3bo6b2o19b2ob2o3bo$56bo2b2o17b2o5b2o16bo
4bo31b2o2bo7b2o$47b2o6b2obobo14b2o2bo5b2o11bo3bo6bo3bo12b5o5b3o3b3o4b
3o2bo$47b2o9bo16b2o3b2o3b2ob2o7bob2o10b2obo11bo9bo2b2o12b2o$54b5o2bo
15bo8b2o2bo6bo16bo12bo2bo5b2ob2o$55bo3b3o17b3o7b2o5b2o16b2o12b2o7bo3bo
b2o$54b2ob2o66b2o10bobo2bo2bo$53bo5bo64bo2bo10b2o2bobo$53b6o47b2o20bo$
98bo6bobo3b2o11b5o$55b2o22b3o16b2o4bo2bo3b2o$55b2o12bo12bo4b3o12bo3bo
27b2o$69b2o7bo3bo3bo3bo11bobo29b2o$47b3o27bobo2bo2bo5bo$46bo3bo14bobo
2b3o2bo2bobo21bobo$45bo5bo13b4obo4bo3bo4bo7bo9bo3bo$46bo3bo14b2o8bo8bo
7bo5b2o4bo2bo3b2o$36b3o8b3o26b3o19bo6bobo3b2o8b2o15b2o$18b2o5b2o9b3o8b
3o35bo5bo14b2o13b2o15b2o$18b2o5b2o9b3o47bo3bo$18b2o5b2o6b3o51b3o$18bo
7bo6b3o39b2o$16b2ob2o3b2ob2o4b3o11b2o25bo2bo56b2o$16b2ob2o3b2ob2o18b2o
25bobobo55bobo$16b2o2bo3bo2b2o46bob3o49b3o$7b2o8b2obo3bob2o49b3o15bo2b
2o4b2o2bo19bo3bo$7bo2b3o5b2o5b2o67bo3b3o2b3o3bo17b2o3b2o$8b2o9bo5bo9b
2o58bo2b2o4b2o2bo19bo$13bo20b4o36b2o53b5o$13bo19bo2bobo33bo4bo52bo$8b
2o22bobo2b2o32bo6bo22b2o$7bo2b3o5b2o5b2o4bobo36bo8bo3b3o$7b2o9b2o5b2o
3b2o38bo8bo5bo17bo5bo20bo$18b2o5b2o3b3o37bo8bo4bo18bo5bo3bo13b5o$18bo
7bo4bobo37bo6bo22b4o3b4o20bo$16b2ob2o3b2ob2o3b2o38bo4bo22b2o9b2o14b2o
3b2o$16b2ob2o3b2ob2o45b2o23b3o2b2ob2o2b3o14bo3bo$5bobo8b2o2bo3bo2b2o
70b2o3b2ob2o3b2o15b3o$4bo2bo9b2obo3bob2o42bo2bo26b3obo3bob3o11bobo$4b
2o2b2o8b2o5b2o47bo26b2o7b2o13b2o$4bo4bo9bo5bo7b2o34bo5bo26b3o3b3o$b3o
5bo22bo2bo33b2o4bo28b2ob2o$obo5bo22bobobo38bo28bobobobo$7bo23bo2bo38bo
21b2o7bo3bo12b2o15b2o$2o4bobo9b2o5b2o3bo41b4obo17b2o24b2o15b2o$2bo2bob
obo2b2o4b2o5b2o4bobo38bo3bo$2b3o3bo3b2o56bo3bo21bo$34b2o33bob4o20bobo$
32bo4bo35bo16b2o2bo2bo4b3o3b3o$8b2o21bo6bo33bo17b2obo8b2obobob2o$8b2o
20bo8bo3b3o25bo4b2o16b2o9bobo$30bo8bo5bo25bo5bo$30bo8bo4bo27bo31b2ob2o
$31bo6bo34bo2bo6bo4bo$32bo4bo43b3o3bob2o$34b2o44bo6bobo5b2o$80b2o6bobo
3bobo$93b3o$74bob2o15b2o$73bo2bob2o14bobo$73bo2bo3bo14bobo2b2o$73b3o
20bo2bobo$68bo11bo16b4o$67bo11bo18b2o$72b3o$67bo3bo2bo$68b2obo2bo$70b
2obo$49bo$49b3o14b2o$52bo14bo$51b2o11b3o$64bo$62bobo$62b2o7$58bobo$57b
o2bo$57bo2bo$58bo2$53bo$51bo2bo$51bo2bo$51bobo7$48b2o$47bobo$47bo$46b
2o11b2o$59bo$60b3o$62bo!
[[ THEME Mono ]]

In Identify, still lifes in hexagonal or triangular rules don't display a value for "Density", even though they do for "Bonding Box". Why is this? I'd expect that either both of them would be displayed, or neither would be. (As I've said before, the latter makes more sense since we don't yet have an agreed upon definition of what a bounding shape on these grids should be. Compare the following three patterns - they showcase the same three life in three orientations, but the values the bounded grid reports back with differ - one is 5x9, another is 5x5 and another is 9x5. The numbers should be able to change position just fine, but their numerical values should always remain the same.)

Code: Select all

x = 5, y = 9, rule = B/S0123HT
o$2o$3o$4o$5o$b4o$2b3o$3b2o$4bo!
[[ GRID ]]

Code: Select all

x = 5, y = 5, rule = B/S0123HT
5o$5o$5o$5o$5o!
[[ GRID ]]

Code: Select all

x = 9, y = 5, rule = B/S0123HT
5o$b5o$2b5o$3b5o$4b5o!
[[ GRID ]]

Would it be possible for the viewer to pause and display a message if all of the cells inside of a bounded grid become permanently alive? Such a message is already displayed if all cells become dead. The following is a bounded grid in Day and Night and its inverse - the one that dies out displays a message, but the one that fills with alive cells does not, despite the fact that in this context they mean the same thing and no further change will ever happen.

Code: Select all

x = 40, y = 40, rule = B3678/S34678:T40,40
b2o3b5obobobo4bobo2b2o6bobobo$b2o2b2ob3obo2b3o3b3ob3o2bo2b2ob2obo$2o2b
2ob2o2bo2bobob4ob5o2b6obo$b2obo2bo3b2obobob5o4bo2b3obob2o$5ob3o2b4ob2o
2bo3b2obobo2b7o$2ob5o2b3o3b2o2b2ob4ob5ob4obo$4o2bob5o4bo2b2obobo3bob5o
$ob2ob4ob3ob3ob4obo4b3o2b4o2bo$2o3b3o2b2o3b4obobo2b2o7bo3b2o$5obo2b3o
4bob2o2b3o2b2obo4bob2o$2b4o3b2o3bob4o6bob2o3bob2o2bo$3bo2b5o2b2o4bob4o
3b3obo2b2o2bo$2o2bo3bo6bob2ob2obob4ob3o2b3obo$o2b3ob2ob4o2bo8b4o2bo3b
2o$bob2o3bo2b2obobo2b3obobob2ob2o4bo2bo$b6o4b3o2b3obo2b7o3b3obo$o3bo4b
2ob3o3bo3bob2obob2o2bo2b2o$bobob3ob2ob2o3b9o3bob2o2b2obo$o2bob6o3bobo
b2o3bo2b2obo3bobobobo$bo2bo4b3obo2bo2b2obob3ob2ob3o4b2o$3o5bo4b7o3b4o
bobobob3ob2o$o4bobo2bo9b2o4b3o3bo2b2o2bo$4o2bo2bob2o3bob5ob2o2b4ob7o$
b8ob4obo3bo2bobo4b2o2b2obo2bo$2o2bob3ob2obo3bo2b3o3bob2ob2ob2ob2o$bob
4o7bob2ob8o2b3o3b3o$2obob2ob4o3b2obobo2b2ob3ob3obo2b2o$2b3o2b6obo2b3o
4bo2bo3b5o2bo$2bob5o2bo3b3o2b2obob2o2b3o5b2o$bo2b4o2b2ob2ob2o2b5o3bo4b
obob2o$bo4bob3obobo2bo2bobob2obobobob4ob2o$o2bob3o2b2o3b7obobo2b4ob2o
3bo$8obo3b2ob2o2b10ob2obo2bo$3ob3obo3b2obobo3b2o4b2o3bo$2b5ob2obo2b6o
bobobo4bobobo4bo$2obo2b4o4b6o2bobo2bob2o4bob3o$o2b3obo2bo2b9obob3obob
o3bo2bo$b6obobo2b2ob2o4bo3bob2o3b3ob2o$2o2b2o2bob2o2b5o6bobo4bobobo$o
bob3obo3bo7b2ob3obo4bo3bobo!
[[ SHOWGENSTATS ]]

Code: Select all

x = 40, y = 40, rule = B3678/S34678:T40,40
o2b3o5bobobob4obob2o2b6obobobo$o2b2o2bo3bob2o3b3o3bo3b2ob2o2bo2bo$2b2o
2bo2b2ob2obobo4bo5b2o6bob2o$o2bob2ob3o2bobobo5b4ob2o3bobo2b2o$5bo3b2o
4bo2b2ob3o2bobob2o7bo$2bo5b2o3b3o2b2o2bo4bo5bo4bo$4b2obo5b4ob2o2bobob
3obo5b4o$bo2bo4bo3bo3bo4bob4o3b2o4b2o$2b3o3b2o2b3o4bobob2o2b7ob3o$5bo
b2o3b4obo2b2o3b2o2bob4obo2bo$2o4b3o2b3obo4b6obo2b3obo2b2o$3ob2o5b2o2b
4obo4b3o3bob2o2b2o$2b2ob3ob6obo2bo2bobo4bo3b2o3bo$b2o3bo2bo4b2ob8o4b2o
b3o2b3o$obo2b3ob2o2bobob2o3bobobo2bo2b4ob2o$o6b4o3b2o3bob2o7b3o3bob2o
$b3ob4o2bo3b3ob3obo2bobo2b2ob2o2b2o$obobo3bo2bo2b3o9b3obo2b2o2bobo$b2o
bo6b3obobo2b3ob2o2bob3obobobo$ob2ob4o3bob2ob2o2bobo3bo2bo3b4o$3b5ob4o
7b3o4bobobobo3bo$b4obob2ob9o2b4o3b3ob2o2b2o$4b2ob2obo2b3obo5bo2b2o4bo
$o8bo4bob3ob2obob4o2b2o2bob2o$2b2obo3bo2bob3ob2o3b3obo2bo2bo2bo2bo$ob
o4b7obo2bo8b2o3b3o3b2o$2bobo2bo4b3o2bobob2o2bo3bo3bob2o2bo$2o3b2o6bob
2o3b4ob2ob3o5b2obo$2obo5b2ob3o3b2o2bobo2b2o3b5o2bo$ob2o4b2o2bo2bo2b2o
5b3ob4obobo2bo$ob4obo3bobob2ob2obobo2bobobobo4bo$b2obo3b2o2b3o7bobob2o
4bo2b3obo$8bob3o2bo2b2o10bo2bob2ob2o$3bo3bob3o2bobob3o2b4o2b3ob7o$2o5b
o2bob2o6bobobob4obobob4o$2bob2o4b4o6b2obob2obo2b4obo$b2o3bob2ob2o9bob
o3bobob3ob2obo$o6bobob2o2bo2b4ob3obo2b3o3bo2bo$2b2o2b2obo2b2o5b6obob4o
bobob3o$bobo3bob3ob7o2bo3bob4ob3obobo!
[[ SHOWGENSTATS ]]

[muzik]

custom themes can be created if we change the colors of states that don't exist. For 2-state rules, such as the following, no script error is produced either unless we specify a number below 0 or above 255, but even exceeding those numbers creates a custom theme for some reason.

Fixed, thanks.

It does display an error message, but a custom theme is still defined anyway, which I don't think is right.

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR 2 Green ]]

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR 3 Green ]]

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR 256 Green ]]

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR 2147483650 Green ]]

Contrast this to changing nonexistent elements by name:

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR thingthatdoesnotexist Blue ]]

I will point out that custom themes are also enabled in some cases if we customize the colors of elements that exist in other rulespaces but not the current one (and in such cases, we don't get an error message):

Code: Select all

x = 13, y = 14, rule = B3/S23
10bo$10bobo$10b2o5$4b2o$3bo2bo$3bobo$b2obo$o2bo$obo$bo!
[[ COLOR DYING Blue ]]

Code: Select all

x = 8, y = 8, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
7.C$6.C$5.C$4.C$3.L$2.L$.L$L!
[[ COLOR ALIVE Blue ]]

Code: Select all

x = 8, y = 8, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
7.C$6.C$5.C$4.C$3.L$2.L$.L$L!
[[ COLOR alive Blue ]]

[rowett]

Some rulespaces still cause phantom cells with PASTE at high distances

Fixed, thanks.

[rowett]

There appear to be issues with drawing in grids bounded in only one dimension.

Fixed, thanks.

Now that we can scroll through the table of periods, would it be possible to visually truncate it at the bottom so that it doesn't visually go under the playback buttons and such?

Yes, done.

In Identify, still lifes in hexagonal or triangular rules don't display a value for "Density", even though they do for "Bonding Box".

I removed Bounding Box.

[muzik]

Now that 2-state ruletables have official functionality that normal native rules do not support (i.e. "proper" non-emulated B0 on bounded grids), would theme support and history processing for 2-state ruletables in specific be possible? This was rejected previously since everything a rule table could do was already possible via something natively supported, but this is no longer the case.

If the rule table contains a @COLORS section, then a CUSTOM theme would be automatically created based on it and then applied. Example, if we pretend that the colors from the default gradient for 2 states was explicitly defined for the following rule:

Code: Select all

x = 7, y = 5, rule = B3/S23:S30*
3b2o$bo4bo$o$o5bo$6o!
[[ COLOR BACKGROUND 0 0 0 COLOR DEAD 0 0 0 COLOR DEADRAMP 0 0 0 COLOR ALIVE 255 0 0 COLOR ALIVERAMP 255 0 0 ]]

Code: Select all

x = 7, y = 5, rule = Life-RuleTree:S30*
3b2o$bo4bo$o$o5bo$6o!

LifeViewer appears to accept the following as valid, but Golly does not, and saving these patterns produces a format that LifeViewer proceeds to reject. I'm curious, though: how exactly are these invalid? With the following test patterns, I don't encounter any random unexpected births/deaths or any of the other weird behaviour associated with invalid bounded grids that I have previously, so this is almost weirder.

Code: Select all

x = 22, y = 22, rule = B3/S23:K22+1
o5$o$2o$bo$o$o$o$21bo$20b2o$20b2o$20b2o$21bo6$21bo!

Code: Select all

x = 24, y = 24, rule = B3/S23:K24+1
5b4o4$2o$bo$bo$bo$o7$22bo3$22bo$23bo2$4bo2bo$8bo$4bo3bo!

There's also the following incredibly fun bug that I've been experimenting with for a while: torus shifts greater than the dimension of the grid itself are not processed correctly, which can result in that edge of the torus blocking cell interactions, or even allowing them to escape the bounded grid entirely:

Code: Select all

x = 2, y = 2, rule = B12345678/S012345678:T20,20+100
2o$2o!
[[ ZOOM 4 ]]

LifeViewer should probably implement Golly's functionality here: for a given shifted side m+n, for positive n, where n>m, n is replaced with n mod m. So, for the following, 21 mod 20 = 1, so the grid definition is replaced with T20,20+1:

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q:T20,20+21
o$2o$o!

Negative values work similarly, as the following becomes T20,20-1:

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q:T20,20-21
o$2o$o!

Neither Golly nor LifeViewer distinguish between the following two cases, though, despite them being identical in meaning. I'm not sure if it'd be a good idea to try and collapse them down to the simplest possible form (the shift that has the lowest absolute value, or if they're both the same such as 20+10 and 20-10, use the positive one instead of the negative one).

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q:T20,20+11
o$2o$o!

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q:T20,20-9
o$2o$o!

And just to put this surprisingly entertaining issue to rest, let's hit the maximum value of a double for a shift of Infinity (which can be seen if we use Save Pattern):

Code: Select all

x = 20, y = 20, rule = B123478/S01234678:T20+999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o
$20o$20o!
[[ MAXGRIDSIZE 9 ]]

I'll definitely be sad to see this one go. Really makes me wish there was some sort of "debug mode" that allowed for drawing outside of bounded grids for fun, but that will realistically never come.

[rowett]

LifeViewer appears to accept the following as valid, but Golly does not

Fixed, thanks. Golly was correct.

torus shifts greater than the dimension of the grid itself are not processed correctly

Fixed, thanks.

LifeViewer should probably implement Golly's functionality here: for a given shifted side m+n, for positive n, where n>m, n is replaced with n mod m.

Done, thanks.

Neither Golly nor LifeViewer distinguish between the following two cases, though, despite them being identical in meaning.

Nor should they.

And just to put this surprisingly entertaining issue to rest, let's hit the maximum value of a double for a shift of Infinity

I've added a maximum range allowed so this is now an error. The issue with not doing so is you are then dependent on the number representation of the programming language and platform for the eventual modulo shift value you end up with. For this pattern in Golly (C++) this was different to LifeViewer (Javascript).

[muzik]

This is incredibly bizarre - Identify now appears to be reporting the speed of the lightweight spaceship as c (4c/4). This is in direct contradiction with what I remember about it, which is that it moves at c/2 (2c/4). The LifeWiki and other sources still report that the LWSS moves at c/2, and for it to move at any faster speed would directly contradict this 2009 proof by Nathaniel Johnston that for B3/S23 an orthogonal spaceship in a vacuum cannot move any faster than c/2 orthogonally. Have any unannounced changes been made to the real number system lately that could have resulted in this peculiar discrepancy?

Code: Select all

x = 13, y = 9, rule = R2,C2,S2-3,B3,NF
2b2o4b2o$2b2o4b2o$2o$2o$2o6b2o$2o6b2o$8o$8o!
[[ ZOOM 8 ]]

I'd also like to show off this other cool bug that I just found:

Code: Select all

x = 57, y = 57, rule = R7,C2,S63-108,B63-84,86
41$8b2o$6b5o$5b7o$3b5o3b2o$2b5o5b2o$b5o7b2o$b5o7b3o$6o7b3o$b6o5b3o$b7o
3b4o$2b12o$3b10o$4b9o$5b7o$6b5o$8bo!
[[ ZOOM 20 TRACK -27/39 27/39 GPS 13 AUTOSTART LAYERS 7 STARS COLOR STARS 255 192 255 ]]

[muzik]

And just to put this surprisingly entertaining issue to rest, let's hit the maximum value of a double for a shift of Infinity

I've added a maximum range allowed so this is now an error. The issue with not doing so is you are then dependent on the number representation of the programming language and platform for the eventual modulo shift value you end up with. For this pattern in Golly (C++) this was different to LifeViewer (Javascript).

Can the maximum shift be changed to 2147483648 as to match Golly?

Also, speaking of shifts, there appears to be an issue where shifts aren't processed for some rulespaces, and it acts as though the shift is 0.

Code: Select all

x = 6, y = 5, rule = B3/S23:T20,40+3
3bo$bo3bo$o$o4bo$5o!

Code: Select all

x = 6, y = 5, rule = R1,C2,S2-3,B3:T20,40+3
3bo$bo3bo$o$o4bo$5o!