Pattern viewer for forum threads

[rowett]

Right clicking on the top bar ("LifeViewer") will (at least on my end) cause an unusual thing to happen: the context menu appears as you'd expect, but moving the cursor will cause the viewer popup to follow it, as though left button is being held down.

LifeViewer will now only use the primary mouse button.

The "show help topics" button in any help page still uses a caret

Changed in build 1353.

Using the scroll wheel to zoom in one unit and then zoom out one unit does not put us back at the zoom level we started from.

It's an artifact of displaying the zoom value rounded down now.

The fix for icons becoming black appears to have some other strange effects.

Fixed in build 1353.

[muzik]

The fix for icons becoming black appears to have some other strange effects.

Fixed in build 1353.

Checking the behaviour on desktop in build 1353, and the icons still have black regions:

1353stillblack.png (42.44 KiB) Viewed 2171 times

Right clicking on the top bar ("LifeViewer") will (at least on my end) cause an unusual thing to happen: the context menu appears as you'd expect, but moving the cursor will cause the viewer popup to follow it, as though left button is being held down.

LifeViewer will now only use the primary mouse button.

An idea I've been thinking about for a while now: in Draw mode, would it be possible to draw different cell states using different mouse buttons? The left mouse button would draw with state 1 (unless you picked another state), the right mouse button would draw with state 2, and the middle button would draw with state 3. You could use the right or middle button on the state picker in the menu to define what the right or middle buttons draw with by clicking on that specific state with one of the respective mouse buttons.

[rowett]

Checking the behaviour on desktop in build 1353, and the icons still have black regions:

I can't reproduce this. Which browser/device/OS are you using?

[muzik]

Checking the behaviour on desktop in build 1353, and the icons still have black regions:

I can't reproduce this. Which browser/device/OS are you using?

Kubuntu 24.04 running the latest version of Waterfox. I've also tried this on the usual iPad/Safari combo and the effects appear to still be the same as in build 1352.

IMG_2603.jpeg (247.03 KiB) Viewed 2159 times

Another icons-related visual bug I've noticed: the leftmost column and topmost row of out-of-bounds cells here initially appear blank (or even entirely transparent depending on browser). Turning off icons appears to fix this.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -256 Y -256 ICONS ]]

The positive equivalent does not exhibit this issue:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X 256 Y 256 ICONS ]]

It doesn't appear to be mandatory for the camera to be centered at the absolute edge for this to occur:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -250 Y -250 ICONS ]]

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -246 Y -246 ICONS ]]

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -245 Y -245 ICONS ]]

...though you can't be too close to the origin:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -240 Y -240 ICONS ]]

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 X -1 Y -1 ICONS ]]

[muzik]

Drawing any cell state next to the boundary here and pressing Play will result in very obvious wrong behaviour. A "Life ended at" message is displayed despite cells visibly remaining on screen, and continuing playback will either keep those cells there or cause p2 strobing.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ GRID MAXGRIDSIZE 9 X 256 ARROW 255 -2 255 -1 32 ]]

The opposite boundary does not appear to be affected:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ GRID MAXGRIDSIZE 9 X -256 ARROW -256 -2 -256 -1 32 ]]

Both the top and bottom boundaries also seem to be affected:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ GRID MAXGRIDSIZE 9 Y -256 ARROW -2 -256 -1 -256 32 ]]

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ GRID MAXGRIDSIZE 9 Y 256 ARROW -2 255 -1 255 32 ]]

[muzik]

Something bizarre appears to be going on here: both the offset rectangle and true hexagonal grids appear to be in use at the same time?

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM 4.61 STARTFROM 255 X 96 Y -96 ]]

In fact, as we watch the bounding box of all alive cells grow, we see the grid itself as well as the shapes of the history cells (better seen if the grid is turned off) shapeshifting in real time from the offset grid to the hexagon grid:

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM 4.61 AUTOSTART STARTFROM 255 GPS 20 X 96 Y -96 THEME Red GRID ]]

Zooming in beyond 4.61 causes everything outside of the bounding box of all living cells to disappear.

[rowett]

Something bizarre appears to be going on here: both the offset rectangle and true hexagonal grids appear to be in use at the same time?

Fixed in build 1355.

[muzik]

Something bizarre appears to be going on here: both the offset rectangle and true hexagonal grids appear to be in use at the same time?

Fixed in build 1355.

Fix confirmed for that specific case. However, it still appears to be happening here:

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ X 64 PASTEMODE XOR PASTEDELTA 1 0 PASTET EVERY 1 PASTE o! 0 0 PASTE o! 0 0 THEME Red AUTOSTART ZOOM 4.61 ]]

Compare to this pattern (same as above but we don't paste a second time to cancel out and produce a history cell), which has an alive cell in each phase, resulting in hexagons correctly being used:

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ X 64 PASTEMODE XOR PASTEDELTA 1 0 PASTET EVERY 1 PASTE o! 0 0 THEME Red AUTOSTART ZOOM 4.61 ]]

Another issue I found while testing this: when pausing, the entire trail of history cells left behind will disappear.

Code: Select all

x = 1, y = 1, rule = B/SL
!
[[ PASTEDELTA 1 0 PASTET EVERY 1 PASTE o! 0 0 THEME Red AUTOSTART AUTOFIT ]]

I am not sure why, but on this page only the first two posts appear to be playable; everything else only shows "select all" for code boxes.

[rowett]

I am not sure why, but on this page only the first two posts appear to be playable; everything else only shows "select all" for code boxes.

Fixed in build 1357.

[muzik]

Is this just on my end, or is artifacting visible here? As the hexagon expands and its top and bottom faces leave the window, some sort of line effect (hard to describe) travels up from the bottom of the screen.

Code: Select all

x = 1, y = 1, rule = B123456/SH
o!
[[ ZOOM 8.5 THEME Red STEP 2 POPUPWIDTH 1920 POPUPHEIGHT 1080 ]]

The triangular grid is also affected in a similar way:

Code: Select all

x = 4, y = 2, rule = B123456789xyz/SL
b3o$b3o!
[[ ZOOM 4.5 THEME Red STEP 2 POPUPWIDTH 1920 POPUPHEIGHT 1080 ]]

Here's a test case for the "pausing removes history cells" issue that does not use PASTE:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B1,N@10H
o!
[[ THEME Red AUTOFIT AUTOSTART ]]

Reiterating an old bug:

Code: Select all

# saving this will make the bounded grid canonical
x = 3, y = 3, rule = B3/S23:k32,16
o$obo$2o!

Code: Select all

# saving this will not make the bounded grid canonical
x = 3, y = 3, rule = Life-RuleLoader:k32,16
o$obo$2o!

[rowett]

This test case for drawn cell connectedness may be clearer: try drawing a straight line as fast as you can within the bounds of the green lines and within the bounds of the red lines. Green lines indicate that the resulting line is connected (as it should be), whereas red lines indicate where gaps will occur.

This has been improved for the Hexagonal grid in build 1358.

EDIT:
On reflection the triangular grid drawing is correct. The triangular grid can be replaced by a rectangular grid (unlike the hexagonal grid which is replaced by an offset square grid). So the drawing should be the same as for the square grid. If you join up all the triangles via edges (rather than vertices) you are creating unneeded extra cells.

[muzik]

Here's another behavioural disparity I've spotted in regard to viewer sizes: the Draw menu will be wider for bigger screen sizes, allowing for more states to be seen. However, this is not true for maximized popups, even if they have the same size: it will always show about seven states with the slider on the left for navigation.

Code: Select all

x = 4, y = 4, rule = Pulse2
4Q$Q2.Q$Q2.Q$OP2Q!
[[ ICONS ]]

Here's how it looks in an embedded viewer:

IMG_2739.jpeg (399.11 KiB) Viewed 2003 times

versus a maximized popup:

IMG_2737.jpeg (290.84 KiB) Viewed 2003 times

Much like the zoom bar and help topic list I'd expect this would adapt to the current size of the viewer window rather than being fixed depending on initial size or embed type.

In oscillator period and frequency maps on bounded grids, the colour of the boundary appears to change depending on zoom level: if zoomed in enough such that the grid is visible, it uses the "bounded" colour, but when zoomed out beyond that point, it uses the "grid" colour. For bounded grids, could the "bounded" colour always be used for the outer boundary?

Code: Select all

x = 1, y = 1, rule = B1357/S02468:P33
o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = B1357/S02468:P65
o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = B1357/S02468:P129
o!
[[ AUTOIDENTIFY ]]

Something that might be useful for the wiki would be a script command to automatically display the period map or frequency map after AUTOIDENTIFY, rather than the initial results table.

Here's a bounded grid related feature request: due to the way hexagonal rules are implemented, anything crossing the vertical boundary will be shifted by half the grid's height to the right.

Code: Select all

x = 5, y = 5, rule = B2/S2H:T60,30
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ]]

We can mitigate this by subtracting half of the grid's height from the width as a shift, which will cause the object crossing this boundary to retain its X position:

Code: Select all

x = 5, y = 5, rule = B2/S2H:T60-15,30
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ]]

Here's the same pattern on an unbounded grid on the X-axis, which, as before, moves to the right every time it crosses the boundary:

Code: Select all

x = 5, y = 5, rule = B2/S2H:T0,30
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ]]

Unfortunately in this case we can't do any kind of shift, since such a grid definition is blocked, even though it would be useful in this case. Is this something that would be possible to support, or should we follow Golly's lead and continue to reject it in the interests of pattern compatibility?

Code: Select all

x = 5, y = 5, rule = B2/S2H:T0-15,30
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ]]

On reflection the triangular grid drawing is correct. The triangular grid can be replaced by a rectangular grid (unlike the hexagonal grid which is replaced by an offset square grid). So the drawing should be the same as for the square grid. If you join up all the triangles via edges (rather than vertices) you are creating unneeded extra cells.

I'm not as certain. Indeed a rectangular grid is used "in the background", for processing and rendering and so on, but the intended outcome (as far as the user is concerned) is distinctly a triangular grid. Any more cells that you get aren't "extra" in this case, but a natural result of how cells are adjacent on a triangular grid. Performing an action should provide the same outcome as rotating one's viewpoint 60 or 120 degrees (according to how the symmetries of a cell or vertex permit it), performing that action, and rotating that outcome back 60 or 120 degrees.

[rowett]

... the Draw menu will be wider for bigger screen sizes, allowing for more states to be seen. However, this is not true for maximized popups, even if they have the same size

Fixed in build 1359.

In oscillator period and frequency maps on bounded grids, the colour of the boundary appears to change depending on zoom level: if zoomed in enough such that the grid is visible, it uses the "bounded" colour, but when zoomed out beyond that point, it uses the "grid" colour.

Fixed in build 1359.

Unfortunately in this case we can't do any kind of shift, since such a grid definition is blocked, even though it would be useful in this case. Is this something that would be possible to support, or should we follow Golly's lead and continue to reject it in the interests of pattern compatibility?

The latter, plus square bounded grids aren't that helpful for non-square grids.

[muzik]

There appears to be an issue where the boundary cells change to the appearance of background cells if you zoom in while they're at the edge of the viewer. Try zooming in to about 44x, and you'll see the grey cells turn black (but mousing over them still says [boundary]):

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ GRID MAXGRIDSIZE 9 ZOOM 42 X -250 ]]

Here's a sort of opposite bug: in this case, the "boundary" cells do render, even though they shouldn't due to sharing the background colour, which causes issues (obscures starfield effect, makes it clear where the spaceship will get deleted, and the quantity of hexagons causes lag):

Code: Select all

x = 5, y = 5, rule = B2/S2H
o$2o$bo2$obobo!
[[ MAXGRIDSIZE 11 STARTFROM 1500 ZOOM 4 STARS COLOR BOUNDARY Black Y -1000 SHOWTIMING ]]

Note how this does not happen for an equivalent setup on the square grid:

Code: Select all

x = 3, y = 4, rule = B367/S23
bo$obo$3o$2o!
[[ MAXGRIDSIZE 11 ZOOM 4 STARTFROM 4000 STARS COLOR BOUNDARY Black Y -1000 ]]

In the Draw menu as well as Help > Info > Pattern, the rightmost column and bottom row of each icon is displayed as black. Would it not make more sense for the background colour to be used instead? (Also, this following rule defines two icons, one for state 1 and the other for state 2. The state 2 icon appears blank in the help section, but removing the second icon invalidates the first. I have no idea why.)

Code: Select all

x = 2, y = 2, rule = light-bg-icons
2A$2A!
[[ ZOOM 8 ICONS ]]
@RULE light-bg-icons
@TABLE
n_states:2
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 255 255 255
1 255 125 0
@ICONS
XPM
"7 14 2 1"
"A c #FFFFFF"
". c #000000"
"......."
"......."
"..AAA.."
"..AAA.."
"..AAA.."
"......."
"......."
"AAA.AAA"
"AAA.AAA"
"AAA.AAA"
"......."
"AAA.AAA"
"AAA.AAA"
"AAA.AAA"

Unfortunately in this case we can't do any kind of shift, since such a grid definition is blocked, even though it would be useful in this case. Is this something that would be possible to support, or should we follow Golly's lead and continue to reject it in the interests of pattern compatibility?

The latter, plus square bounded grids aren't that helpful for non-square grids.

An unbounded grid can be seen as a hexagon where two of the parallel edges (and their associated vertices) are at infinity, such that only one pair remains in bounds.

This may depend on display and will probably change a lot depending on zoom and camera position, but I've attempted to highlight an artifact on the triangular grid using annotations (see just below the zoom bar on the right) - note how, despite being an orthogonal line of cells, the bottom of the cells suddenly just downward at this position:

Code: Select all

x = 4, y = 2, rule = B123456789xyz/SL
b3o$b3o!
[[ ZOOM 4.6 THEME Red STARTFROM 64 POLYSHADOW OFF COLOR POLY Blue POLYLINE 13 -34 18 -34 18 -31 13 -31 13 -34 4 ]]

How it looks on my screen, in case it's different elsewhere:

triartifact.png (104.01 KiB) Viewed 1970 times

Thanks for the recent fixes, by the way! Still trying to find esoteric ways to break LifeViewer Pro but it's holding up quite well.

[rowett]

... this following rule defines two icons, one for state 1 and the other for state 2. The state 2 icon appears blank in the help section, but removing the second icon invalidates the first. I have no idea why.)

The rule only contains two states so the second icon should be silently ignored. I'll fix Help so it only displays number of states - 1 icons rather than number of icons decoded.

Thanks for the recent fixes, by the way! Still trying to find esoteric ways to break LifeViewer Pro but it's holding up quite well.

Thanks for the testing. Glad to hear LifeViewer Pro is surviving. I'll be promoting it to Beta in the not too distant future.

[muzik]

There appears to be a considerable lag spike when closing a memory-intensive popup then opening other patterns which are comparatively less demanding:

Code: Select all

# close this after it reaches T=6
x = 1, y = 1, rule = R50,C2,S0-7650,B1-7650,NH
o!
[[ SHOWTIMING EXTENDEDTIMING ZOOM 4 STARTFROM 6 POPUPWIDTH 1920 POPUPHEIGHT 1080 ]]

Code: Select all

# then open this
x = 1, y = 1, rule = B/S0123HT
o!

In the first pattern, also look at the Grid button: the lower white border appears to have gaps, possibly due to the grid icon rendering on top of it.

Also, here's a visual bug I've only managed to reproduce using Samsung Internet: there are visual artifacts that can be seen in small arrow annotations, particularly when zoomed in at level 32 or so. Moving the camera and changing the zoom level will cause these to morph and flicker. I haven't been able to reproduce this effect on other devices.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ GRID MAXGRIDSIZE 9 X 256 ARROW 255 -2 255 -1 32 ]]

Screenshot_20251120-153601_Samsung Internet.jpg (181.1 KiB) Viewed 1950 times

Screenshot_20251120-153619_Samsung Internet.jpg (163.17 KiB) Viewed 1950 times

Screenshot_20251120-153640_Samsung Internet.jpg (190.24 KiB) Viewed 1950 times

[muzik]

If you manually remove the highlighted seven cells by drawing or clearing a selection, many cells will visibly change from being hexagons to being offset rectangles. This obviously should not happen - history cells should remain the same shape if the zoom level remains the same and no relevant toggles are modified.

Code: Select all

x = 15, y = 23, rule = B2o3-o4-m56/S2m3o4-o56H
b2o$o3bo$b4o$2bobo$3b2o14$10b2o$10bobo$10b4o$10bo3bo$12b2o!
[[ THEME Red ZOOM 4.61 STARTFROM 225 POLYSHADOW OFF COLOR POLY Blue POLYLINE -10 -16 -3 -16 -0 -10 -7 -10 -10 -16 8 ]]

Selecting draw states no longer seems to be possible in [R]History:

Code: Select all

x = 12, y = 2, rule = LifeHistory
2A2B2C2D2E2F$2A2B2C2D2E2F!

Code: Select all

x = 12, y = 2, rule = LifeSuper
2A2B2C2D2E2F$2A2B2C2D2E2F!

Code: Select all

x = 12, y = 2, rule = LifeInvestigator
2A2B2C2D2E2F$2A2B2C2D2E2F!

A better test case for the "boundary cells become background cells" issue: pan to the left and you'll see the black cells turn grey as soon as they're fully on screen.

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ GRID MAXGRIDSIZE 9 X -252 ZOOM 64 ]]

This issue appears to have some height limits as well - move the camera downwards and you'll see the gray edge cells disappear:

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ GRID MAXGRIDSIZE 9 X -252 Y -125 ZOOM 64 ]]

For hexagonal oscillators, instead of using a rhombic shape for the period/frequency map, could a rectangular shape be used instead to make things overall more symmetric?

Code: Select all

x = 15, y = 23, rule = B2o3-o4-m56/S2m3o4-o56H
b2o$o3bo$b4o$2bobo$3b2o14$10b2o$10bobo$10b4o$10bo3bo$12b2o!
[[ POPUPHEIGHT 600 POPUPWIDTH 800 AUTOIDENTIFY ]]

Rhombic boundary (current):

Code: Select all

x = 39, y = 59, rule = B2o3-o4-m56/S2m3o4-o56HHistory
39F$F2.5B30.F$F3.4B30.F$F3.5B29.F$F3.2B2A2B28.F$F3.2B3A2B27.F$F2.4B2A
4B25.F$F2.11B24.F$F2.12B23.F$F.B.11B.B21.F$F18B19.F$F19B18.F$F20B17.F
$F.19B17.F$F.20B16.F$F2.19B16.F$F3.18B16.F$F3.19B15.F$F3.20B14.F$F4.19B
14.F$F5.18B14.F$F5.3BA11BA3B13.F$F5.2B2AB2A2B2A2B2AB2A2B12.F$F.4BABAB
3ABA3BAB3ABABA4B7.F$F6B2AB5A4B5AB2A6B5.F$F6BAB8AB8ABA6B4.F$F6BAB18ABA
6B3.F$F.7BAB15ABA7B3.F$F.7BABAB12ABABA7B2.F$F2.7B19A7B2.F$F2.7BABAB12A
BABA7B.F$F3.7BAB15ABA7B.F$F3.6BAB18ABA6BF$F4.6BAB8AB8ABA6BF$F5.6B2AB5A
4B5AB2A6BF$F7.4BABAB3ABA3BAB3ABABA4B.F$F12.2B2AB2A2B2A2B2AB2A2B5.F$F13.
3BA11BA3B5.F$F14.18B5.F$F14.19B4.F$F14.20B3.F$F15.19B3.F$F16.18B3.F$F
16.19B2.F$F16.20B.F$F17.19B.F$F17.20BF$F18.19BF$F19.18BF$F21.B.11B.B.
F$F23.12B2.F$F24.11B2.F$F25.4B2A4B2.F$F27.2B3A2B3.F$F28.2B2A2B3.F$F29.
5B3.F$F30.4B3.F$F30.5B2.F$39F!
[[ THEME Occupied SQUARECELLS STARTFROM 171 ZOOM 8 GRID ]]

Rectangular boundary (calculated as the axis aligned bounding box of the two acute vertices of the rhombus - result can be achieved by filling in the empty space at the bottom right and top left with a grid pattern):

Code: Select all

x = 97, y = 59, rule = B2o3-o4-m56/S2m3o4-o56HHistory
68F$.F30.5B30.F$.F31.4B31.F$2.F30.5B30.F$2.F30.2B2A2B30.F$3.F29.2B3A2B
29.F$3.F28.4B2A4B28.F$4.F27.11B27.F$4.F27.12B27.F$5.F25.B.11B.B25.F$5.
F24.18B24.F$6.F23.19B23.F$6.F23.20B23.F$7.F23.19B23.F$7.F23.20B23.F$8.
F23.19B23.F$8.F24.18B24.F$9.F23.19B23.F$9.F23.20B23.F$10.F23.19B23.F$
10.F24.18B24.F$11.F23.3BA11BA3B23.F$11.F23.2B2AB2A2B2A2B2AB2A2B23.F$12.
F18.4BABAB3ABA3BAB3ABABA4B18.F$12.F17.6B2AB5A4B5AB2A6B17.F$13.F16.6BA
B8AB8ABA6B16.F$13.F16.6BAB18ABA6B16.F$14.F16.7BAB15ABA7B16.F$14.F16.7B
ABAB12ABABA7B16.F$15.F16.7B19A7B16.F$15.F16.7BABAB12ABABA7B16.F$16.F16.
7BAB15ABA7B16.F$16.F16.6BAB18ABA6B16.F$17.F16.6BAB8AB8ABA6B16.F$17.F17.
6B2AB5A4B5AB2A6B17.F$18.F18.4BABAB3ABA3BAB3ABABA4B18.F$18.F23.2B2AB2A
2B2A2B2AB2A2B23.F$19.F23.3BA11BA3B23.F$19.F24.18B24.F$20.F23.19B23.F$
20.F23.20B23.F$21.F23.19B23.F$21.F24.18B24.F$22.F23.19B23.F$22.F23.20B
23.F$23.F23.19B23.F$23.F23.20B23.F$24.F23.19B23.F$24.F24.18B24.F$25.F
25.B.11B.B25.F$25.F27.12B27.F$26.F27.11B27.F$26.F28.4B2A4B28.F$27.F29.
2B3A2B29.F$27.F30.2B2A2B30.F$28.F30.5B30.F$28.F31.4B31.F$29.F30.5B30.
F$29.68F!
[[ THEME Occupied SQUARECELLS STARTFROM 171 ZOOM 8 GRID ]]

Glad to hear LifeViewer Pro is surviving. I'll be promoting it to Beta in the not too distant future.

When will a build be deployed to the forums? If that happens it should be easy for me to go through the history of this thread to see if anything acts weird.

On reflection the triangular grid drawing is correct. The triangular grid can be replaced by a rectangular grid (unlike the hexagonal grid which is replaced by an offset square grid). So the drawing should be the same as for the square grid. If you join up all the triangles via edges (rather than vertices) you are creating unneeded extra cells.

I had another thought: what if the drawing logic used depended on what grid was active? If "Use Rectangles" is on, it would behave as it currently does, using square-grid connection logic, since that lines up with what you see. If turned off (i.e. triangles are in use), the drawing would be changed such that it acts the way you'd expect it to for triangles: lines would be continuous and connected edge-to-edge.

[rowett]

Selecting draw states no longer seems to be possible in [R]History:

Fixed in build 1360.

For hexagonal oscillators, instead of using a rhombic shape for the period/frequency map, could a rectangular shape be used instead to make things overall more symmetric?

I prefer the rhombic shape.

When will a build be deployed to the forums? If that happens it should be easy for me to go through the history of this thread to see if anything acts weird.

During the Beta phase.

[muzik]

For a third type of oscillator map, how about implementing heat maps? Every pixel is colored depending on how many times the corresponding cell changed state in the oscillator's evolutionary cycle (for 2-state rules this value will always be even). Here's a statorless p13:

Code: Select all

x = 30, y = 30, rule = B3/S23
9b2o8bobo$8b3o8bobo$19bobo$7bo2bo9bo$8bobo10b2o$8bo11bo2$3bo6bo7b3o4bo$bo2b2o
3b3o2b2o2bo6bob3o$2o6bobo3b2o2bo3bobobo$2ob2o2b3o12bo4b3o$8bo11b3o3$8b2o10b2o
$8b2o10b2o3$7b3o11bo$3o4bo12b3o2b2ob2o$3bobobo3bo2b2o3bobo6b2o$3obo6bo2b2o2b
3o3b2o2bo$4bo4b3o7bo6bo2$9bo11bo$7b2o10bobo$9bo9bo2bo$8bobo$8bobo8b3o$8bobo8b
2o!

Here is the corresponding map of this p13:

Code: Select all

# 184 x 2, 192 x 4, 40 x 6, 24 x 8
x = 32, y = 32, rule = //5
11.B8.B$9.AC2B6.2BCA$8.A4B6.4BA$8.AD2BA6.A2BDA$8.2BC2BA4.A2BC2B$8.2B2D
2A4.2A2D2B$8.ABC2BA4.A2BCBA$8.3ACBA4.ABC3A$2.2A2B2A2.2BCA.2A.AC2B2.2A
2B2A$.ABD3BA2.A2B6A2BA2.A3BDBA$.C2BCDCABA.AB.4A.BA.ABACDC2BC$5BDBC2BA
4.2A4.A2BCBD5B$.2BABA2BC2B10.2BC2BABA2B$4.6A12.6A$9.2A10.2A$8.4A8.4A$
8.4A8.4A$9.2A10.2A$4.6A12.6A$.2BABA2BC2B10.2BC2BABA2B$5BDBC2BA4.2A4.A
2BCBD5B$.C2BCDCABA.AB.4A.BA.ABACDC2BC$.ABD3BA2.A2B6A2BA2.A3BDBA$2.2A2B
2A2.2BCA.2A.AC2B2.2A2B2A$8.3ACBA4.ABC3A$8.ABC2BA4.A2BCBA$8.2B2D2A4.2A
2D2B$8.2BC2BA4.A2BC2B$8.AD2BA6.A2BDA$8.A4B6.4BA$9.AC2B6.2BCA$11.B8.B!
[[ COLOR 1 #66FFFF COLOR 2 #66FF66 COLOR 3 #FFFF66 COLOR 4 #FF6666 GRID GRIDMAJOR 0 ZOOM 8 VIEWONLY
COLOR LABEL #66FFFF LABEL -6 9 8 "█ 2"
COLOR LABEL #66FF66 LABEL -6 13 8 "█ 4"
COLOR LABEL #FFFF66 LABEL -6 17 8 "█ 6" 
COLOR LABEL #FF6666 LABEL -6 21 8 "█ 8" ]]

For 2-state rules there will be no more than p/2 colours for an oscillator of period p (compared to a frequency map, which has at most p or p+1 colours depending on whether 0 is counted), so these should be overall less complex.

If of any use, here is the commit that implemented heat maps in Oscilloscope: https://github.com/rei1024/oscilloscope ... 99bfa2b942

----

In the draw menu, would it be possible for icons to be displayed to the right of their colours instead of the left, as well as always be displayed if the rule has icons (rather than only when icons are toggled on)? This would make things more like Golly's draw interface:

Code: Select all

x = 2, y = 2, rule = JvN29
MP$NO!
[[ ICONS ]]

image.png (7.82 KiB) Viewed 1888 times

Some icons in the Draw menu as well as in Help > Info > Pattern can visually intrude on the dark border space to the right and bottom of the squares in which they're displayed (note the stray whitish pixels):

Code: Select all

x = 1, y = 1, rule = sphere
o!
[[ ICONS ]]
@RULE sphere

Override the default colors and icons for Life (B3/S23).

@TABLE
n_states:2
neighborhood:Moore
symmetries:none
# do nothing

@COLORS

0 255 255 255   white (matches icon background below)
1 54 54 194     dark blue (average color of icon below)

@ICONS

XPM
/* width height num_colors chars_per_pixel */
"31 31 78 2"
/* colors */
".. c #FFFFFF"   white background
"BA c #CECEDE"
"CA c #7B7BAD"
"DA c #4A4A84"
"EA c #18187B"
"FA c #08006B"
"GA c #18186B"
"HA c #29297B"
"IA c #6B6BAD"
"JA c #ADADDE"
"KA c #EFF7FF"
"LA c #ADADC6"
"MA c #39398C"
"NA c #3939BD"
"OA c #7B7BCE"
"PA c #ADB5DE"
"AB c #8C8CD6"
"BB c #4A4A9C"
"CB c #18188C"
"DB c #EFEFEF"
"EB c #EFEFFF"
"FB c #525A9C"
"GB c #08088C"
"HB c #ADADE7"
"IB c #DEDEEF"
"JB c #D6D6F7"
"KB c #DEE7F7"
"LB c #BDBDEF"
"MB c #525ABD"
"NB c #21219C"
"OB c #292984"
"PB c #CECEE7"
"AC c #ADB5CE"
"BC c #2929BD"
"CC c #7B7BDE"
"DC c #BDC6E7"
"EC c #CECEF7"
"FC c #8C8CE7"
"GC c #4242C6"
"HC c #A5A5BD"
"IC c #08087B"
"JC c #3939CE"
"KC c #5A5AC6"
"LC c #BDBDF7"
"MC c #BDBDDE"
"NC c #6B6BD6"
"OC c #9494DE"
"PC c #3931DE"
"AD c #1818AD"
"BD c #2929CE"
"CD c #9C9CC6"
"DD c #10087B"
"ED c #9C9CBD"
"FD c #1818B5"
"GD c #1818C6"
"HD c #847BCE"
"ID c #181094"
"JD c #6B6BCE"
"KD c #7B7BB5"
"LD c #2121AD"
"MD c #BDC6D6"
"ND c #0808AD"
"OD c #4A42B5"
"PD c #00009C"
"AE c #3942BD"
"BE c #3129B5"
"CE c #B5B5CE"
"DE c #0000BD"
"EE c #0000CE"
"FE c #0000DE"
"GE c #42427B"
"HE c #C6CECE"
"IE c #0000EF"
"JE c #9494AD"
"KE c #F7FFEF"
"LE c #10086B"
"ME c #7B849C"
"NE c #0000F7"
/* icon for state 1 */
".............................................................."
".............................................................."
"......................BACADAEAFAGAHAIAJA......................"
"................KALAMAFANAOAJAPAJAABBBCBEAIADB................"
"..............EBFBGBNAHBIBDBJBKAKBEBJBLBMBNBOBPB.............."
"............ACHABCCCDCECIBPBJBPBIBPBJBIBECFCGCCBCAKA.........."
"..........HCICJCKCLBLCLBMCLBLBLBLBMCLBLBMCLCNCJCCBCAKA........"
"........DBOBBCJCCCJAJAJAJAJAJAJAJAJAJAJAJAJAOCJCPCICAC........"
"......KADAADBDBCABABOCABOCOCOCOCABOCABOCABCDFCJCBDBCDDBA......"
"......EDGBFDGDADCCABOAOAOAOAOAOAOAOAHDOAHDCCCCNAADGDIDMA......"
"....KAHAADFDFDADJDMBOAJDJDJDJDJDKDJDJDJDJDJDJDLDFDFDFDICBA...."
"....MDFANDNDNDADODMBMBMBMBMBMBMBKCKCMBMBMBMBODADNDNDNDGBIA...."
"....CAGBNDPDNDPDADGCODODODODODODNAODODGCODAEBCPDNDPDNDPDGA...."
"....OBPDPDNDPDNDNDADBCBEBCBEBCBCBEBCBCBCNAADPDNDNDPDPDNDICPB.."
"....ICNDNDPDNDNDNDPDNDADADADADADADADADADNDNDNDNDNDNDNDPDGBCE.."
"....FANDNDDENDNDNDDENDDENDNDNDNDNDNDNDNDNDNDNDNDNDNDNDNDGBLA.."
"....FANDDENDDEDENDDEDENDDENDDEDEDEDEDEDEDEDEDEDEDENDDEDEGBED.."
"....GANDEEDEDEDEDEDEDEDEDEDEDEDENDDENDDEDEDEDEDEDEDEDEDEGBLA.."
"....BBPDEEDEEEDEEEDEEEDEEEDEDEDEEEDEEEDEDEDEDEDEEEDEEEDEFABA.."
"....EDGBDEEEDEEEEEEEDEEEDEEEEEEEEEEEEEEEEEEEEEEEEEDEEENDGADB.."
"....KBICDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEGBDA...."
"......FBNDFEFEEEEEEEEEFEEEEEFEEEEEEEEEEEEEEEEEEEEEFEDEICHC...."
"......IBEADEFEFEEEFEFEFEFEFEEEFEFEFEFEFEFEFEFEFEFEDEGBGEDB...."
"........LAGBFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFENDGAHE......"
"..........FBNDFEFEIEFEFEIEIEIEFEIEFEFEIEFEFEFEFEEEDDJEKE......"
"..........EBFBIDEEIEIEIEFEFEFEIEFEIEIEIEIEIEIENDLEMEKE........"
"..............CDGBDEIEIENENEIEIEIEIEIEIEIEGDPDGAJEKE.........."
"................BAOBGBADFEIENEIENEIEIEEENDFAGECEKE............"
"....................CDBBDDPDIDNDADPDICEAGEJEDB................"
"........................EBBALAEDEDHCMCDBKE...................."
".............................................................."

Is it intended that "Last Delete" persists into future viewer popups, or should it be reset upon opening a subsequent viewer?

The top boundary and bottom boundary appear to "flicker" slightly between two different thicknesses as the shape grows. The top-left and bottom-right boundaries stay somewhat constant by comparison. I don't know if a similar visual result to this is achievable for the top and bottom boundaries.

Code: Select all

x = 1, y = 1, rule = /123456/3H
A!
[[ AUTOSTART ZOOM -4.0 ]]

In this, the left and right boundaries appear discontinuous (in terms of the alive cells) when zoomed out even though zooming in shows that they are indeed continuous. Is this fixable somehow?

Code: Select all

x = 1, y = 1, rule = /1234/3V
o!
[[ STARTFROM 512 ZOOM -4 ANGLE 45 ]]

Is this post supposed to contain a functional paste command? If so, it doesn't appear to work (however the post quoting it does work).

How is cell shader selection supposed to work? This uses Mono, which implies the Basic shader gets used, but if we look at Settings > Display, "Age" is selected, rather than "Bas", which I'm not sure is right:

Code: Select all

x = 1, y = 1, rule = B1c2c3e4r5i/S01c3i
o!
[[ STARTFROM 128 ZOOM 2 THEME Mono ]]

These six setups should be rotationally equivalent to each other, however only the first and fourth of these six work as expected: (also, pausing these will cause the history trail to disappear as mentioned earlier)

Code: Select all

# intersection of alive cells is mirror-symmetric, history trails overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 2 0 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 2 0 PASTE o! 1 0
]]

Code: Select all

# intersection of alive cells is not mirror-symmetric, history trails do not overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 1 PASTE o! 1 0
]]

Code: Select all

# intersection of alive cells is not mirror-symmetric, history trails do not overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 1 PASTE o! -1 0
]]

Code: Select all

# intersection of alive cells is mirror-symmetric, history trails overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -2 0 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -2 0 PASTE o! -1 0
]]

Code: Select all

# intersection of alive cells is not mirror-symmetric, history trails do not overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 -1 PASTE o! 0 -1
]]

Code: Select all

# intersection of alive cells is not mirror-symmetric, history trails do not overlap perfectly
x = 1, y = 1, rule = B/SL
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 -1 PASTE o! 0 -1
]]

Equivalent hexagonal patterns that move diagonally, all of which seem to work correctly unlike the second, third, fifth and sixth orthogonal triangular demonstrations (the overlap is mirror symmetric):

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 -2 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 -2 PASTE o! -1 -1
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 -1 PASTE o! 1 0
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 2 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 2 1 PASTE o! 1 0
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 2 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 2 PASTE o! 1 1
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 1 PASTE o! -1 0
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -2 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -2 -1 PASTE o! -1 0
]]

The four diagonal directions on a square grid also work as expected, producing a mirror-symmetric effect:

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 -1 PASTE o! 0 -1
]]

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA 1 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA 1 1 PASTE o! 1 0
]]

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 1 PASTE o! 0 1
]]

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ AUTOSTART AUTOFIT
PASTET EVERY 2 0 PASTEDELTA -1 -1 PASTE o! 0 0
PASTET EVERY 2 1 PASTEDELTA -1 -1 PASTE o! -1 0
]]

At T=1, a population of 0 is displayed, despite there being one alive cell clearly present. All subsequent generations appear correctly.

Code: Select all

x = 1, y = 1, rule = M0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
!
[[ MAXGRIDSIZE 9 SHOWGENSTATS PASTET EVERY 1 PASTEDELTA 0 1 PASTE o! 255 -256 GPS 1 ]]

I am not sure if the top-left and bottom-right boundary cells should be present in the period/frequency map:

Code: Select all

x = 1, y = 1, rule = B/SHInvestigator:P1,1
J!
[[ AUTOIDENTIFY ]]

[muzik]

Rulestring validation for higher-range outer-totalistic rules appears to not reject large values if valid counts are placed after them (they appear to get converted to the maximum value instead):

Code: Select all

x = 2, y = 2, rule = R1,C2,S2147483648,1,B2147483648,1
2o$2o!
[[ SHOWGENSTATS ]]

Compare:

Code: Select all

# rearranging counts to being in ascending order produces an error, which you'd expect from the top as well
x = 2, y = 2, rule = R1,C2,S1,2147483648,B1,2147483648
2o$2o!

Code: Select all

x = 2, y = 2, rule = R1,C2,S1,B1,2147483648
2o$2o!

Code: Select all

x = 2, y = 2, rule = R1,C2,S1,2147483648,B1
2o$2o!

von Neumann-neighbourhood patterns seem to get boundary-killed a lot sooner than they should, particularly on the Y-axis. In the range-1 example, we also can see that there are many history cells that don't fade with time for some reason. Things get extremely strange if we run these in LifeViewer Pro, which causes what looks almost like a torrent of garbage data to manifest in cellular form and descend upon the pattern from the top of the grid:

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,2,4,B1,3,NN
o!
[[ MAXGRIDSIZE 9 ZOOM -1 AUTOSTART ]]

Code: Select all

x = 1, y = 1, rule = R2,C2,S0,2,4,6,8,10,12,B1,3,5,7,9,11,NN
o!
[[ MAXGRIDSIZE 9 ZOOM -1 AUTOSTART ]]

The Moore neighbourhood, and all other neighbourhoods I've tested this with so far, do not behave in this way at all.

Code: Select all

x = 1, y = 1, rule = R2,C2,S0,2,4,6,8,10,12,14,16,18,20,22,24,B1,3,5,7,9,11,13,15,17,19,21,23,NM
o!
[[ MAXGRIDSIZE 9 ZOOM -1 AUTOSTART ]]

Higher von Neumann ranges appear to be subject to some bugs other neighbourhood types simply do not have. Try manually selecting the entire 512x512 grid, using Invert Selection (or Random Fill) and note the overall shape of the modified region - it is not what you'd actually expect (compare this to Moore or any other neighbourhood):

Code: Select all

x = 1, y = 1, rule = R2,C2,S0,2,4,6,8,10,12,B1,3,5,7,9,11,NN
!
[[ MAXGRIDSIZE 9 ZOOM -1 ]]

I've also managed to somewhat unreliably crash LifeViewer doing things like this and playing the result, presumably due to things getting too close to the grid edge. I wonder if it'd be possible at all to figure out what causes these crashes in the first place and stop them, rather than restricting the area in which things can be drawn/pasted/etc.

In LifeViewer Pro specifically, this pattern is completely impossible to modify by means of drawing or selections:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B,NN
!
[[ MAXGRIDSIZE 9 ZOOM -1 PASTET EVERY 1 PASTEDELTA 0 1 PASTE 512o! -256 -256 STARTFROM 512 THEME Occupied ]]

Manually pan the camera up or down here and you'll notice a harsh horizontal boundary. I have a strong suspicion that the "offset rectangle" and "hexagonal" grids are actually being drawn on top of each other here, which should not be the case. Note how zooming in just slightly beyond this level results in much cleaner looking hexagons.

Code: Select all

x = 1, y = 1, rule = B135/S0246H
!
[[ GRID ZOOM 4.61 ]]

hexgridsoddity.png (168.12 KiB) Viewed 1850 times

The layout of the Help menu does not appear to check if annotations are defined, since if they are the help buttons will intersect the other buttons at the bottom as well as the credits text at the top. Would it be a good idea to have "Annotations" always be present, but gray and disabled if none are defined, so the layout remains consistent regardless of what is defined in script commands, and so we don't have two distinct button layouts to keep track of here?

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ POPUPHEIGHT 400 ]]

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ POPUPHEIGHT 400 LABEL 0 0 32 "look in the Help menu" ]]

Use Select All on this pattern without moving the camera or changing the zoom level. There is a one-pixel (not cell, but screen pixel) gap between the green selection rectangle and the right edge of the bounded grid, as well as with it and the bottom edge of the bounded grid. This should not be the case - the selection should be completely flush with both faces with no gaps. If we cut and paste, and arrange the paste rectangle in that same position, we see the same effect.

Code: Select all

x = 20, y = 20, rule = B3/S23:T20,20
10$10bo9$19bo!
[[ ZOOM 22 ]]

Are there ways to detect periodicity sooner for some objects? In this RRO's case identification takes 3043 generations, despite it being p1744 (we almost do a whole second period cycle), so it seems like we could save a lot of time for objects with periods higher than this:

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!
[[ ZOOM -3 X -500 Y 300 ]]

Even more investigation into that "boundary cells disappear on the left hand side of the window" bug: it turns out that the contents of the leftmost in-bounds column are actually visually cloned over the first out-of-bounds column. This pre-beehive on the edge of your screen is actually just a block if you move over to investigate it:

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ GRID MAXGRIDSIZE 9 X -247 PASTE 2o$2o! -256 -1 ]]

Decided to double-check the prior "compilation" posts I made. A lot of those mentioned are now fixed - here's the remaining issues that still affect build 1360 (more for personal quick reference than anything):

Reiterating some other recent reports:

Code: Select all

#C changing the theme will not adjust TRACKLOOP length, causing visual grid jumping
x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ AUTOSTART THEME Margolus GRID TRACKLOOP 4 -1/4 1/4 GPS 5 ]]

Code: Select all

#C Basic shader is not used, despite BACKGROUND = DEAD = DEADRAMP and AGESTATES 0
x = 1, y = 1, rule = W4
o!
[[ COLOR DEAD Black COLOR DEADRAMP Black AGESTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

#C AUTOFIT will focus on living cells during playback, but zoom out to fit history cells when paused
x = 3, y = 4, rule = /2/3
BA$.BA$.BA$BA!
[[ AUTOFIT AUTOSTART STOP 100 ]]

Code: Select all

#C Select All works as expected, but Shrink Selection proceeds to exclude two cells
x = 3, y = 4, rule = R1,C3,S,B2
BA$.BA$.BA$BA!
[[ MAXGRIDSIZE 9 STARTFROM 253 X 255 PASTET 253 PASTE o! 250 -2 ]]

Some previously reported issues from around September (every time I go back to page 169 the autoidentify example freezes the page for several seconds, which makes reproducing these annoying):

Code: Select all

# zooming out will reveal more history cells that aren't initially shown
x = 1, y = 1, rule = B/SL
!
[[ PASTEMODE XOR AUTOSTART GPS 16 ZOOM 4
PASTET EVERY 4 0 PASTEDELTA 2 0 PASTE o! 0 0 PASTE o! 0 0
PASTET EVERY 4 1 PASTEDELTA 2 0 PASTE o! 0 1 PASTE o! 0 1
PASTET EVERY 4 2 PASTEDELTA 2 0 PASTE o! 1 1 PASTE o! 1 1
PASTET EVERY 4 3 PASTEDELTA 2 0 PASTE o! 1 0 PASTE o! 1 0
]]

Code: Select all

# cells modified by PASTE or KILLGLIDERS will defy HISTORYFIT
x = 125, y = 9, rule = B3/S23
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -21 1 ]]

Code: Select all

# this spaceship is impossible to Identify
x = 1, y = 1, rule = M0,4,1,0,1,0,0,0,8,0,0,0,0,0,0,0
o!
[[ AUTOIDENTIFY ]]

Code: Select all

# KILLGLIDERS doesn't get these
x = 116, y = 90, rule = B3/S23
113b2o$113bobo$113bo5$80b2o$79b2o$81bo71$34bo$33b2o$33bobo5$2o$obo$o!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

Code: Select all

# ...or these
x = 116, y = 132, rule = B2i3-cky4e5c6n7c/S2-n3-ce4cy5jkr6ik
114b2o$113b2o$115bo41$67b2o$66b2o$68bo19$4bo$3b2o$3bobo63$b2o$2o$2bo!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

Code: Select all

# ...or these
x = 6, y = 7, rule = B3/S23
2o$obo$o2$3b2o$3bobo$3bo!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

A compilation of some other reports from around September, alongside some from earlier in the year:

Code: Select all

# some signed 32-bit values overflow, even though others are correctly handled
x = 3, y = 3, rule = B3/S23
o$o$3o!
[[ STARTFROM 5000000000 HISTORYSTATES 5000000000 ]]

Code: Select all

# in range-1 rules bounded grid sizes 16353 to 16379 do not display SHOW PATTERN ERROR despite being invalid
x = 3, y = 3, rule = B3/S23:P16379
o$obo$2o!
[[ MAXGRIDSIZE 14 ]]

Code: Select all

# you cannot draw here until you click near the very left and drag it rightward
x = 2, y = 16, rule = B3/S23:T0,32
2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o!
[[ GRID ZOOM 16 X 272 ]]

Code: Select all

# no error is produced here, despite "COLOR dead" not being valid for [R]Super even if it is valid for other rules
x = 5, y = 4, rule = B3/S23Super
.A2.A$A$A3.A$4A!
[[ COLOR dead 255 255 255 ]]

Code: Select all

# pausing this will zoom in on alive cells, disregarding HISTORYFIT
x = 4, y = 3, rule = B367/S2-i34q
3o$2obo$b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT ]]

Code: Select all

# oblique spaceships can have a mod identified as lower than their period, which should never be possible
x = 6, y = 6, rule = R3,C2,S5-7,B5-7,NW0000000002020200000000020102000000000202020000000
6o$6o$2o$2o$2b2o$2b2o!
[[ AUTOIDENTIFY ]]

Code: Select all

# set "Refresh Rate" to 144 and this will get jittery (you do not need a 144hz monitor to see this effect)
x = 1, y = 1, rule = B3/S23
b!
[[ PASTEDELTA 1 1 PASTET EVERY 1 PASTE bo$2o! 0 0 TRACK 1 1 ]]

Code: Select all

# changing Theme in-viewer will not change TRACKLOOP's duration and the major grid lines will visibly jump
x = 6, y = 6, rule = MAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////w
o$bo3bo$2bo2bo$3bobo$4bo$b3o!
[[ TRACKLOOP 3 1 1 GRID THEME Margolus AUTOSTART GPS 2 ]]

[muzik]

AutoFit centers the camera in [R]History differently from how it does so for [R]Standard and [R]Super for this same setup:

Code: Select all

x = 5, y = 3, rule = B3/S23
b3o$o3bo$2ob2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 2 -1 AUTOSTART AUTOFIT ]]

Code: Select all

x = 5, y = 3, rule = B3/S23History
b3o$o3bo$2ob2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 2 -1 AUTOSTART AUTOFIT ]]

Code: Select all

x = 5, y = 3, rule = B3/S23Super
b3o$o3bo$2ob2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 2 -1 AUTOSTART AUTOFIT ]]

For some reason, state 1's icon in the Langtons-Ant rule appears to be invisible now:

Code: Select all

x = 5, y = 6, rule = Langtons-Ant
2.2A$.A.H$A3.A$A3.A$.F.A$.2A!
[[ ICONS ZOOM 32 ]]

For oscillator and spaceship bounding boxes: would it be possible to display all three on the main results table, rather than only one and having the other two only accessible from the help menu? Since there's no agreed-upon standard for what constitutes a spaceship's bounding box I don't think it's a good idea to only provide one value unless community consensus dictates that one should take precedence over the others.

Code: Select all

x = 5, y = 5, rule = R2,C2,S,B4
3bo$3bo$2bobo$2o2bo$3bo!
[[ AUTOIDENTIFY ]]

Something bizarre appears to be going on here: both the offset rectangle and true hexagonal grids appear to be in use at the same time?

Fixed in build 1355.

Not entirely - if you make a selection anywhere in the field of empty cells, then use the button to clear the inside of the selection, then despite this not changing any cells on the board, things will visibly change to the offset rectangle grid, and continuing playback will cause it to morph back into the hexagon grid as the bounding rhombus expands:

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM 4.61 STARTFROM 255 X 96 Y -96 GRID ]]

To reduce confusion: if a weighted rule defines negative weights, can those actually be displayed as negative numbers in Help > Info > Pattern, rather than the positive values defined in the rulestring? There have been multiple cases (especially for the 0-15 system) where defining values 8, 9, ... didn't actually function as 8 or 9, but rather as negative values (as the format defines it), resulting in confused posts in this thread and elsewhere.

Code: Select all

x = 5, y = 9, rule = R2,C2,S2-3,B3,NW1191111111910191111111911
2bobo2$4bo4$o2$obo!

Would it be possible to make the left, right, bottom-left and top-right edges of this hexagon less rough when doing zoomed-out sampling like this, such that we get a result more akin to the top-left and bottom-right edges?

Code: Select all

x = 3, y = 3, rule = 2om3o/2o3o/5H
2A$A.A$.2A!
[[ STARTFROM 1024 ZOOM -4 ]]

More messing with the NN bugginess - this loses bilateral symmetry in Pro, but not in Standard (I also don't know where the white cells come from in Pro since it's not part of the active theme at all):

Code: Select all

x = 2, y = 2, rule = R2,C3,S,B1-2,NN
2A$2A!
[[ MAXGRIDSIZE 9 ZOOM -1 AUTOSTART ]]

[b-engine]

Could a "Heat" cell shader being added?
Basically, cells are colored based on how much state changes they undergone.
Cells that changes state for one generation have their "heat" increased by 1.
Cells that retains state for one generation have their "heat" decreased by 1.

[muzik]

This behaves incorrectly in LifeViewer Pro (also compare to Golly):

Code: Select all

x = 2, y = 2, rule = TimeTun:T32
2A$2A!

The first pattern correctly zooms out to show all history cells, as HISTORYFIT is supposed to; the second incorrectly shifts the camera over, not accounting for the prior history cells.

Code: Select all

x = 7, y = 9, rule = B3/S23
2bo$obo$b2o5$5b2o$5b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTET 100 PASTE 4bo$4bobo$4b2o5$2o$2o! 50 0 ]]

Code: Select all

x = 7, y = 9, rule = R1,C2,S2-3,B3
2bo$obo$b2o5$5b2o$5b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTET 100 PASTE 4bo$4bobo$4b2o5$2o$2o! 50 0 ]]

Icon previews in the draw menu appear to stick out at the top and bottom more than the cell colour preview does, which I don't like the look of (also notice how the ant in the icon previews for states 7 and 8 have black antennae and 6 and 9 a black rear, which is not how the icons actually look as they exist within a pattern):

Code: Select all

x = 5, y = 6, rule = Langtons-Ant
.2A$.H.A$A3.A$A3.A$.A.F$2.2A!
[[ ICONS POPUPWIDTH 800 ]]

IMG_2799.jpeg (52.21 KiB) Viewed 1763 times

Is it possible to detect if every cell in a bounded grid becomes alive in a rule with Smax, and then pause automatically and announce the generation? These two patterns are behaviourally identical and I think they should be treated as such:

Code: Select all

x = 30, y = 30, rule = B123478/S01234678:S30
30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o$30o
$30o$30o$30o$30o$30o$30o$30o$30o$26o2b2o$26obobo$26ob3o$30o!

Code: Select all

x = 30, y = 30, rule = B3/S238:S30
26$26b2o$26bobo$26bo!

Is there an official archive of previous versions of LifeViewer Pro anywhere?

[muzik]

Triangular cells appear to be one to two pixels taller than their corresponding rectangular cells. Here's an interactive test case demonstrating this - follow the instructions and you'll see the strip of green at the bottom appear and disappear accordingly, which should not happen. The bottom face of upward-pointing triangles does not appear to be affected.

Code: Select all

x = 22, y = 1, rule = B/S0123LE
b21o!
[[ POPUPWIDTH 600 POPUPHEIGHT 560 ZOOM 32 Y -5.775 AUTOSTART AUTOHIDEGUI THEME LifeHistory LABEL 12 -6.5 32 "Use Shift+/ and observe the bottom of this popup" ]]

A similar issue affects hexagonal cells on their right edges, but not their left. This test case is much more subtle, but still noticeable:

Code: Select all

x = 9, y = 17, rule = B/S0123HT
o2$bo2$2bo2$3bo2$4bo2$5bo2$6bo2$7bo2$8bo2$9bo2$10bo!
[[ POPUPWIDTH 600 POPUPHEIGHT 560 ZOOM 32 X 9.63 AUTOSTART AUTOHIDEGUI THEME LifeHistory LABEL 13.5 8 32 "Use Shift+/ and observe the left of this popup" ]]

There are also visible "bumps" on some triangle strips. I don't know if this is due to the vertices of other triangles poking through, or a natural consequence of scaling a line that isn't orthogonal or diagonal according to the screen pixels.

Code: Select all

x = 47, y = 24, rule = B/S0123LE
11b25o$10b2o23b2o$9b2o25b2o$8b2o27b2o$7b2o29b2o$6b2o31b2o$5b2o33b2o$4b
2o35b2o$3b2o37b2o$2b2o39b2o$b2o41b2o$2o20b3o20b2o$2o20b3o20b2o$b2o41b
2o$2b2o39b2o$3b2o37b2o$4b2o35b2o$5b2o33b2o$6b2o31b2o$7b2o29b2o$8b2o27b
2o$9b2o25b2o$10b2o23b2o$11b25o!
[[ ZOOM 8.5 ARROW -1 7 2 8 8 ARROW 1 5 4 6 8 ARROW 3 3 6 4 8 ARROW 5 1 8 2 8 ]]

Now that we mark off-deathforcer cells as "Off DF", could [R]Investigator maps also mark on-deathforcer maps as "On DF"? Here's two example patterns:

Code: Select all

# Identify should show 6 On DF cells
x = 11, y = 5, rule = B3/S23Investigator
9.2B$9.A$2A$A$.AB.ABA.A2B!

Code: Select all

# Identify should show 13 Off DF cells
x = 19, y = 17, rule = B3/S23Investigator
2A13.C$A16.A$2.C13.2A$18.C$9.3A$2.C6.A.A3.C$9.3A5.2C$18.A$17.2A$17.A$
9.3A5.2C$2.C6.A.A3.C$9.3A$18.C$16.2A$16.A$18.C!

At some height specifications the cell period/frequency table will be completely unable to display any contents, and will only show the header. In cases like these, we still have ample room above the Oscillator period N header such that the table could be moved upwards and display at least some content (even when Draw or Select are in use).

Code: Select all

# press E - no table contents
x = 3, y = 1, rule = B3/S23
3o!
[[ HEIGHT 274 AUTOIDENTIFY ]]

Code: Select all

# press E - one item in table
x = 3, y = 1, rule = B3/S23
3o!
[[ HEIGHT 275 AUTOIDENTIFY ]]

Code: Select all

# popup reproduction case: zoom your browser in to around 180%
x = 3, y = 1, rule = B3/S23
3o!
[[ POPUPHEIGHT 250 AUTOIDENTIFY ]]

Another seemingly Samsung Internet-only issue: when selecting a region in a hexagonal rule, the right hand side of the selection region is peppered with tiny holes.

Screenshot_20251124-161202_Samsung Internet.jpg (180.47 KiB) Viewed 1696 times

Screenshot_20251124-161218_Samsung Internet.jpg (164.05 KiB) Viewed 1696 times

Can confirm that build 1261 fixes the aforementioned rule table issue (though it only appears to have been released for Pro and not Standard and isn't mentioned in any changelog).

[muzik]

As of today it's now been nine months since the pull request for updated period map colors was originally created. It's been updated to build 1357 and I can confirm that everything still appears to be functioning as intended, so merging this in its current state shouldn't cause any problems.

To make testing easier (as well as allow anyone interested to see the changes without having to compile anything manually) I've hosted a test case here: https://muzikbike.github.io/tests/lifev ... iewer.html

Changes made are as follows:
- Only period maps are changed by this. Frequency maps will continue to use their generated set of colours.
- The highest subperiod colour is still white, background cells are still black, and stator cells are still gray.
- For period maps, the 20 highest subperiods will pick from a set of constant colours. The highest subperiod will always have the same colour (#1C92CD), the second highest will also be the same (#0AB87B), and so on up until the 20th. This way, across different maps, it's easy to see a colour and instinctively learn that this is the nth highest subperiod.
- For subperiods beyond the 20th, colours are still generated as previously. If an oscillator has 27 subperiods (not counting stator cells), the 20 constant colours will be used, and 21 to 27 will be generated, producing the same colours as an oscillator with 7 subperiods in the current system.
- I've used Nakano's colours (besides the gray, since I don't want to cause confusion with stator cells, off-deathforcers, and so on), followed by Oscillizer's colours, as to hopefully create something of a "standard" colour set across oscillator mapping tools.

Here's how the example oscillator provided on the page looks:

updated-cellmap.png (7.47 KiB) Viewed 1667 times

The current cell map colouring system, for comparison (note how the colours at the apex are hardest to distinguish):

current-cellmap.png (7.65 KiB) Viewed 1667 times

Feel free to check how other oscillators look with these changes - the contrast is improved in almost all cases I've checked so far.