Pattern viewer for forum threads

[rowett]

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?

Settings->Advanced->Snap Angle

[muzik]

The T menu doesn't freeze on the last nonzero statistics for RSuper:

Code: Select all

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

Code: Select all

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

[muzik]

Would it be possible to allow for color specifications in scripts to use hexadecimal codes as an alternative to RGB? The following two would give the same result:

Code: Select all

x = 13, y = 13, rule = B36/S23History
4.2A$4.A3.2A$6.F.2A$.2A2.3F$.A2.5F2.2A$3.7F.2A$2.9F$2A.7F$2A2.5F2.A$
5.3F2.2A$3.2A.F$3.2A3.A$7.2A!
[[ COLOR kill 255 255 0 ]]

Code: Select all

x = 13, y = 13, rule = B36/S23History
4.2A$4.A3.2A$6.F.2A$.2A2.3F$.A2.5F2.2A$3.7F.2A$2.9F$2A.7F$2A2.5F2.A$
5.3F2.2A$3.2A.F$3.2A3.A$7.2A!
[[ COLOR kill #FFFF00 ]]

[rowett]

Would it be possible to allow for color specifications in scripts to use hexadecimal codes as an alternative to RGB?

Yes, done.

[muzik]

Would it be possible to allow for color specifications in scripts to use hexadecimal codes as an alternative to RGB?

Yes, done.

Could it also be made to support ARGB? If eight hexadecimal characters are specified instead of six, the first two would be treated as an alpha channel from 0 to 255, and the last six would be RGB as usual. As such, the following two script commands would produce identical results:

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ GRID ZOOM 64
COLOR LABEL 0 255 255
LABELALPHA 0.5
LABEL 2 2 32 "HERE'S SOME TEXT" ]]

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ GRID ZOOM 64
COLOR LABEL #8000FFFF
LABEL 2 2 32 "HERE'S SOME TEXT" ]]

[rowett]

Could it also be made to support ARGB?

No since most colour settings don't support alpha.

[muzik]

Could it also be made to support ARGB?

No since most colour settings don't support alpha.

ARGB specification would be exclusive to labels, arrows and other annotation objects that can have their alpha specified. Everything else would just throw up an error about alpha being unsupported. While I'd very much like the currently hardcoded alpha values to be configurable at some point in the future, that's a low priority suggestion.

On the topic of annotations, is there anywhere in the Help menu that lists the details on defined annotations in the current pattern? I can't seem to find anywhere that does. Most things that have customizable colors appear to be displayed in Help now, so these are the only things that are still missing if so.

[GUYTU6J]

Could it also be made to support ARGB?

No since most colour settings don't support alpha.

Incidentally, I was about to suggest a similar option to adjust each layer's opacity for Golly's Stack Layers mode.

Great job for the recent update. Can we write more commands for randomization so that every time a lifeviewer pops up it will show a different random initial configuration in a fixed rule? The required script would look like this: (the command names are just for example, it can be something else)
[cod]x = 0, y = 0, rule = 345/2/4
!
#C [[ RANDOMIZE RANDT <> RANDWIDTH <> RANDHEIGHT <> RANDX <> RANDY <> RANDFILL <> RANDSTATECHANCE <> <>]]
[/cod]
Which means to RANDOMIZE a RANDWIDTH-by-RANDHEIGHT region whose upper left corner is at (RANDX,RANDY) (default (0,0)) with RANDFILL percentage (cells with non-zero states versus all cells) at generation RANDT (default 0). RANDSTATECHANCE n p tells the percentage p of state n cells among all non-zero-state cells, which by default should be p=100 for n=1 and p=0 for else.
If completed, we can embed a viewer in LifeWiki Template:Rule but that's the topic for another thread.

Would RANDT, RANDX, RANDY and RANDSTATECHANCE be available to randomize a specific location at some non-zero generation?

[rowett]

On the topic of annotations, is there anywhere in the Help menu that lists the details on defined annotations in the current pattern?

Yes, Help->Annotations (only available if the pattern has annotations).

[muzik]

What exactly controls the speed slider turning red? It appears to go red even when I'm receiving a solid 60 fps and the pattern isn't being throttled. Yet to test this on all devices, though.

[muzik]

On the topic of annotations, is there anywhere in the Help menu that lists the details on defined annotations in the current pattern?

Yes, Help->Annotations (only available if the pattern has annotations).

Could this button be made to stay present on the help menu if no annotations are specified, but in a grayed-out state, for consistency with other buttons?

[rowett]

Incidentally, I was about to suggest a similar option to adjust each layer's opacity for Golly's Stack Layers mode.

For Golly please use the Golly Suggestions thread.

Would RANDT, RANDX, RANDY and RANDSTATECHANCE be available to randomize a specific location at some non-zero generation?

I'll investigate enhancing [[ PASTE ]] so it can paste a random size block of cells. There's the [[ PASTET ]] command that allows this to happen at a specified generation, or [[ PASTET EVERY ]] that would allow this to happen every so many generations.

[rowett]

What exactly controls the speed slider turning red? It appears to go red even when I'm receiving a solid 60 fps and the pattern isn't being throttled. Yet to test this on all devices, though.

The elapsed time since the last update compared with Help->Display->Refresh.

[rowett]

Could this button be made to stay present on the help menu if no annotations are specified, but in a grayed-out state, for consistency with other buttons?

No. It adds clutter to a long menu for a function rarely used.

[rowett]

Would RANDT, RANDX, RANDY and RANDSTATECHANCE be available to randomize a specific location at some non-zero generation?

I extended the existing [[ PASTE ]] and [[ RLE ]] functionality so you can now define a box of random cells [[ RANDCELLS W H ]] that you want to paste. You can then use [[ PASTET ]] to define which generation you want the paste to happen. The existing [[ RANDFILL ]] command will set the random chance of a cell being alive for subsequent [[ RANDCELLS ]] definitions.

Code: Select all

x = 1, y = 1, rule=B3/S23
!
[[ ZOOM 10 GRID ]]

Paste a 10x10 box of random cells (50% chance, the default) at -5, -5 at generation 0
[[ PASTE RANDCELLS 10 10 -5 -5 ]]

Paste a 6x12 box of random cells (30% chance) at 10, 10 at generation 5
[[ PASTET 5 RANDFILL 30 PASTE RANDCELLS 6 12 10 10 ]]

Define a 8x20 box of random cells (66% chance) and paste it at -25, -10 at generation 10
[[ RANDFILL 66 RLE randbox RANDCELLS 8 20 PASTET 10 PASTE randbox -25 -10 ]]

Symmetric soup:

Code: Select all

x = 1, y = 1, rule=B3/S23
!
Define the top left quadrant
[[ RLE topleft RANDCELLS 16 16 ]]

Use transformations to paste into the four quadrants
[[ PASTE topleft 0 0 ]]
[[ PASTE topleft 0 31 FLIPY ]]
[[ PASTE topleft 31 0 FLIPX ]]
[[ PASTE topleft 31 31 FLIP ]]

[muzik]

A black rounded rectangle appears around the viewer when the viewer is brought into focus on desktop browsers (tested with Chrome and Brave). This is especially noticeable on Catagolue as well as the conwaylife.com main page. Is this intended?

[rowett]

A black rounded rectangle appears around the viewer when the viewer is brought into focus on desktop browsers (tested with Chrome and Brave). This is especially noticeable on Catagolue as well as the conwaylife.com main page. Is this intended?

That's up to the stylesheet of the webpage containing the viewer.

[muzik]

Hex colouring seems to throw up a script error in some cases where RGB works just fine:

Code: Select all

x = 1, y = 1, rule = B/S012345678
b!
[[ GRID COLOR ARROW #FF0000 ARROW -100 -3 100 -3 24 ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
b!
[[ GRID COLOR ARROW 255 0 0 ARROW -100 -3 100 -3 24 ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
b!
[[ GRID COLOR GRID #FF0000 ARROW -100 -3 100 -3 24 ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
b!
[[ GRID COLOR GRID 255 0 0 ARROW -100 -3 100 -3 24 ]]

[rowett]

Hex colouring seems to throw up a script error in some cases where RGB works just fine:

Fixed, thanks.

[muzik]

Drawing appears to assume that the proper triangular grid is in use even if rectangular cells are enabled. Try drawing across this yellow line and note that the cells are filled in correctly for the triangular grid, but are "staggered" for the rectangular grid display, implying that the triangular grid is still in use for coordinate deletion behind the scenes:

Code: Select all

x = 1, y = 1, rule = B/S0123456789XYZL
b!
[[ GRID COLOR ARROW #FFFF00 ARROW -100 -2.625 100 -2.625 24 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123456789XYZL
b!
[[ GRID SQUARECELLS COLOR ARROW #FFFF00 ARROW -100 -2.625 100 -2.625 24 ]]

Expected behaviour would be that drawing would treat the rectangular cells as rectangular if active, and only use triangular drawing if triangular cells are enabled.

Also, something rather minor I noticed: the "Grid" button for the rectangular grid for triangular rules still appears to be a square grid. This is inconsistent with the hexagonal grid when rectangular cells are forced, which correctly causes the offset square grid to be rendered on the button. Shouldn't the grid button render taller rectangles for triangular rules when rectangles are forced?

Code: Select all

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

Code: Select all

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

Code: Select all

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

[muzik]

Would it be possible to add native support for the following two triangular grid neighbourhoods? From my enumeration, these are the only two symmetric subsets of the 12-cell range-1 neighbourhood (aside from the trivial case with no cells) that aren't currently supported. Suggested names would be "Triangular Radiation" (suffix LR) for the 3-cell far-vertices-only neighbourhood, and "Triangular Biohazard" (suffix LB) for the 9-cell neighbourhood with everything but the far vertices present.

Code: Select all

x = 0, y = 0, rule = 0123456789XYZ//3L
.B.B8.B$2BA2B7.A$.3B6.B3.B!
[[ GRID THEME Margolus
LABEL 3 -1 32 "Triangular Biohazard\n(LB)" 
LABEL 13 -1 32 "Triangular Radiation\n(LR)" ]]

While these could theoretically simply be defined via custom CoordCA neighbourhoods, I'd much prefer to see them be natively supported as their own range-1 neighbourhoods, as the general outer-totalistic algorithm that supports higher ranges doesn't currently support unbounded B0 rules, nor does it support non-plane, non-torus bounded grids (and it also doesn't support [R]History if ever that returns for range-1 triangular rules).

----

Would it be possible to have the "New Pattern" message disappear when a menu such as the help menu is opened? It occludes text in these scenarios which I find to be annoying.

Code: Select all

x = 0, y = 0, rule = B/S012345678
b!

----

I'm not sure if this is intended, but changing the rule from within the viewer reverts most changes made to settings from within the viewer after loading it. For the following pattern, try switching off Cell Borders, for example, and then changing to another hexagonal rule, and then note that they've reenabled themselves:

Code: Select all

x = 7, y = 22, rule = B2/S3H
3b3o$bo3bo$3b2o2$b2obo$o$2bo9$obo$4bo$bo2bo$bobo$2bo2bo$6bo$3bobo!
[[ CELLBORDERS ]]

[muzik]

The information box at the bottom left that details the type of cell under the cursor appears to be bugged for this pattern, as the region inside of the box beyond 29 X is listed as [boundary], and an equivalent region outside of the box to the left is denoted "dead" implying them to be within the box even though they are not:

Code: Select all

x = 5, y = 4, rule = B3/S23:T60,60
24o!
[[ ZOOM 8 ]]

The Y axis of this pattern appears to also be affected, but to a lesser degree. It still happens outside of the -30 to 30 range in this case.

----

Would it be possible to allow for existing selections to be manipulated from inside of the viewer? Currently, clicking anywhere on the grid will cause any existing selections to be cancelled while in select mode. I propose that the following changes be made:

- clicking and dragging near the edge of a selection would cause that edge of the selection to be resized (like in mobile Golly, or what happens if you use shift and then click in desktop Golly)
- clicking and dragging near a corner does much the same, resizing it on two axes
- clicking and dragging near the center of the selection allows for the selection rectangle to be moved around (a mobile Golly functionality that I don't think has any desktop counterpart yet)

The only way to cancel a selection would be to use the dedicated "cancel selection" button (or its hotkey), as to prevent any accidental cancellations due to misclicking on other parts of the grid.

In addition, it'd be preferable that for pasting patterns, there would be an in-viewer button and a hotkey for confirming the region that a pattern gets pasted into, rather than simply clicking on the grid, since this makes pasting rather tricky on touchscreen devices.

[rowett]

Drawing appears to assume that the proper triangular grid is in use even if rectangular cells are enabled

Fixed, thanks.

Also, something rather minor I noticed: the "Grid" button for the rectangular grid for triangular rules still appears to be a square grid.

Fixed, thanks.

[rowett]

Would it be possible to have the "New Pattern" message disappear when a menu such as the help menu is opened?

Yes, done.

I'm not sure if this is intended, but changing the rule from within the viewer reverts most changes made to settings from within the viewer after loading it.

Yes this is intentional. Changing the rule does not change any of the script commands in the original pattern so they will be retained when the rule changes.

[muzik]

Drawing appears to assume that the proper triangular grid is in use even if rectangular cells are enabled

Fixed, thanks.

I should point out that the same issue (or perhaps the opposite) still remains for hexagonal grids: it assumes that the offset square grid is in use even if it is not. Try drawing in one of the two triangles near the top and bottom vertices of each hexagon, and notice that adjacent cells are modified instead rather than the actually targeted hexagon:

Code: Select all

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

Code: Select all

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