Pattern viewer for forum threads

[muzik]

On the topic of weighted neighbourhoods, since certain neighbours can have negative weights, shouldn't birth conditions also be able to be negative?

Code: Select all

x = 41, y = 49, rule = R1,C2,S2-3,B3,NW111101111
19b2o$19b4o$19bob2o2$20bo$19b2o$19b3o$21bo$33b2o$33b2o7$36bo$35b2o$34bo3bo$35b2o2bo$40bo$37bobo$38bo$38bo$38b2o$38b2o3$13bo10bo$12b5o5bob2o11bo$11bo10bo3bo9bo$12b2o8b3obo9b2o$13b2o9b2o12bo$2o13bo21b3o$2o35b3o7$8b2o$8b2o11b2o$19b2o2bo$24bo3bo$18bo5bo3bo$19bo2b2o3bobo$20b3o5bo$28bo!

Code: Select all

x = 41, y = 49, rule = R1,C2,S-2--3,B-3,NW999909999
19b2o$19b4o$19bob2o2$20bo$19b2o$19b3o$21bo$33b2o$33b2o7$36bo$35b2o$34bo3bo$35b2o2bo$40bo$37bobo$38bo$38bo$38b2o$38b2o3$13bo10bo$12b5o5bob2o11bo$11bo10bo3bo9bo$12b2o8b3obo9b2o$13b2o9b2o12bo$2o13bo21b3o$2o35b3o7$8b2o$8b2o11b2o$19b2o2bo$24bo3bo$18bo5bo3bo$19bo2b2o3bobo$20b3o5bo$28bo!

[muzik]

Would it be possible to support the triangular Moore and triangular von Neumann neighbourhoods in rule tables (see here for specifications)?

Code: Select all

x = 1, y = 1, rule = TriVNTest
o!

Code: Select all

x = 1, y = 1, rule = B13/S13LE
o!

[rowett]

On the topic of weighted neighbourhoods, since certain neighbours can have negative weights, shouldn't birth conditions also be able to be negative?

No that's by design.

[rowett]

Would it be possible to support the triangular Moore and triangular von Neumann neighbourhoods in rule tables

No. They're not supported natively by Golly. It has a script to convert them to RuleTrees.

[muzik]

Would it be possible to support the triangular Moore and triangular von Neumann neighbourhoods in rule tables

No. They're not supported natively by Golly. It has a script to convert them to RuleTrees.

Can some sort of way be added to make those actually render like proper triangular rules in LifeViewer?

Code: Select all

x = 1, y = 1, rule = Fredkin mod3 triangularVonNeumann emulated
o!
[[ ZOOM 4 ]]

A slider or two that allows the grid to be "sheared" as follows could help, as getting it to the right value would distort each square into a rhombus that could be dissected into two equilateral triangles:

Code: Select all

x = 107, y = 42, rule = B3/S23
bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo25bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo$42o23b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo25b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo24bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o22b42o$bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo24bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo23bo2bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo$42o21b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo2bo23bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo22bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o
20b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo22bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo21bo2bo
2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o19b42o$bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo2bo21bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo
2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo20bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo$42o18b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo20bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo19bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o17b42o$bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo19bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo18bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo$42o16b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
18bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo17bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o15b42o$b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo17bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo16bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o14b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo2bo2bo16bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo15bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$
42o13b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo15bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo14bo
2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o12b42o$bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo2bo2bo2bo2bo14bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo
2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo13bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo2bo$42o11b42o$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo13bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo
2bo2bo12bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$42o10b42o$bo2bo2bo2b
o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo12bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2b
o2bo!

[muzik]

There is currently no way to copy a custom neighbourhood to the clipboard on mobile devices, as the copy neighbourhood button does not work on such platforms. Could a "save neighbourhood" button be added to one of the menus that outputs it to an external text box if one exists, like with the "save pattern" button, or possibly open up a dialog text box?

[muzik]

For History rules, gray cells appear to kill more distant cells on hexagonal grids, and fail to kill some close by cells on triangular grids:

Code: Select all

x = 15, y = 9, rule = B/S0123456HHistory
2$4.4A$4.5A$4.6A$4.3AF3A$5.6A$6.5A$7.4A!
[[ GRID ]]

Code: Select all

x = 16, y = 9, rule = B/S0123456789XYZLHistory
$8.A$7.3A$6.5A$5.7A$4.9A$3.5AF5A$2.13A$.15A!
[[ GRID ]]

Code: Select all

x = 15, y = 9, rule = B/S0123HTHistory
2$4.4A$4.5A$4.6A$4.3AF3A$5.6A$6.5A$7.4A!
[[ GRID ]]

Code: Select all

x = 16, y = 9, rule = B/S0123LEHistory
$8.A$7.3A$6.5A$5.7A$4.9A$3.5AF5A$2.13A$.15A!
[[ GRID ]]

Code: Select all

x = 16, y = 9, rule = B/S0123456789LVHistory
$8.A$7.3A$6.5A$5.7A$4.9A$3.5AF5A$2.13A$.15A!
[[ GRID ]]

Code: Select all

x = 16, y = 9, rule = B/S0123456LIHistory
$8.A$7.3A$6.5A$5.7A$4.9A$3.5AF5A$2.13A$.15A!
[[ GRID ]]

Code: Select all

x = 16, y = 9, rule = B/S0123456LOHistory
$8.A$7.3A$6.5A$5.7A$4.9A$3.5AF5A$2.13A$.15A!
[[ GRID ]]

This is almost certaintly due to the grid still being treated as a square grid somewhere, when it should not be. The way in which gray cells work is that any living cell which has a gray cell in its neighbourhood should die in the next generation. In the top two cases illustrated above, however, the hexagonal neighbourhood has two hexagonal cells that do not have the gray cell in their neighbourhood but are killed anyway, and four triangular cells which have the gray cell in their neighbourhood are not killed.

Unsurprisingly, Von Neumann is also affected by this, but not in [R]Super:

Code: Select all

x = 5, y = 5, rule = B/S01234VHistory
5A$5A$2AF2A$5A$5A!
[[ GRID ]]

Code: Select all

x = 5, y = 5, rule = B/S01234VSuper
5A$5A$2AF2A$5A$5A!
[[ GRID ]]

The behaviour in [R]History for hexagonal and Von Neumann neighbourhoods clash with what is seen in Golly, so these should be fixed.

A bug I discovered while testing this: for [R]Super, hexagonal patterns appear completely invisible (or, if one of the above viewers is opened first, having died at some point) until you zoom out or activate rectangles:

Code: Select all

x = 15, y = 9, rule = B/S0123456HSuper
2$4.4A$4.5A$4.6A$4.3AF3A$5.6A$6.5A$7.4A!
[[ GRID ]]

Code: Select all

x = 15, y = 9, rule = B/S0123HTSuper
2$4.4A$4.5A$4.6A$4.3AF3A$5.6A$6.5A$7.4A!
[[ GRID ]]

Zooming out and advancing one generation reveals the deletion to indeed be in a hexagonal shape, but offset to the right. Task completed unsuccessfully?

[rowett]

The behaviour in [R]History for hexagonal and Von Neumann neighbourhoods clash with what is seen in Golly, so these should be fixed.

Fixed, thanks.

A bug I discovered while testing this: for [R]Super, hexagonal patterns appear completely invisible

Fixed, thanks.

Zooming out and advancing one generation reveals the deletion to indeed be in a hexagonal shape, but offset to the right.

Fixed, thanks.

Hex Tripod neighbourhood is not supported with [R]Super.

[hotdogPi]

This might be a forum issue and not a LifeViewer issue, but clicking "show in viewer" in this post makes the code block disappear.

[muzik]

Can Help > Info > Pattern be made to show neighbourhood diagrams for non-custom neighbourhoods like how it does for custom neighbourhoods? This should help with visualisation for certain higher-range neighbourhoods that aren't necessarily visually obvious such as circular and Gaussian neighbourhoods, as well as demonstrate how triangular grid neighbourhoods work.

Code: Select all

x = 3, y = 3, rule = B3/S23
3o$obo$3o!

Code: Select all

x = 3, y = 3, rule = R1,C2,S2-3,B3
3o$obo$3o!

Code: Select all

x = 3, y = 3, rule = R1,C2,S2-3,B3,NG
3o$obo$3o!

Code: Select all

x = 3, y = 3, rule = R1,C2,S,B,NW999909999
3o$obo$3o!

[muzik]

I'm not sure that History killing cells are working correctly in History. Here's the test case:

Code: Select all

x = 15, y = 9, rule = B/S0123HTHistory
2$4.4A$4.5A$4.6A$4.3AF3A$5.6A$6.5A$7.4A!
[[ GRID ]]

The way that killer cells are supposed to work is that any living cell that has a killer cell in its neighbourhood will die in the next generation. However, it seems that in this case, the opposite is true. Here's b1:

Code: Select all

x = 9, y = 5, rule = B1/SHT
o!

As can be seen here, those exact same three cells (in relation to the center) are born; right, top-left and bottom-left. Note that in the Tripod neighbourhood, "cells in this central cell's neighbourhood" is distinct from "cells that have this central cell in their neighbourhood"; in fact, the truth is the inverse of this, and as such it would be expected that the other three cells surrounded by the killer cell would die since they have it in their neighbourhood, and that the three cells that die currently would stay alive as they don't have it in theirs.

Since neighbourhoods like these exist where cells in a central cell's neighbourhood do not necessarily have that central cell's in their own, could another section be added to Help > Info > Pattern that lists all cells that have a central cell in their neighbourhood; a cell's "region of influence" if that's a fitting name?

[rowett]

This might be a forum issue and not a LifeViewer issue, but clicking "show in viewer" in this post makes the code block disappear.

It's deliberate. Scroll down in the RLE and you'll see the relevant script command at the bottom.

[rowett]

I'm not sure that History killing cells are working correctly in History. Here's the test case:

True for Hex Tripod neighbourhood.

I'm going to disable [R]History support for Hex Tripod and triangular rules since the current state 6 algo won't work for them. Also I'd like parity between [R]History and [R]Super and the latter only supports Moore, von Neumann and Hexagonal neighbourhoods.

[muzik]

I'm not sure that History killing cells are working correctly in History. Here's the test case:

I'm going to disable [R]History support for Hex Tripod and triangular rules since the current state 6 algo won't work for them.

Will [R]History (and, by extension, [R]Super) support ever return to these neighbourhoods if state 6 handling can be improved?

On the topic of [R]History and [R]Super, I assume you've seen this already but Super's state 6 cells may potentially have another flaw that needs addressing. The potentially unwanted behaviour is identical in LifeViewer and Golly so I'm not sure what exactly is intended.

[rowett]

Will [R]History (and, by extension, [R]Super) support ever return to these neighbourhoods if state 6 handling can be improved?

Possibly. There are many such low priority items on the backlog that I never have time to get to. The more popular a feature is the more likely it is to get implemented.

On the topic of [R]History and [R]Super, I assume you've seen this already but Super's state 6 cells may potentially have another flaw that needs addressing. The potentially unwanted behaviour is identical in LifeViewer and Golly so I'm not sure what exactly is intended.

Yes it's working as specified.

[muzik]

[R]History and [R]Super seem to treat state 6 differently in some cases. For example, a pattern consisting of state 6 as the only present nonzero cell state shows "New Pattern" for [R]History, but not for [R]Super:

Code: Select all

x = 15, y = 7, rule = B36/S23History
.3F3.F$F$F9.F3.F$.3F3.F3.F.F$4.F2.F4.F$4.F2.F3.F.F$.3F3.F2.F3.F!

Code: Select all

x = 15, y = 7, rule = B36/S23Super
.3F3.F$F$F9.F3.F$.3F3.F3.F.F$4.F2.F4.F$4.F2.F3.F.F$.3F3.F2.F3.F!

While [R]History arguably shows the correct behaviour in this case due to it correctly processing the lack of any alive cells, the message "New Pattern" seems off to me since the provided pattern isn't a blank canvas. It might be worth introducing another message for cases like these:
- Only state 0 cells are present in the RLE: "New Pattern"
- Even-state [R]History/[R]Super cells are present, but no odd states: "No living cells"
- 1 or more odd-state cell is present: No message

A similar scheme could be adopted for trying to select all/Identify with no living states present.

In addition, all cells dying in [R]Super does not show an everything died at message like in [R]History.

Code: Select all

x = 7, y = 7, rule = B36/S23History
4.A$4.A.A$4.2A4$F!

Code: Select all

x = 7, y = 7, rule = B36/S23Super
4.A$4.A.A$4.2A4$F!

In the following example, the T menu misreports the number of alive states in generation 1 for [R]Super:

Code: Select all

x = 5, y = 5, rule = B36/S23History
2.F$.3A$FAFAF$.3A$2.F!
[[ STOP 1 SHOWGENSTATS ]]

Code: Select all

x = 5, y = 5, rule = B36/S23Super
2.F$.3A$FAFAF$.3A$2.F!
[[ STOP 1 SHOWGENSTATS ]]

The number of births and deaths in both examples also appears to be incorrect (they may be cancelled births that would have been born into spaces where state 6 is, but I'm not sure if those should be reported as births or not).

[muzik]

Could dead zones be added to ... all 45 degree increments of the angle slider, to make these exact values easier to manually select?

No to the angle slider.

Could a button be added somewhere in the viewer that snaps the camera's rotation to the closest 45 degree increment then, much like how Integer Zoom brings the zoom level to the nearest integer?

[rowett]

In the following example, the T menu misreports the number of alive states in generation 1 for [R]Super:

Fixed, thanks.

[muzik]

While testing hexagonal history and super rules earlier, I noticed that drawing on a hexagonal grid appears to be slightly biased to the right. Try clicking in the far right of a cell and note that the cell to the right of that cell is modified instead. The same does not happen for the left of that same cell - the targeted cell is filled in as expected.

Code: Select all

x = 1, y = 1, rule = B/S0123456H
!
[[ GRID ZOOM 64 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123456H
!
[[ GRID ZOOM 64 SQUARECELLS ]]

Also, blank hexagonal patterns appear to start very zoomed out by default instead of at 32.0 like square and triangular grids:

Code: Select all

x = 1, y = 1, rule = B/S0123456H
!
[[ GRID ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
!
[[ GRID ]]

Code: Select all

x = 1, y = 1, rule = B/S0123456789XYZL
!
[[ GRID ]]

In addition, the hexagonal grid appears to be centered about 192 cells in the negative X direction instead of at (0,0) regardless of whether zoom is overridden in these cases.

[rowett]

I noticed that drawing on a hexagonal grid appears to be slightly biased to the right.

Fixed, thanks.

Also, blank hexagonal patterns appear to start very zoomed out

Fixed, thanks.

In addition, the hexagonal grid appears to be centered about 192 cells in the negative X direction instead of at (0,0) regardless of whether zoom is overridden in these cases.

Fixed, thanks.

[muzik]

The right bias issue seems to be fixed, but the problem region inside each hexagon appears to be a sort of dead area now such that literally nothing happens when clicked. Shouldn't such regions modify the hexagon containing them?

[rowett]

The right bias issue seems to be fixed, but the problem region inside each hexagon appears to be a sort of dead area now such that literally nothing happens when clicked. Shouldn't such regions modify the hexagon containing them?

I don't understand what you mean by "problem region".

[muzik]

The right bias issue seems to be fixed, but the problem region inside each hexagon appears to be a sort of dead area now such that literally nothing happens when clicked. Shouldn't such regions modify the hexagon containing them?

I don't understand what you mean by "problem region".

The region of a hexagonal cell that previously caused cells to be drawn to the right of the targeted cell now does nothing when clicked on on my end.

[rowett]

The right bias issue seems to be fixed, but the problem region inside each hexagon appears to be a sort of dead area now such that literally nothing happens when clicked. Shouldn't such regions modify the hexagon containing them?

I don't understand what you mean by "problem region".

The region of a hexagonal cell that previously caused cells to be drawn to the right of the targeted cell now does nothing when clicked on on my end.

Try hard refresh on the browser - it works for me.

[muzik]

Does seem to work now.

On a related note, drawing on the hexagonal grid seems to assume that the offset square grid is in use, since clicking near the top of a hexagonal cell will end up drawing in one of the two cells above it:

Code: Select all

x = 1, y = 1, rule = B/S0123456H
!
[[ ZOOM 64 GRID ]]

Offset square grid for comparison, where this issue is not present:

Code: Select all

x = 1, y = 1, rule = B/S0123456H
!
[[ ZOOM 64 GRID SQUARECELLS ]]

Drawing, selections and other such actions should adapt to how the grid is currently rendered.