Pattern viewer for forum threads

[muzik]

It seems like recent fixes to PCA theme or error handling have made it impossible to change the color of north cells regardless of notation used, with the only remaining way to change these colors being the build-in themes:

Code: Select all

x = 11, y = 11, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
I9AC$HI7ACB$2HI5AC2B$3HI3AC3B$4HIAC4B$5HO5B$4HLDF4B$3HL3DF3B$2HL5DF2B
$HL7DFB$L9DF!
[[ COLOR N White COLOR E White COLOR S White COLOR W White ]]

Code: Select all

x = 11, y = 11, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
I9AC$HI7ACB$2HI5AC2B$3HI3AC3B$4HIAC4B$5HO5B$4HLDF4B$3HL3DF3B$2HL5DF2B
$HL7DFB$L9DF!
[[ COLOR 1 White COLOR 2 White COLOR 4 White COLOR 8 White ]]

DEADRAMP also isn't shown in Help > Themes for three-state Generations patterns.

Code: Select all

x = 2, y = 2, rule = /2/3
AB$AB!

Code: Select all

x = 3, y = 2, rule = /2/4
ABC$ABC!

Icon names don't seem right. This rule has nine states from 0 to 8, with state 0 being the background state as is standard. However, the icon that would be used for state 1 is called "state 0" despite it being intended for state 1, state 2's icon is called "state 1", and so on.

Code: Select all

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

I've tested some of the PCA/Margolus bugs in newer versions that I'm still yet to report (hopefully sooner today) and they do seem to behave differently, and some others seem fixed (such as step back/step forward reversing play direction in empty patterns, which seems to have been fixed around the time that PCA History cells being cleared in empty patterns was).

[rowett]

Moving forward stepwise doesn't seem to show a "Life ended at generation" message anymore

Fixed, thanks.

Also, since normal playback is permitted when all cells die if there are future paste commands to be executed, could Go To Gen/STARTFROM (and possibly Identify) also respect this and not stop prematurely if it detects commands?

Yes for Go To Gen/STARTFROM. No for Identify.

On the topic of Go To Gen, is there any reason for having the maximum number of generations it can go through capped at 1048576?

It was an arbitrarily large number. I've now picked an arbitrary larger number of 4194304.

Back on the topic of themes and cell color customization, the results of these commands are different

Fixed, thanks.

I've been wondering if it'd be possible to make snow a "normal" toggleable visual effect now since the formula to activate it is now publicly known - it'd have its own script command to force it on, an in-viewer button to toggle it for any desired pattern, and so on.

At some stage. It's only been 3 years...

[rowett]

It seems like recent fixes to PCA theme or error handling have made it impossible to change the color of north cells regardless of notation used

Fixed, thanks.

DEADRAMP also isn't shown in Help > Themes for three-state Generations patterns.

Fixed, thanks.

Icon names don't seem right.

Fixed, thanks.

[muzik]

I actually went the other way with this and removed the "New Pattern" message from the LifeHistory one. I decided that "New Pattern" is only relevant if there are no cells in the pattern, rather than no alive cells.

If this is the case, would it be possible to also rephrase the "Empty Pattern" message displayed when attempting to use Select All or Identify on a pattern containing no living cells? It calling a pattern "empty" despite the presence of [R]History/[R]Super cells or Generations dying cells has never fit well with me, either. Perhaps "No living cells to select" for Select All, and "No living pattern to Identify" for Identify?

Code: Select all

x = 5, y = 5, rule = LifeHistory
5F$5F$5F$5F$5F!

Code: Select all

x = 5, y = 5, rule = LifeSuper
5F$5F$5F$5F$5F!

Code: Select all

x = 5, y = 5, rule = //7
5F$5F$5F$5F$5F!

Also, playing each of these causes it to pause after one generation. The same behaviour is seen in initially empty patterns:

Code: Select all

x = 5, y = 5, rule = LifeHistory
b!

[muzik]

Time for those long-awaited reports:

PCA patterns seem to just crash LifeViewer outright when cells approach the edge of the grid. Previously they would jitter back and forth just before it, but never actually die (and Identify would never resolve, but there would still be a usable Cancel button). Neither of these are the expected behaviour.

Code: Select all

x = 10, y = 2, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
IC2.HBH.IC$LF6.LF!
[[ THEME LifeHistory MAXGRIDSIZE 9 ZOOM 1 ]]

Also, for the following pattern, when manually stepping forward, it would correctly increment by 64 generations from 0 --> 64, 64 --> 128 and 128 --> 192. However, it would then step to generation 317 (if I remember correctly) instead of generation 256, and there was some other odd behaviour I didn't take a note of. It now freezes the viewer again when trying to step beyond generation 192 since it goes to a point where PCA cells would hit the boundary.

Code: Select all

x = 9, y = 5, rule = PCA_1
20o!
[[ SHOWGENSTATS MAXGRIDSIZE 9 ZOOM -1.5 STEP 64 ]]

If we run any of these patterns to a point where it crashes, close the crashed viewer, and open another viewer, it'll do a step of whatever the step size is set to immediately after loading.

----

When testing a similar pattern to the pattern at the top in a Margolus rule, I found a way to reproduce the previously-reported Margolus pulsating effect to an absurd degree. I've put multiple content warnings in the test pattern below since this effect is very very very very very very very very very very not nice to look at.

Code: Select all

x = 5, y = 11, rule = M0,4,8,3,1,5,6,7,2,9,10,11,12,13,14,15
$2o$2o4$bo2bo3$2o$2o!
[[ GRID MAXGRIDSIZE 14 AUTOFIT STARS COLOR TEXT Lime T 0 "Disclaimer: this is very uncomfortable.\nPotential motion sickness/seizure risk!" PAUSE 3 "Playback commencing in 3 seconds..." T 4 "" ]]

Here's a pattern in Seeds, where this horrid effect does not occur:

Code: Select all

x = 4, y = 7, rule = B2/S
o$bo3$o2bo2$b2o!
[[ GRID AUTOFIT STARS MAXGRIDSIZE 14 ]]

----

PCA patterns also appear to be interacting incorrectly with some bounded grids. PCA_4 is a population conserving rule, so I'd expect that the population in the following pattern would remain constant, but it does not.

Code: Select all

x = 10, y = 5, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15:S10
A4$9.D!
[[ GRID ]]

There is the possibility that bounded grids like the sphere aren't getting the memo about the fact that cell states are meant to be rotated (or diagonally flipped? Is there an important distinction to be made in this context?) when they pass through the boundary, and just copy the cell states verbatim without respect to the fact that they should be rotated into other corresponding states. Here's a more direct test case for that example - I'd expect that for the bottom example, the spaceship should remateralize on the right just like it does in Seeds:

Code: Select all

#CXRLE Pos=-5,-5
x = 4, y = 3, rule = B2/S:S20
3bo$o$b2o!
[[ GRID ]]

Code: Select all

#CXRLE Pos=-5,-5
x = 4, y = 3, rule = PCA_1:S20
3bo$o$b2o!
[[ GRID ]]

----

For the following Margolus bounded grid pattern, if we draw a cell in the top right and/or bottom left. save the pattern, and then load the pattern, there will be no remaining cells inside of the grid, but despite this, no "New Pattern" message will be displayed.

Code: Select all

x = 2, y = 2, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15:T2
!

If we draw a cell at the top left, then save it and load it, the pattern will show no alive cells, but the T menu will say there is one. Select All seems to imply it's in the bottom right of the boundary cells, but the select offset bug might mean it thinks said cell is actually somewhere else. A cell drawn in the bottom right will stay in the bottom right if the pattern is saved and loaded.

It's also very easy to see that for Margolus patterns, bounded grids are very discentered, even more so than normal 2-state rules:

Code: Select all

x = 2, y = 2, rule = Life:T2
!

In general, for Margolus patterns, the top row of cells and left row of cells seem to get deleted in a bounded grid for some reason. Here's a larger bounded grid for testing purposes: manually select the entirety of this grid, use the Invert function to fill it with cells, optionally draw something at the very bottom right to confirm that the top and left rows are truly deleted rather than the entire pattern just being moved down and to the right, and then Save Pattern and reload it.

Code: Select all

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

This covers pretty much all of the major issues so far that I know of. I'll try to add any more issues I end up encountering below.

EDIT 1: It seems like custom PCA colors persist into other patterns again that don't have a theme explicitly defined (or they explicitly define the PCA theme), and they also don't go away if you switch from the custom theme to a PCA theme either. They even overwrite the values shown in Help > Themes!

Code: Select all

x = 14, y = 2, rule = PCA_4
ABCDEFGHIJKLMN$ABCDEFGHIJKLMN!

Code: Select all

x = 14, y = 2, rule = PCA_4
ABCDEFGHIJKLMN$ABCDEFGHIJKLMN!
[[ THEME PCA ]]

Code: Select all

x = 14, y = 2, rule = PCA_4
ABCDEFGHIJKLMN$ABCDEFGHIJKLMN!
[[ THEME Blues ]]

Code: Select all

x = 11, y = 11, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
I9AC$HI7ACB$2HI5AC2B$3HI3AC3B$4HIAC4B$5HO5B$4HLDF4B$3HL3DF3B$2HL5DF2B
$HL7DFB$L9DF!
[[ COLOR N White COLOR E White COLOR S White COLOR W White ]]

Code: Select all

x = 14, y = 2, rule = PCA_4
ABCDEFGHIJKLMN$ABCDEFGHIJKLMN!
[[ COLOR BACKGROUND 0 0 0 COLOR DEAD 0 0 127 COLOR DEADRAMP 0 0 47
COLOR N 96 0 128
COLOR E 0 104 128
COLOR S 0 0 255
COLOR W 128 128 192
COLOR NE 64 64 128
COLOR ES 0 64 192
COLOR SW 72 72 200
COLOR NW 96 64 128
COLOR NS 64 0 192
COLOR EW 64 104 128
COLOR ESW 43 64 149
COLOR NSW 85 43 170
COLOR NEW 85 85 128
COLOR NES 48 48 176
COLOR NESW 64 64 160 ]]

EDIT 2: For patterns that die out with paste commands yet to be executed, "Empty Pattern" is displayed instead of "Life ended at" - although since "Life ended at" is meant to not display in normal playback if future paste commands exist I'm not sure what the behaviour here should be:

Code: Select all

x = 1, y = 1, rule = B3/S23
3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo!

Code: Select all

x = 1, y = 1, rule = B3/S23
3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo!
[[ PASTET EVERY 12 12 PASTE 3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo! 0 0 ]]

EDIT 3: The population graph inconsistently occludes Identify results. The initial Identify table appears on top of it, the period table's "Oscillator period X" header appears on top of it but the rest of the table does not, and every part of the period map and its key is hidden behind the graph.

Code: Select all

x = 123, y = 135, rule = B3/S23
5b2o$5b2o6$26b2o$25bobo$24b3o12bo$4b3o8b2o6b3o8b2o3b4o$3bo3bo7b2o7b3o8b2o3b4o
$2bo5bo16bobo2b2obob2o3bo2bo5b2o$2bo5bo17b2o2b2obobo4b4o5b2o$5bo26b2obo3b4o$
3bo3bo31bo$4b3o$5bo$25bo$23b2o$2b3o19b2o$2b3o$bo3bo$9bobo$2o3b2o3b2o$10bo5$
17bo$18b2o$17b2o2$3b2o$3b2o4$42bo$40b3o$39bo$20b2o17b2o$20bo$21b3o$23bo23$54b
obo$55b2o$55bo45$111b2o6b2o$110bo2bo4bo2bo$109b6o2b6o$110bo2bo4bo2bo$111b2o6b
2o8$104b3o$104bobo$104b3o$104b3o$104b3o$104b3o$104bobo$104b3o!
[[ GRAPH ]]

EDIT 4: For the horrible Margolus zoom bug mentioned earlier, toggling the WAYPT button after it starts demonstrating the bug grays out the autofit button.

[rowett]

would it be possible to also rephrase the "Empty Pattern" message displayed when attempting to use Select All or Identify on a pattern containing no living cells?

Yes, done.

[rowett]

PCA patterns seem to just crash LifeViewer outright when cells approach the edge of the grid.

Fixed, thanks.

[rowett]

I found a way to reproduce the previously-reported Margolus pulsating effect to an absurd degree.

Fixed, thanks.

It seems like custom PCA colors persist into other patterns again that don't have a theme explicitly defined (or they explicitly define the PCA theme), and they also don't go away if you switch from the custom theme to a PCA theme either.

Fixed, thanks.

The population graph inconsistently occludes Identify results.

Fixed, thanks.

[muzik]

I don't like the fact that for [R]Super, state 6 is named "boundary", since LifeViewer already has an established element named "boundary" already.

Would it be possible for [R]History state names to also apply to the equivalent states in [R]Super, and possibly vice versa?

Code: Select all

x = 17, y = 2, rule = B3/S23History
2A.2B.2C.2D.2E.2F$2A.2B.2C.2D.2E.2F!
[[ COLOR alive 255 0 0 COLOR history 255 255 0 COLOR mark1 0 255 0 COLOR markOff 0 255 255 COLOR mark2 0 0 255 COLOR kill 255 0 255 ]]

Code: Select all

x = 17, y = 2, rule = B3/S23Super
2A.2B.2C.2D.2E.2F$2A.2B.2C.2D.2E.2F!
[[ COLOR alive 255 0 0 COLOR history 255 255 0 COLOR mark1 0 255 0 COLOR markOff 0 255 255 COLOR mark2 0 0 255 COLOR kill 255 0 255 ]]	

Changing state 2's color via the name of the state doesn't seem to be possible; neither manually-places state 2 cells nor those generated via evolution and aging appear to be affected by it, regardless of whether the target cell state is "history", "HISTORY" or "2". No script error saying this in an illegal element is produced, either. I don't know if such a command has been deprecated or not.

[rowett]

Would it be possible for [R]History state names to also apply to the equivalent states in [R]Super, and possibly vice versa?

No. That would be confusing.

Changing state 2's color via the name of the state doesn't seem to be possible

Fixed, thanks.

[rowett]

PCA patterns also appear to be interacting incorrectly with some bounded grids. PCA_4 is a population conserving rule, so I'd expect that the population in the following pattern would remain constant, but it does not.

Fixed, thanks.

[muzik]

Is it intended that PCA cells can get right next to the boundary in this case? For Margolus and 2-state rules, cells are killed one cell before they can make contact.

Code: Select all

x = 2, y = 2, rule = M0,2,1,3,8,5,6,7,4,9,10,11,12,13,14,15
$bo!
[[ SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 ]]

Code: Select all

x = 2, y = 2, rule = MAPAP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/w
$bo!
[[ SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 ]]

Code: Select all

x = 2, y = 2, rule = PCA_1
$.B!
[[ SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 ]]

This might be a directional thing, since they do die one cell before the boundary at the bottom (the births and deaths statistics still differ from the first two example patterns, though):

Code: Select all

x = 2, y = 2, rule = PCA_1
$.A!
[[ SHOWGENSTATS MAXGRIDSIZE 9 Y 255 STARTFROM 254 ]]

Also, when mousing over the gray cells outside of the boundary, "dead" is displayed in the bottom left coordinates display. I think this is incorrect, since these are not typical dead cells; rather, [boundary] should be displayed in this situation similarly to what happens for cells at the edges of bounded grids when moused over.

Manually using the Go To Gen command for an empty pattern results in one generation elapsing and "Going to generation n" being displayed, which doesn't seem right; it should probably behave the same as STARTFROM and show the same message while staying at T=0.

Code: Select all

x = 1, y = 1, rule = Life
b!

Code: Select all

x = 1, y = 1, rule = Life
b!
[[ STARTFROM 20 ]]

For this pattern, if we increment it using the "Step Back" button that causes the T to reach a more negative value, it correctly gives a "Life ended at" message, but if we reverse the playback back to the forwards direction and use the "normal" Step Back to go backwards to a more negative generation, no such message ends up being displayed. If, after the cell "dies", we then step forward, it will then give the life ended at message.

Code: Select all

x = 2, y = 2, rule = PCA_1
$.H!
[[ REVERSESTART SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 ]]

Also, back to the horrid pulsating example: it's still possible to make it pulse once if we disable WAYPT after hitting play, then wait a few seconds (around when the zoom hits 1.0x or so) and click it again.

Code: Select all

x = 5, y = 11, rule = M0,4,8,3,1,5,6,7,2,9,10,11,12,13,14,15
$2o$2o4$bo2bo3$2o$2o!
[[ GRID MAXGRIDSIZE 14 AUTOFIT STARS COLOR TEXT Lime T 0 "Here we go again..." PAUSE 3 "Press the WAYPT button now!" T 4 "" ]]

[rowett]

Is it intended that PCA cells can get right next to the boundary in this case? For Margolus and 2-state rules, cells are killed one cell before they can make contact.

Yes.

Also, when mousing over the gray cells outside of the boundary, "dead" is displayed in the bottom left coordinates display. I think this is incorrect, since these are not typical dead cells; rather, [boundary] should be displayed in this situation similarly to what happens for cells at the edges of bounded grids when moused over.

Added.

Manually using the Go To Gen command for an empty pattern results in one generation elapsing and "Going to generation n" being displayed, which doesn't seem right; it should probably behave the same as STARTFROM and show the same message while staying at T=0.

Fixed, thanks.

For this pattern, if we increment it using the "Step Back" button that causes the T to reach a more negative value, it correctly gives a "Life ended at" message, but if we reverse the playback back to the forwards direction and use the "normal" Step Back to go backwards to a more negative generation, no such message ends up being displayed.

Fixed, thanks.

[muzik]

After all cells die, it seems that the step size ends up being functionally clamped to 1 regardless of what it's set to:

Code: Select all

x = 2, y = 2, rule = PCA_1
$.B!
[[ SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 STEP 64 ]]

Code: Select all

x = 2, y = 2, rule = PCA_1
$.H!
[[ REVERSESTART SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 STEP 64 ]]

Code: Select all

x = 2, y = 2, rule = MAPAP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/w
$bo!
[[ SHOWGENSTATS MAXGRIDSIZE 9 X -255 STARTFROM 254 STEP 64 ]]

Also, if the Undo sets the viewer back to a point before playback was reversed, the four buttons at the bottom right don't visually update immediately. For the following example, step forward one generation, hit the reverse playback button, step "forward" (backwards, but still the "third" button), then use the Undo button. Stepping forward will cause all of the buttons to "reset" to forward mode, but that should have happened when Undo was pressed if the playback direction was indeed reset (which it is according to Help > Grid).

Code: Select all

x = 2, y = 2, rule = MargSingRot
o!

Code: Select all

x = 2, y = 2, rule = PCA_4
o!

[muzik]

[R]History state 6 cells don't work correctly at grid boundaries, since cells on the other side of that boundary aren't killed by them when they should be. State 6 cells in [R]Super appear to work correctly.

Code: Select all

x = 20, y = 20, rule = B12345678/S012345678History:T20
20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A
$20A$16AF3A!

Code: Select all

x = 20, y = 20, rule = B12345678/S012345678Super:T20
20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A$20A
$20A$16AF3A!

Is this related to the old issue where state-6 cells didn't function correctly for triangular rules and range-1 tripod rules?

Select All also appears to select the boundary cells for the [R]Super pattern, but not the [R]History pattern.

When [R]Super patterns are deleted at grid boundaries, ghost cells (which become alive cells when selected and manipulated in the right way) are left behind:

Code: Select all

x = 5, y = 4, rule = B3/S23History
.A2.A$A$A3.A$4A!
[[ GRID MAXGRIDSIZE 9 STARTFROM 500 X -256 ]]

Code: Select all

x = 5, y = 4, rule = B3/S23Super
.A2.A$A$A3.A$4A!
[[ GRID MAXGRIDSIZE 9 STARTFROM 500 X -256 ]]

I also rediscovered this old bug when testing the above:

Code: Select all

x = 16, y = 15, rule = LifeHistory
13.A$3.2A8.A.A$3.2A8.2A5$8D$8D$8D$8D5.2A$8D5.2A$8D$8D$8D!
[[ KILLGLIDERS ]]

Layers appear to function incorrectly in [R]Super, since every single state appears at the exact same height:

Code: Select all

x = 23, y = 3, rule = LifeHistory
3A.3B.3C.3D.3E.3F$3A.3B.3C.3D.3E.3F$3A.3B.3C.3D.3E.3F!
[[ ZOOM 20 Y 8 LAYERS 10 ]]

Code: Select all

x = 23, y = 3, rule = LifeSuper
3A.3B.3C.3D.3E.3F$3A.3B.3C.3D.3E.3F$3A.3B.3C.3D.3E.3F!
[[ ZOOM 20 Y 8 LAYERS 10 ]]

If we select this entire pattern and use a random fill on it, the state-6 cells that were in the center previously still kill every alive cell in the pattern and prevent any cells from being born where they previously were. Rewinding to generation 0 and playing it again seems to return to the intended behaviour.

Code: Select all

x = 12, y = 7, rule = LifeHistory
A$.10F$.10F$.10F$.10F$.10F$11.A!

Since [R]History has its own set of icons in Golly, could these also be listed in LifeViewer under Info > Pattern?

And finally for [R]History/[R]Super sightings: for the top pattern, Identify gives the whole configuration a 3x4 bounding box, seemingly including the state-6 cells and also adding an extra layer of empty cells around its period map, but for the bottom example, the gray cells are not counted and the period map still only has a single layer of cells around it.

Code: Select all

x = 5, y = 4, rule = B1/SVHistory
3.F$2.FAF$2.F.F$3.F!

Code: Select all

x = 4, y = 4, rule = B2/SVHistory
.2F$F.AF$FA.F$.2F!

[muzik]

I'm not sure if Klein bottles are being processed correctly for triangular grids. For the two following square-grid patterns, the left and right sides of the grid map to each other without a twist, and so the pattern emerges without any mirroring.

Code: Select all

x = 7, y = 12, rule = B3/S23:T20
bo2bo$o$o3bo$4o4$6o$o5bo$o$bo4bo$3b2o!

Code: Select all

x = 7, y = 12, rule = B3/S23:K20*,20
bo2bo$o$o3bo$4o4$6o$o5bo$o$bo4bo$3b2o!

So, to my understanding, the following two patterns should behave identically:

Code: Select all

x = 5, y = 9, rule = B4/S456L:T20
$b4o$b4o3$o$ob3o$ob3o$o!

Code: Select all

x = 5, y = 9, rule = B4/S456L:K20*,20
$b4o$b4o3$o$ob3o$ob3o$o!

However, for the Klein bottle example, both spaceships crash and die for some reason. The behaviour actually seems identical to that of a Klein bottle with the left and right twisted:

Code: Select all

x = 5, y = 9, rule = B4/S456L:K20,20*
$b4o$b4o3$o$ob3o$ob3o$o!

The twist for the top and bottom does seem to be processed correctly - if we draw a line of four triangles at the top-right, it causes birth at the bottom left for K20*,20, and the bottom right for K20,20*.

----

I've also been wondering recently if triangular rule notation might end up conflicting with BSFKL rulestrings when that rulespace finally gets added, since both of them end with L. How would LifeViewer know to differentiate between a triangular BSFK rule (a subset of BSFKL rules whose notation would likely have a conversion process for backwards compatibility's sake) and a BSFKL rule which didn't have anything defined for L, meaning that it had L as its final character? While conflicts would arguably only arise if the rulestring isn't perfectly formatted (i.e. contained no slashes), the use of "TR" was rejected back in 2019 despite it too never being a problem for perfectly-formatted rulestrings, so I'm not sure how it will end up working.

----

Identify used on this oscillator has large empty regions in the period map around the oscillator in all directions:

Code: Select all

#CXRLE Pos=-2,-2
x = 0, y = 0, rule = B1z/SL:T6
$bo!

Compare to the following, where those empty regions do not exist and there's only one layer of dead cells instead of two or more:

Code: Select all

x = 0, y = 0, rule = B1z/SL
$bo!

[PHPBB12345]

Suggestion: Script command for repeated recipe

[rowett]

Suggestion: Script command for repeated recipe

Please give me an example of what you want.

[muzik]

For a break from the disgusting amount of bug reports from the other day, would it be possible to reduce the initial width of the graph to a much smaller number? Having it initially be around 600 makes it very hard to use for visually tracking the properties of low-period objects, for example, since everything is crushed to the left and is hard to read. Could the initial width be 10 or so, or even 0 like the height is for empty patterns?

Code: Select all

x = 27, y = 16, rule = B3/S23
21bo$19b3o$18bo$18b2o3$11bobo$15bobo$11bobo3bo6b2o$14b2obo5bo2bo$4b2o
15bo2bobo$2bob2o19bo$bo19bob2o$4bo17bo$2obo5b2o$2o7b2o!
[[ STARTFROM 32 GRAPH ]]

[Sokwe]

Custom cell colors appear to no longer be working in at least some rules. Example:

Code: Select all

#C [[ COLOR 0 White ]]
#C [[ COLOR 1 Black ]]
#C [[ COLOR 2 Darkgray ]]
x = 7, y = 6, rule = immigration
.2A$A$3.A$.2A2.2B$4.2B$6.B!

[rowett]

Custom cell colors appear to no longer be working in at least some rules.

Fixed, thanks!

[rowett]

After all cells die, it seems that the step size ends up being functionally clamped to 1 regardless of what it's set to

Fixed, thanks.

[rowett]

[R]History state 6 cells don't work correctly at grid boundaries, since cells on the other side of that boundary aren't killed by them when they should be.

Fixed, thanks.

Select All also appears to select the boundary cells for the [R]Super pattern, but not the [R]History pattern.

Fixed, thanks.

When [R]Super patterns are deleted at grid boundaries, ghost cells (which become alive cells when selected and manipulated in the right way) are left behind.

Fixed, thanks.

Layers appear to function incorrectly in [R]Super, since every single state appears at the exact same height.

This is by design.

If we select this entire pattern and use a random fill on it, the state-6 cells that were in the center previously still kill every alive cell in the pattern and prevent any cells from being born where they previously were.

Fixed, thanks.

[muzik]

Cheers for the fixes! I genuinely can't thank you enough.

Here's a couple of hopefully minor change requests:

- Would it be possible to put the mod transform on its own line separate from Mod? FlipXorYorRotCWorCCW patterns with three-digit periods or higher have the ends cut off, which isn't ideal.

Code: Select all

x = 254, y = 254, rule = B2e/S
o$bo$2bo$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16b
o$17bo$18bo$19bo$20bo$21bo$22bo$23bo$24bo$25bo$26bo$27bo$28bo$29bo$30b
o$31bo$32bo$33bo$34bo$35bo$36bo$37bo$38bo$39bo$40bo$41bo$42bo$43bo$44b
o$45bo$46bo$47bo$48bo$49bo$50bo$51bo$52bo$53bo$54bo$55bo$56bo$57bo$58b
o$59bo$60bo$61bo$62bo$63bo$64bo$65bo$66bo$67bo$68bo$69bo$70bo$71bo$72b
o$73bo$74bo$75bo$76bo$77bo$78bo$79bo$80bo$81bo$82bo$83bo$84bo$85bo$86b
o$87bo$88bo$89bo$90bo$91bo$92bo$93bo$94bo$95bo$96bo$97bo$98bo$99bo$100b
o$101bo$102bo$103bo$104bo$105bo$106bo$107bo$108bo$109bo$110bo$111bo$112b
o$113bo$114bo$115bo$116bo$117bo$118bo$119bo$120bo$121bo$122bo$123bo$124b
o$125bo$126bo$127bo$128bo$129bo$130bo$131bo$132bo$133bo$134bo$135bo$136b
o$137bo$138bo$139bo$140bo$141bo$142bo$143bo$144bo$145bo$146bo$147bo$148b
o$149bo$150bo$151bo$152bo$153bo$154bo$155bo$156bo$157bo$158bo$159bo$160b
o$161bo$162bo$163bo$164bo$165bo$166bo$167bo$168bo$169bo$170bo$171bo$172b
o$173bo$174bo$175bo$176bo$177bo$178bo$179bo$180bo$181bo$182bo$183bo$184b
o$185bo$186bo$187bo$188bo$189bo$190bo$191bo$192bo$193bo$194bo$195bo$196b
o$197bo$198bo$199bo$200bo$201bo$202bo$203bo$204bo$205bo$206bo$207bo$208b
o$209bo$210bo$211bo$212bo$213bo$214bo$215bo$216bo$217bo$218bo$219bo$220b
o$221bo$222bo$223bo$224bo$225bo$226bo$227bo$228bo$229bo$230bo$231bo$232b
o$233bo$234bo$235bo$236bo$237bo$238bo$239bo$240bo$241bo$242bo$243bo$244b
o$245bo$246bo$247bo$248bo$249bo$250bo$251bo$252bo$253bo!

Also, would it be possible for 100.00% to be displayed as straight-up 100% in the period tables menu if it actually is 100%, like how the volatility output omits the zeros at the end in such cases? The above pattern can be used as a test case for 100% with no trailing zeros. Here's a test pattern where 100.00% would be used instead of pure 100% due to the presence of a minority of lower-period cells in the overall configuration:

Code: Select all

x = 513, y = 513, rule = B2e/S
o$bo2$3bo$4bo$5bo$6bo$7bo$8bo$9bo$10bo$11bo$12bo$13bo$14bo$15bo$16bo$
17bo$18bo$19bo$20bo$21bo$22bo$23bo$24bo$25bo$26bo$27bo$28bo$29bo$30bo$
31bo$32bo$33bo$34bo$35bo$36bo$37bo$38bo$39bo$40bo$41bo$42bo$43bo$44bo$
45bo$46bo$47bo$48bo$49bo$50bo$51bo$52bo$53bo$54bo$55bo$56bo$57bo$58bo$
59bo$60bo$61bo$62bo$63bo$64bo$65bo$66bo$67bo$68bo$69bo$70bo$71bo$72bo$
73bo$74bo$75bo$76bo$77bo$78bo$79bo$80bo$81bo$82bo$83bo$84bo$85bo$86bo$
87bo$88bo$89bo$90bo$91bo$92bo$93bo$94bo$95bo$96bo$97bo$98bo$99bo$100bo
$101bo$102bo$103bo$104bo$105bo$106bo$107bo$108bo$109bo$110bo$111bo$
112bo$113bo$114bo$115bo$116bo$117bo$118bo$119bo$120bo$121bo$122bo$123b
o$124bo$125bo$126bo$127bo$128bo$129bo$130bo$131bo$132bo$133bo$134bo$
135bo$136bo$137bo$138bo$139bo$140bo$141bo$142bo$143bo$144bo$145bo$146b
o$147bo$148bo$149bo$150bo$151bo$152bo$153bo$154bo$155bo$156bo$157bo$
158bo$159bo$160bo$161bo$162bo$163bo$164bo$165bo$166bo$167bo$168bo$169b
o$170bo$171bo$172bo$173bo$174bo$175bo$176bo$177bo$178bo$179bo$180bo$
181bo$182bo$183bo$184bo$185bo$186bo$187bo$188bo$189bo$190bo$191bo$192b
o$193bo$194bo$195bo$196bo$197bo$198bo$199bo$200bo$201bo$202bo$203bo$
204bo$205bo$206bo$207bo$208bo$209bo$210bo$211bo$212bo$213bo$214bo$215b
o$216bo$217bo$218bo$219bo$220bo$221bo$222bo$223bo$224bo$225bo$226bo$
227bo$228bo$229bo$230bo$231bo$232bo$233bo$234bo$235bo$236bo$237bo$238b
o$239bo$240bo$241bo$242bo$243bo$244bo$245bo$246bo$247bo$248bo$249bo$
250bo$251bo$252bo$253bo$254bo$255bo$256bo$257bo$258bo$259bo$260bo$261b
o$262bo$263bo$264bo$265bo$266bo$267bo$268bo$269bo$270bo$271bo$272bo$
273bo$274bo$275bo$276bo$277bo$278bo$279bo$280bo$281bo$282bo$283bo$284b
o$285bo$286bo$287bo$288bo$289bo$290bo$291bo$292bo$293bo$294bo$295bo$
296bo$297bo$298bo$299bo$300bo$301bo$302bo$303bo$304bo$305bo$306bo$307b
o$308bo$309bo$310bo$311bo$312bo$313bo$314bo$315bo$316bo$317bo$318bo$
319bo$320bo$321bo$322bo$323bo$324bo$325bo$326bo$327bo$328bo$329bo$330b
o$331bo$332bo$333bo$334bo$335bo$336bo$337bo$338bo$339bo$340bo$341bo$
342bo$343bo$344bo$345bo$346bo$347bo$348bo$349bo$350bo$351bo$352bo$353b
o$354bo$355bo$356bo$357bo$358bo$359bo$360bo$361bo$362bo$363bo$364bo$
365bo$366bo$367bo$368bo$369bo$370bo$371bo$372bo$373bo$374bo$375bo$376b
o$377bo$378bo$379bo$380bo$381bo$382bo$383bo$384bo$385bo$386bo$387bo$
388bo$389bo$390bo$391bo$392bo$393bo$394bo$395bo$396bo$397bo$398bo$399b
o$400bo$401bo$402bo$403bo$404bo$405bo$406bo$407bo$408bo$409bo$410bo$
411bo$412bo$413bo$414bo$415bo$416bo$417bo$418bo$419bo$420bo$421bo$422b
o$423bo$424bo$425bo$426bo$427bo$428bo$429bo$430bo$431bo$432bo$433bo$
434bo$435bo$436bo$437bo$438bo$439bo$440bo$441bo$442bo$443bo$444bo$445b
o$446bo$447bo$448bo$449bo$450bo$451bo$452bo$453bo$454bo$455bo$456bo$
457bo$458bo$459bo$460bo$461bo$462bo$463bo$464bo$465bo$466bo$467bo$468b
o$469bo$470bo$471bo$472bo$473bo$474bo$475bo$476bo$477bo$478bo$479bo$
480bo$481bo$482bo$483bo$484bo$485bo$486bo$487bo$488bo$489bo$490bo$491b
o$492bo$493bo$494bo$495bo$496bo$497bo$498bo$499bo$500bo$501bo$502bo$
503bo$504bo$505bo$506bo$507bo$508bo$509bo$510bo$511bo$512bo!

[muzik]

EDIT 2: For patterns that die out with paste commands yet to be executed, "Empty Pattern" is displayed instead of "Life ended at" - although since "Life ended at" is meant to not display in normal playback if future paste commands exist I'm not sure what the behaviour here should be:

Code: Select all

x = 1, y = 1, rule = B3/S23
3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo!

Code: Select all

x = 1, y = 1, rule = B3/S23
3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo!
[[ PASTET EVERY 12 12 PASTE 3bo2bo$3bo2bo$2b6o$10o$2b6o$2b6o$10o$2b6o$3bo2bo$3bo2bo! 0 0 ]]

Not sure how I managed to forget to mention the very important detail that this is what happens when you use Identify, not play it normally. Are there any situations where "Empty Pattern" should arise intentionally, anyway?

----

I also assume that the viewer pausing at T=1 when Play is pressed for empty patterns is a known issue? It's already obvious from "New Pattern" that the pattern is devoid of any empty cells, so pausing immediately doesn't make much sense to me.

Code: Select all

x = 1, y = 1, rule = B3/S23
!