Pattern viewer for forum threads

[muzik]

Layers appear to render strangely when surpassing each additive inverse of a positive integer power of two:

Code: Select all

x = 5, y = 4, rule = B3/S23:T60,60
24o!
[[ LAYERS 10 ZOOM -2 ]]

Code: Select all

x = 5, y = 4, rule = B3/S23:T60,60
24o!
[[ LAYERS 10 ZOOM -2.1 ]]

In [R]Super, all nonzero cell states are duplicated across all layers whereas only odd numbered [R]History cells are duplicated across layers using the alive state's color. You've stated that [R]History's behaviour is correct in this case, and while I prefer [R]Super's current behaviour it remains inconsistent with [R]History.

Code: Select all

x = 9, y = 9, rule = LifeHistory
3.3A3B$3.3A3B$3.3A3B$3.3C$3.3C$3.3C$3D3E3F$3D3E3F$3D3E3F!
[[ GRID LAYERS 5 ]]

Code: Select all

x = 39, y = 6, rule = LifeSuper
3.3A3B3C3D3E3F3G3H3I3J3K3L$3.3A3B3C3D3E3F3G3H3I3J3K3L$3.3A3B3C3D3E3F
3G3H3I3J3K3L$3M3N3O3P3Q3R3S3T3U3V3W3X3pA$3M3N3O3P3Q3R3S3T3U3V3W3X3pA$
3M3N3O3P3Q3R3S3T3U3V3W3X3pA!
[[ GRID LAYERS 5 ]]

Custom ruletables can have their layers values changed, but they don't render extra layers on top. Can this be fixed so that custom ruletables do render these extra layers?

Code: Select all

x = 4, y = 6, rule = Life
2bo$2obo$3bo$bobo$o$b3o!
[[ GRID LAYERS 5 ]]

Code: Select all

x = 4, y = 6, rule = Life-RuleLoader
2bo$2obo$3bo$bobo$o$b3o!
[[ GRID LAYERS 5 ]]

And finally, would it be possible for grid rotation and tilting to be enabled for the "none" rule? To my understanding it's just a normal square-grid rule, so I don't see how there would be any issues in enabling this, nor why it's disabled in the first place.

[muzik]

Reiterating this post from 2020:

Code: Select all

x = 16, y = 18, rule = R2,C2,S3-4,B3-4,NW0000001110010100111000000|R2,C2,S3-4,9-20,B4,NW1111111111110111111111111
9b3o5b$9bo7b$9b4o4b$17b$17b$17b$17b$17b$b3o13b$4o13b$2o15b$2o15b$17b$13b2o2b$12bo2bob$11bo4bo$11bo4bo$12bo2bob$13b2o2b$!

If alternating between neighbourhoods isn't supposed to work, an error message should probably be shown.

I assume that alternating between two different neighbourhoods of the same range and symmetry isn't supported? If so, this should probably give an error as mentioned in the post rather than run the incorrect rule. Either that, or support should be added for consistency with CAViewer (see image file in original version of quoted post).

----

Would it make more sense for the "Reset" button to flip horizontally in negative generations, since it takes you forward to generation 0 in this case?

Code: Select all

x = 9, y = 9, rule = MargSingRot
3ob2obo$2ob2ob2o$ob2o2b2o$3obobo$obob4o$5o$o2bo$obob5o$2obob2obo!
[[ REVERSESTART ]]

----

Should mod calculations be disabled for MAP strings, ruletables with symmetry set to "none", and asymmetric custom neighbourhoods? Identify can output otherwise impossible object type, mod/period and transform type combinations as a result such as "RotCWorCCW" or "RotCWFlipX" spaceships:

Code: Select all

x = 2, y = 1, rule = MAPAABoACAAgAAAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

Code: Select all

x = 7, y = 6, rule = MAPAABoACAAgAAAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
5b2o5$2o3b2o!

as well as oscillators with a mod a quarter of their period marked as "FlipX":

Code: Select all

x = 10, y = 10, rule = NaiveLifeEmulated
10E$E8.E$E.B6.E$E8.E$E8.E$E8.E$E8.E$E8.E$E8.E$10E!

If it's possible for LifeViewer to somehow detect that the MAP string belongs to an isotropic rule, then mod support could likely be restored, but I'm unsure if this is possible.

[muzik]

And hexagonal and triangular grids just don't work with it at all

True, layers are only currently supported on square and offset square grids.

Has the functionality for layers to work with the offset square grid been removed? From what I can see, the sliders are greyed out:

Code: Select all

x = 20, y = 20, rule = B/S0123456H
o3bobo3b3ob3o2bo$o2b3o3bobo2b4o$b2o4b2obo3bo2b2o$4b2ob2obobo2bob3o$2ob
o2bobobob2o2bo2bo$bob2o4b3o2bo3bo$6ob2o2bo2b3ob2o$b3o2bo2bo2b5ob2o$2bo
bo3b3ob2o2b4o$b3o2bo2bo2bob2obo$bo3bo3b3o5bobo$2bo4bob3obo2bo2bo$o3bo
2b3ob3obob3o$bob2o2bo2b8obo$o4b6obob2obobo$o3b2o3b3o6b2o$o4b3ob3o2bo4b
o$5bob2o3bobob3o$7o3b2o4b3o$7b3ob3ob2o!
[[ GRID SQUARECELLS LAYERS 5 ]]

I'm not sure if the functionality has been removed intentionally or if it was an accidental side effect of disabling it for the true hexagonal grid. Scripts appear to silently reject it if defined.

EDIT: Just tested build 388 and layers definitely worked with the offset square grid. They also worked fine with the triangular grid when zoomed out beyond 4.0 (although at that point it was just the square grid and didn't have the modern rectangles). So if possible I'd like it if this functionality returned. For triangular and hexagonal rules:

- if Use Rectangles is active, then Layers and Depth should be processed and configurable
- if Use Rectangles is inactive, those two sliders should be greyed out and the viewer should treat those sliders as if they were set to the default values beyond a zoom level of 4

This would help to reintroduce the accidentally(?) removed functionality. Unless, of course, proper support for layers ends up coming to triangular and hexagonal rules, but I'm not sure if that'll happen any time soon.

[rowett]

The information box at the bottom left that details the type of cell under the cursor appears to be bugged for this pattern

This is known. There are currently issues with cell position with bounded grids and/or CXRLE Pos.

EDIT: Fixed for this specific issue.

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.

Rather than just click you can drag the paste to the position you want and then release to confirm.

[rowett]

Has the functionality for layers to work with the offset square grid been removed?

Yes so it is consistent with the Hex display. Same with Triangles.

[rowett]

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

This has been improved, thanks.

[rowett]

If alternating between neighbourhoods isn't supposed to work, an error message should probably be shown.

Fixed, thanks.

Would it make more sense for the "Reset" button to flip horizontally in negative generations, since it takes you forward to generation 0 in this case?

No. It's clear what reset does.

[muzik]

In that case shouldn't the rotating oscillator at least have a mod of half its period be detected, since it occurs on an even generation?

Actually it makes more sense to disable Mod output for these rules since it won’t be accurate.

Could a toggle be introduced somewhere that re-enables hidden Identify values for rulespaces which have them disabled? While they have been disabled for a reason (not making sense in a rulespace, full support not being added yet, and so on), there are occasional cases where the output can still be valuable. For example, this Margolus p8 oscillator has a mod of 4 (an even number), which I believe will be recognised by Identify:

Code: Select all

x = 9, y = 5, rule = MargSingRot
bo$o!

In addition, the slope directions reported for hexagonal and triangular spaceships, despite not making much sense at first glance, do reveal useful information pertaining to their orientation on the hexagonal grid.

The restoration of these values to Identify would be hidden behind a toggle (off by default, and likely under Advanced) to ensure that anyone who wants to see these values understands that they are likely misleading or inaccurate and as such should be taken with a grain of salt.

----

On the topic of warnings, would it be possible to implement an annotation that appears when a strobing rule is loaded (LifeViewer would recognise general-range outer-totalistic rules with B0, no Smax and a valid bounded grid, as well as rule tables with a state which is born on 0 cells and doesn't have Smax for that state)? There have been numerous occasions where I've inadvertently loaded such a rule and immediately played it and been assaulted by an unpleasant strobing effect, so having a safeguard like this in place would hopefully lessen cases like these.

Example of a strobing outer-totalistic rule (STEP 2 NOTHROTTLE used to avert effect):

Code: Select all

x = 10, y = 8, rule = R1,C2,S4-5,B0-2:T50,50
2b2o$5b4o$ob2o$ob3o4bo$ob3o4bo$ob2o$5b4o$2b2o!
[[ STEP 2 NOTHROTTLE ]]

Example of a strobing rule table (STEP 2 NOTHROTTLE used to avert effect):

Code: Select all

x = 6, y = 3, rule = LifeRLB0
.3A$3A.2A$.3A!
[[ STEP 2 NOTHROTTLE ]]

It may also be worth changing the "1x" button to "2x" and moving the dead zone accordingly in these rules such that resets (or indeed accidental misclicks) don't immediately cause the effect.

[muzik]

Potentially mobile-exclusive potentially-bug that I'm yet to test on desktop: after clicking on a NOGUI window, it's possible to click and drag to move the pattern. This reminds me of the old mobile bug with expandable viewers so I'm not sure if this is intended or not.

Code: Select all

x = 3, y = 4, rule = B3aijr4ciq7c/S2-i3-a4i5q
o$2o$b2o$2o!
[[ NOGUI ]]

The flashing "Copy" text is another example of something whose color cannot be customized.

[rowett]

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.

Done.

Code: Select all

x = 1, y = 1, rule=B1/SLB
o!
[[ STARTFROM 1 GRID TITLE "#D" ]]

Code: Select all

x = 1, y = 1, rule=B1/SLR
o!
[[ STARTFROM 1 GRID TITLE "#D" ]]

[rowett]

after clicking on a NOGUI window, it's possible to click and drag to move the pattern.

Fixed, thanks.

[muzik]

A related, minor issue that affects NOGUI and thumbnail viewers: tapping within that viewer window and dragging the tap outside of the viewer will cause the "Expand"/"Copy" text to persist, likely because the viewer cannot register that the cursor is no longer in its space. Not sure if this is fixable.

Code: Select all

x = 3, y = 4, rule = B3aijr4ciq7c/S2-i3-a4i5q
o$2o$b2o$2o!
[[ THUMBNAIL ]]

Could a functionality be added to the viewer that causes the currently moused-over cell to be visually highlighted in some way? Perhaps the cell currently under the mouse could have a colored border around it, be filled in with a translucent color, or both. This would make the cell under the cursor much easier to see when zoomed out, allow for easier debugging of cell position and shape issues like the recently-fixed hexagonal and triangular grid cases, make it easier to see what cell is considered to be under the mouse when the viewer is tilted, and also help with debugging mobile-related issues pertaining to where it believes the cursor is.

[muzik]

Can VIEWONLY be made to still show all of the buttons on the bottom row (T menu, undo/redo, speed sliders, reverse button, reset, back, forward, play), but greyed out to indicate that they're not usable, for the sake of consistency with other button-disabling scenarios?

Code: Select all

x = 3, y = 4, rule = B3aijr4ciq7c/S2-i3-a4i5q
o$2o$b2o$2o!
[[ VIEWONLY ]]

If not, I'd still like to see the T menu present as to provide a more convenient way of checking the population and (if set with CXRLE) current generation. Since the button doesn't affect playback or the pattern at all I don't see why it's disabled.

[rowett]

On the topic of warnings, would it be possible to implement an annotation that appears when a strobing rule is loaded

I've added B0 emulation for 2-state LtL/HROT rules.

Code: Select all

x = 10, y = 8, rule = R1,C2,S4-5,B0-2:T50,50
2b2o$5b4o$ob2o$ob3o4bo$ob3o4bo$ob2o$5b4o$2b2o!

[muzik]

I've added B0 emulation for 2-state LtL/HROT rules.

Brilliant - so I assume this brings us up to parity with Golly for unbounded rule support then?

It does seem as though support for B0 Generations rules has been sacrificed, though, which ultimately isn't a massive loss. I'm still curious as to how these would even be emulated - would genext be capable of it or would it require some other rulespace to be implemented? Even for non-strobing cases this is rather puzzling. I might discuss this in the dedicated Extended Generations thread some time soon.

[muzik]

LifeViewer no longer seems to accept alternating rules:

Code: Select all

x = 9, y = 5, rule = alternlife
$bo3b3o$b3o2bo$2bo!

Code: Select all

x = 9, y = 5, rule = B1357/S1357|B1357/S02468
$bo3b3o$b3o2bo$2bo!

Some even weirder behaviour resulting from this can be observed on the viewer.html page: inputting an RLE with an alternating neighbourhood and then clicking View does nothing until the viewer is clicked, in which case it appears to reload, but the rule and pattern remain unchanged. Pressing play and then clicking the view button again will then cause the viewer to appear to reload for a fraction of a second, but the pattern keeps evolving even though the generation counter resets. Ultimately these notes are pretty redundant since the root cause being fixed will likely wipe out these extra effects anyway, but in the event that they highlight any other issues those might be worth fixing as well.

[rowett]

LifeViewer no longer seems to accept alternating rules:

Fixed, thanks.

[rowett]

Brilliant - so I assume this brings us up to parity with Golly for unbounded rule support then?

Yes

[muzik]

I've been doing some thinking pertaining to triangular rules on bounded grids recently, and noticed something which may require attention. Currently, triangular bounded grids require that the dimensions of such a bounded grid be even by even as to permit logical connections. However, this really only makes sense for toroidal bounded grids, as Klein bottle bounded grids flip the pattern when a boundary is reached. Flipping a pattern on a triangular grid also switches the parity of the triangles, resulting in a connection that makes no sense for the twisted edge:

Code: Select all

x = 4, y = 2, rule = B4/S456L:T24,24
4o$4o!

Code: Select all

x = 4, y = 2, rule = B4/S456L:K24,24*
4o$4o!

Code: Select all

x = 4, y = 2, rule = B4/S456L:K24*,24
4o$4o!

Code: Select all

x = 4, y = 2, rule = B4/S456L:C24,24
4o$4o!

(Also, the spaceship doesn't appear to be able to cross the boundary on either of the Klein bottle grids, which seems like a bug to me since one of them should work.)

So to my understanding:
- the torus bounded grid should still require even by even boundaries
- Klein bottle bounded grids should require an odd size on the twisted edge, and an even size on the non-twisted edge
- cross surface bounded grids should be odd by odd
- plane bounded grids probably shouldn't have side length parity restrictions due to not having any connections
- and sphere bounded grids should probably be disabled for triangular and hexagonal grids, since they involve 90 degree rotations which are meaningless on said grids.

Of course, many of these flaws arise from the fact that we're using rectangular bounded grids for rules which are inherently not rectangular, but that's a whole different can of worms. I have a dedicated thread on issues that arise with hexagonal and triangular emulation on square grids and what could be done to solve them, so input on that thread would be appreciated if you have anything to add.

----

On the topic of bounded grids, would it be possible to allow for a * to be appended to the sphere bounded grid to flip the equatorial diagonal? There are currently two different connection types a sphere can have, only one of which is supported. Here are some test cases:

Normal sphere, barberpole wick should be continuous:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30
bo2$bobo2$3bobo23bo2$5bobo2$7bobo2$9bobo2$11bobo2$13bobo2$15bobo2$17bo
bo2$19bobo2$21bobo2$o22bobo$o$o24bobo2$4bo22bobo$4bo!

Normal sphere, barberpole wick should die:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30
28bo2$26bobo2$o23bobo2$22bobo2$20bobo2$18bobo2$16bobo2$14bobo2$12bobo
2$10bobo2$8bobo2$6bobo2$4bobo22bo$29bo$2bobo24bo2$obo22bo$25bo!

Flipped sphere, barberpole wick should be continuous:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30*
28bo2$26bobo2$o23bobo2$22bobo2$20bobo2$18bobo2$16bobo2$14bobo2$12bobo
2$10bobo2$8bobo2$6bobo2$4bobo22bo$29bo$2bobo24bo2$obo22bo$25bo!

Flipped sphere, barberpole wick should die:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30*
bo2$bobo2$3bobo23bo2$5bobo2$7bobo2$9bobo2$11bobo2$13bobo2$15bobo2$17bo
bo2$19bobo2$21bobo2$o22bobo$o$o24bobo2$4bo22bobo$4bo!

[rowett]

I've been doing some thinking pertaining to triangular rules on bounded grids recently, and noticed something which may require attention.

These will all need to be revisited if non-square bounded grids and selections are implemented. I have no current plans.

On the topic of bounded grids, would it be possible to allow for a * to be appended to the sphere bounded grid to flip the equatorial diagonal?

Flipped sphere, barberpole wick should be continuous:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30*
28bo2$26bobo2$o23bobo2$22bobo2$20bobo2$18bobo2$16bobo2$14bobo2$12bobo
2$10bobo2$8bobo2$6bobo2$4bobo22bo$29bo$2bobo24bo2$obo22bo$25bo!

Flipped sphere, barberpole wick should die:

Code: Select all

x = 30, y = 30, rule = B3/S23:S30*
bo2$bobo2$3bobo23bo2$5bobo2$7bobo2$9bobo2$11bobo2$13bobo2$15bobo2$17bo
bo2$19bobo2$21bobo2$o22bobo$o$o24bobo2$4bo22bobo$4bo!

Yes, done. Please check it.

[muzik]

Yes, done. Please check it.

viewer.html Build 764 seems to support these two patterns as expected.

[muzik]

There's a couple more bounded grid types that I've wanted for a while, which, to my knowledge, would complete the set of possible interesting bounded grids:

- Finite cylinder: a bounded grid where two opposing sides would act as "plane" boundaries, and the other two would be connected without a twist. A * would be used to indicate which of the two opposing sides are connected to each other, similarly to how a * is used to identify the twisted connection on a Klein bottle.

The letter used for this bounded grid would be A (for Annulus; C for Cylinder and T for Tube are both already taken by other bounded grid types)

Code: Select all

x = 5, y = 4, rule = B3/S23:A24*,24
o2bo$4bo$o3bo$b4o!

Code: Select all

x = 4, y = 5, rule = B3/S23:A24*,24
b3o$o2bo$3bo$3bo$obo!

Code: Select all

x = 5, y = 4, rule = B3/S23:A24,24*
o2bo$4bo$o3bo$b4o!

Code: Select all

x = 4, y = 5, rule = B3/S23:A24,24*
b3o$o2bo$3bo$3bo$obo!

- Mobius strip: a bounded grid where "two opposing sides" (really just the one side due to the twist) would act as "plane" boundaries, and the other two would be connected with a twist. Again, a * would be used to identify the two sides which are connected.

The letter M is currently free and as such can be used for this bounded grid.

Code: Select all

x = 5, y = 4, rule = B3/S23:M24*,24
o2bo$4bo$o3bo$b4o!

Code: Select all

x = 4, y = 5, rule = B3/S23:M24*,24
b3o$o2bo$3bo$3bo$obo!

Code: Select all

x = 5, y = 4, rule = B3/S23:M24,24*
o2bo$4bo$o3bo$b4o!

Code: Select all

x = 4, y = 5, rule = B3/S23:M24,24*
b3o$o2bo$3bo$3bo$obo!

[muzik]

Reiterating some older bugs and potential issues:

Bounded grids don't seem to be centered correctly on first load (pay close attention to the squares on the left and right sides of the window and note how much of each is cut off as a reference, especially when zooming):

Code: Select all

x = 0, y = 0, rule = B3/S23
10o$o8bo$o8bo$o8bo$o3b2o3bo$o3b2o3bo$o8bo$o8bo$o8bo$10o!
[[ GRID ]]

Code: Select all

x = 0, y = 0, rule = B3/S23:T8,8
2o$2o!
[[ GRID ]]

The triangular grid renders slightly to the left of where it should be. The following pattern demonstrates this with lines, and the issue can also be seen when switching between rectangles and triangles and noticing that the cell positions appear to move sideways. Also, looking closely at the right of the grid shows that some horizontal lines are not drawn, but the visibility of this depends on screen size, viewer window size and zoom level:

Code: Select all

x = 12, y = 8, rule = B3/S23L
b!
[[ GRID THEME Life32 ZOOM 24
COLOR ARROW 0 255 0
ARROW 5 -10 5 15 24
LABEL 9 0 24 "Use Rectangles"
COLOR ARROW 0 0 255
ARROW -5.26 -10 -5.26 15 24
LABEL -3 0 24 "Triangles" ]]

PCA rules' T counter does not increment after all cells in a pattern die, and for blank patterns do not go past 1 or -1, unlike all other rule families:

Code: Select all

x = 0, y = 0, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
b!

Code: Select all

x = 0, y = 0, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
b!
[[ REVERSESTART ]]

Code: Select all

x = 0, y = 0, rule = B3/S23
b!

And finally, hexagonal cells (and offset squares) should probably be made slightly shorter. For hexagonal grids, large patterns tend to appear slightly but noticeably taller than they are wide, whereas equivalent triangular rules have the proportions completely correct:

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ STARTFROM 255 ZOOM 1 ]]

Code: Select all

x = 1, y = 1, rule = B13/S13LE
o!
[[ STARTFROM 254 ZOOM 1 ]]

[muzik]

How does LifeViewer decide where to place major grid lines? Golly has them intersect at the bottom left of the (0,0) cell and they repeat periodically as expected, but LifeViewer doesn't seem to place them consistently anywhere. The first pattern has them at the top left of (3,3) and the second at the top left of (-2,-2):

Code: Select all

x = 0, y = 0, rule = B3/S23
10o$o8bo$o8bo$o8bo$o3b2o3bo$o3b2o3bo$o8bo$o8bo$o8bo$10o!
[[ GRID ]]

Code: Select all

x = 0, y = 0, rule = B3/S23:T8,8
2o$2o!
[[ GRID ]]

[muzik]

LifeViewer seems to be incorrectly decoding high range rulestrings and treating them as B0:

Code: Select all

x = 5, y = 5, rule = R2,C6,M0,S2..3,B3..3,NN
2.2A$B2CA$.CB2A$3A$2.A!