Pattern viewer for forum threads

[muzik]

I've managed to find a massive crop of bugs and other anomalies mostly pertaining to the Margolus and PCA rulespaces today, but want to hold off on reporting them for a bit as to not overload this thread with an uncontrollable growing list of unresolved issues (as well as to make sure more people see the menu changes suggestion I posted earlier - I'd also like to hear your opinion on it).

----

Here's one unrelated to Margolus/PCA: Identify still seems to not be detecting the mod of certain higher-range Generations patterns. I've selected the following examples from the original 2017 "Larger than Life" thread. Here's a RRO - the mod is detected for two of these placed in a loop, but not a lone unit:

Code: Select all

x = 17, y = 16, rule = R3,C9,M0,S6..8,B6..7,NM
2.E2.F$4.GF3.E$2.G2.3FG.EC2.C$2.G5FG.2CE3.C$.FE5HFG2FDE$.HE.4H.FDF4D$
.G6.4F.3D$G4.3HFGF.A2D$.H5.2GB2.2DA$.H4.A.2EB2D.2AC$H5.A.4B2.C2A$6.A.
B.4B3A$6.A.2B4.2A$6.A2.2B2.BA$7.2A5.A$11.A!

Code: Select all

x = 39, y = 67, rule = R3,C9,M0,S6..8,B6..7,NM
5.A$2.A5.2A$2.AB2.2B2.A$.2A4.2B.A$3A4B.B.A$2AC2.4B.A5.H$C2A.2DB2E.A4.
H$2.A2D2.B2G5.H$2.2DA.FGF3H4.G$.3D.4F6.G$.4DFDF.4H.EH$3.ED2FGF5HEF$C3.
E2C.G5FG$2.C2.CE.G3F2.G$7.E3.FG$11.F2.E36$24.E2.F$26.GF3.E$24.G2.3FG.
EC2.C$24.G5FG.2CE3.C$23.FE5HFG2FDE$23.HE.4H.FDF4D$23.G6.4F.3D$22.G4.3H
FGF.A2D$23.H5.2GB2.2DA$23.H4.A.2EB2D.2AC$22.H5.A.4B2.C2A$28.A.B.4B3A$
28.A.2B4.2A$28.A2.2B2.BA$29.2A5.A$33.A!

The following orthogonal spaceship also appears to not have its half-mod detected: (EDIT: I've somehow managed to get LifeViewer to recognise that it had a mod of 13, and it now seems to permanently remember this.) (EDIT2: Rotating it anticlockwise seems to get LifeViewer to forget what its mod is.)

Code: Select all

x = 29, y = 23, rule = R2,C6,M0,S6..10,B7..10,NM
12.2A$11.4A$9.3A2C3A$8.3A4C2A$8.3AC2EC2A$9.BAE2C2A$8.D3E2BD$8.C3E2.E$
8.D3E14.2E$9.BA2ED6.3E2.4A$10.3AD5.E4.2A2BA$10.3A5.E6.A2BA$18.E5.D4A$
17.E6.E.2A$.2E14.E5.E$E17.ED.E$E18.2E$3.2D$.DE2CD$.C3EBC$.DB2EB$2.D2B
D$3.C!

This issue appears to be the most prominent for diagonal glide-reflective spaceships.

Code: Select all

x = 8, y = 8, rule = R2,C3,M0,S4..4,B4..4,NM
2$2.2B$2.3A$2.B2A$2.B!

Code: Select all

x = 8, y = 8, rule = R2,C4,M1,S4..4,B4..4,NM
5.2A$4.3BA$6.CA$6.CA$6.C!

Code: Select all

x = 23, y = 24, rule = R2,C6,M0,S5..7,B5..7,NM
18.A$16.2B2ABA$16.B3C3A$15.ED3C3A$15.ED.2CD2A$17.3E2BA$17.3E2C$18.2ED
$19.2D!

Code: Select all

x = 10, y = 15, rule = R2,C5,M0,S6..8,B5..7,NM
2.4A$.6A$2ACABC3A$BCB2DBC3A$2BA3D2B2A$B2C2D2.2B$4.AD2B$2.C.A4B$4.2D3B
$.D.2D.3BA$3.3D2B.A$.AC4B.A$.2A4BA$.2A3B.A$2.A2.2A!

Code: Select all

x = 47, y = 73, rule = R2,C6,M0,S6..7,B5..8,NM
5.2A$4.3AB$2.2A2BAC$.2A2BCA2C17.4A$.A3BC4D15.3ABA$2A2BCD2EDE15.D2AB2A
$2AC.2D2ED15.2EA2CAB$A2B2DE19.D.D2CAB$.B3C21.E.E3CB$2.CD2E21.2ED2CBA$
4.E22.2E3CB$29.2DCB$29.E48$39.2A$38.5A$38.B2AB2A$37.3CA2B2A$36.C4D2CB
2A$35.CDE4D2CB2A$35.C3D2.D2C3A$36.C.D3.EBDB$38.E3.2ECD$42.3EC$43.2ED$
43.D.D$45.D!

Code: Select all

x = 12, y = 13, rule = R2,C6,M0,S7..8,B5..8,NM
.5A$.BA2B2A$.CA3B2A$DCAC3B2A$2E2D2C2B2A$ECDED2CB2A$3.BDB2CABA$E4.2D2C
B2A$2.EDE.D2CABA$4.DED4B$5.E.2DC$7.ED$7.2E!

Code: Select all

x = 19, y = 20, rule = R3,C8,M0,S1..1,B6..7,NM
11.3A$10.2B2.3A$9.B3.2B3A$8.3C3.2B.A$7.2D2A3C2B$6.D.B.2D3CB2.A$5.3EB2.
2D.C.B.A$4.2F2B3E2D3.BA$3.F.D.2F3ED2ACB$2.3GD2.2F.EAD.C$3.2D3G2F2.ADC
$2.F3.3GF2CED$2.F5.GCF.E$2F7.CFE$7.2EGF$6.E2.G$6.E.G$4.2G$3.G$3.G!

Code: Select all

x = 19, y = 23, rule = R3,C8,M0,S1..1,B6..7,NM
12.2A$11.A3.2A$10.3B3.2A$9.2C2.3B2A$8.CBA.2C3BA$6.B3DA2.2C.B.A$6.2ECB
3D2C3.A$5.ED.C2E3DC2.BA$3.C3F.C.2E.D.CAB$3.2GE.3F2E3BCB$2.G2.E2G3FEB.
DC$4.2E.2G.FCE.DA$3.F3.2G3.ED$.G6.GADFE$.D6.EGEF$6.3FGF$9.G$7.G.E3$6.
F2$G!

Code: Select all

x = 21, y = 28, rule = R3,C6,M0,S6..7,B6..7,NM
.2E9.2E2$14.E$.2E2$3.E$8.C2.BCE2A$7.2C.DE.C2.2A$8.DE2D2BCB.A$8.2DBA2D
2B2A$7.E.DBA2DCB2A$5.E.2C2.2DBC2.A$12.2EC2A$10.C2.E2$6.E3$6.D7.2A$2.E
.2E2.D3.BD2A2BA$D2.E7.C.D2.4A$D.E.2E4.3ED3CA.2A$D.3E4.4E4CB2.A$.2C3E3.
E3.2C.AB2A$2.2C3E.E.B2CD.2AB$.D7.DBDC3AB$3.3D.D2.C3BA$13.A!

Code: Select all

x = 12, y = 20, rule = R2,C6,M0,S7..8,B5..8,NM
2.4A$2.B4A$.CBAB3A$.2D2C2B2A$EDBCDC2B2A$2.2EACA2B2A$.D.2E.2C2BA$3.DCD
EC2B.A$5.CDC4A$6.DE2CB$7.EDC$7.E2D$7.E$7.E2$6.E$6.E3$3.2E!

Code: Select all

x = 76, y = 105, rule = R4,C10,M0,S7..8,B7..8,NM
46.3A$45.2A.2A$44.2A3.2A$44.2A3.2A$43.9A$43.BA6.2A$42.B2A6.AB$43.2A.3C
2.2A$41.B.2A5C.2AB$44.3C2.2C2.B$44.D6C$44.3C2.CD5A$42.D.3C2.ACD4.A$41.
D2.C3EA.CD$41.B2.C4E.C3B$42.2B2E.2E2.3B$44.2E.2E3.D.B$43.2F3E2F5B$44.
2E.2EBF3B$42.F.2E2GE3CD3.A$41.D2.E3G2E2CD2.A$8.7A27.D2.3G.E2D2.2A$44.
H.2G3HD$7.A2.3B3.A26.H.2G.D$7.A2.3B30.H2G2I2.F$8.4C2B3.A26.G.3IF$6.C3.
2B.2B3.A26.F3I$10.2B.B2C3.A27.5I$7.A.3D2.2B3.A23.H9.H$2.C4.2D.B2D.2BC
2.A23.H$6.3DA.2D3BCB.A$.C3.4D3.2D5BA19.H.H4.I.2I.I$4.3DED2E2DE3.C.A29.
2I2HF$4.D2E2D2.F.2D4.A21.I6.2I.CHCFAB4A$2.E.5D2.F2GD2.CA22.3I3.I.3GHG
CF5A$.E2.3D2GF.F.2DG.C23.3I2.I4.C2G2C5A$E3.3DG2F.F.ICGH23.4I.2IB2.D2C
GCD.2A.A$.C2.5F2.FIE2.G3.I20.3I2.I3CGEG.CD.2A.A$3.5F.3HI2H2.G2.I22.I.
2I.5GA2E.D3A$2.C5F5H25.H3.C3I.F2H2GC2EF.3A$2.C2FG2FHF2.H32.2DFHE.2CEF
BC$.2C5F6H27.H3.2DH2EABAEFA$3.4F2.3HI3H.2F.I22.A.2D.FE2F3E$C2.D6F2.I2F
H4.I22.AB2DB2E2BA2E$E2.3D.G2F3.I2F2G.I22.A2.2D2BE2.2EA2.D$.E.4D2G4.3F
2G27.B2D2.3E$2.2E7DGDF2GD.C22.A2C.3B2.C5.D$3.2D4E4D3FD2.C21.A2.2CBCDC
4.D$3.10D3FD.E26.3B$C3.10D.2D28.3B$6.10D2E27.3B$.C6.6D.2D25.A7.A$2.C4.
A4.2D.2D.A$7.A2.2B4DB2.A$6.C3.3B3DB2.C$8.C.7B.C$10.C6B$10.BCBC2BC$10.
7B$7.A3.5B3.A$12.3B$8.A9.A2$10.7A22$58.2I2.2I$63.GIG.3G$62.G8.F$65.2H
4.FG$65.2HI3.F.G$65.4H2.F2.G$65.3HI2H4.G$66.6H$69.H.2H$62.G2.H.6H$65.
H.6H$57.I9.6H$63.G2.3HI2H$68.I6.G$64.G9.G$66.GI4.G4$56.I6.I!

For comparison, here are diagonal glide-reflective spaceships which are correctly identified as having a mod half of their period:

Code: Select all

x = 6, y = 8, rule = R2,C3,M0,S3..5,B4..4,NM
.2A$.2A$B2AB$.2A$.A3$5.B!

Code: Select all

x = 25, y = 29, rule = R2,C14,M0,S2..3,B4..4,NM
21.3A$21.B2.A$17.A.2D3B$17.A3D3B$11.E3.E.AF3DB$12.3F.2H3F2.A$8.G.2H3F
3H3F2A$8.E3H3FJ3HFB2.A$4.E.2FEH.JH2L3J3D2B$.C2.C3FH3J3L3J.D.2B$2.2DFG
2.H2.J.3LJB.D2B$.2DFDG2HJH5.2BD2B2.A$.2DF.G3H7.2B2.A$C2.D2F.DH5.AK2B.
A$2.B.3D5.3L4A$3.C.2D5.3L$7.C4.3L$15.K3$11.2KM$3.I2.J3.2L$4.2J4.2L$4.
2JL3ML$5.JL.JLIK$4.I.J2LJ$5.H.3J$7.2J.I$6.I!

Code: Select all

x = 27, y = 20, rule = R2,C14,M0,S2..3,B4..4,NM
9.D3.D$10.3E2.D$9.2E2G2E$9.2E.G2E$8.FD2H2GE$6.G.2H2JI$7.H.J2K2I6.2A$6.
2H2J2LK2I4.A2BA$4.G3HJL2M2K2I2.AB2C.A$5.FKILM2.MLK2I.HBCDCBA$.F.GHIJL
M4.M.K2I2A2EDC2A$2.3G2I2L5.MLKJI3FEDCBA$.G.HI2JIL.I2.2MLKJIGAFEDCBA$.
GH2.F2K4.J2L2JIHG.FDCBA$F3GJ2.H4.JCKDGHGE2BCBA$.F2IJ.I6.2JD2G.2A2B$3.
J2L7.A3DAF2A2.A$2.2I.M8.BCB$3.H2L8.B.B$6.K.M5.3A!

Code: Select all

x = 20, y = 21, rule = R2,C6,M0,S2..4,B4..4,NM
15.3A$15.B2.A$11.A.2D3B.A$3.A7.A3D3B.A$2.A.A6.A.3D3BA2$16.B$.3A12.3A$
.EB.A8.B2C.A$.3B.A5.D3E.3A$A2.DBA7.BA.A$A2DB2A6.3E.D$.3D8.3E$C12.2E$14.
2E$16.E$2.3A9.E$10.EB3E.D$11.2B2E$11.3B.D$10.A!

Code: Select all

x = 15, y = 11, rule = R2,C6,M0,S3..4,B3..4,NN
12.2A$11.D3A$10.E4A$8.D3EDA$7.CACEC$2.E4.3AD$.D6.AC$CE2D$.C.D.E$B.CED
$.B.C!

Code: Select all

x = 23, y = 20, rule = R3,C5,M0,S4..8,B6..6,NM
3.B2.B$6.2B.D$3.3C5.D$2.CACA$4.2C$.B2.C$4.2B13.2A$2.DB12.A$C.D6.D5.A.
4A$2.2D10.DA.A4.B$3.4D8.3A.C$C2.2D11.A.3C$3.3D14.3C$.C5.C11.4C$20.C$17.
2A2C$17.4A$15.2D4A$17.4A$17.4A!

----

The Generations issue with Identify saying "Empty Pattern" rather than "Life ended at" still exists if the theme is changed to certain themes (Catagolue, Generations and Blues all seem to work for this, but MCell does not) before identifying.

Code: Select all

x = 77, y = 7, rule = 23/3/143
4.A.B.F.J.N.R.V.pB.pF.pJ.pN.pR.pV.qB.qF.qJ.qN.qR.qV.rB.rF.rJ.rN.rR.rV
.sB.sF.sJ.sN.sR.sV.tB.tF.tJ.tN.tR.tV$2.3ACBGFKJONSRWVpCpBpGpFpKpJpOpN
pSpRpWpVqCqBqGqFqKqJqOqNqSqRqWqVrCrBrGrFrKrJrOrNrSrRrWrVsCsBsGsFsKsJsO
sNsSsRsWsVtCtBtGtFtKtJtOtNtStR.tV$2A2D2H2L2P2T2X2pD2pH2pL2pP2pT2pX2qD
2qH2qL2qP2qT2qX2rD2rH2rL2rP2rT2rX2sD2sH2sL2sP2sT2sX2tD2tH2tL2tP2tT$AB
DFHJLNPRTVXpBpDpFpHpJpLpNpPpRpTpVpXqBqDqFqHqJqLqNqPqRqTqVqXrBrDrFrHrJ
rLrNrPrRrTrVrXsBsDsFsHsJsLsNsPsRsTsVsXtBtDtFtHtJtLtNtPtRtTtV$A2B2F2J2N
2R2V2pB2pF2pJ2pN2pR2pV2qB2qF2qJ2qN2qR2qV2rB2rF2rJ2rN2rR2rV2sB2sF2sJ2sN
2sR2sV2tB2tF2tJ2tN2tR2tV$.5AEDIHMLQPUTpAXpEpDpIpHpMpLpQpPpUpTqApXqEqD
qIqHqMqLqQqPqUqTrAqXrErDrIrHrMrLrQrPrUrTsArXsEsDsIsHsMsLsQsPsUsTtAsXtE
tDtItHtMtLtQtPtUtT$3.A.A.D.H.L.P.T.X.pD.pH.pL.pP.pT.pX.qD.qH.qL.qP.qT
.qX.rD.rH.rL.rP.rT.rX.sD.sH.sL.sP.sT.sX.tD.tH.tL.tP.tT!
[[ MAXGRIDSIZE 9 COLOR DEAD Black COLOR DYING 64 64 64 COLOR DYINGRAMP 32 32 32 COLOR ALIVE White STARTFROM 430 X -215 ]]

If we evolve the pattern to generation 435, either through use or Identify or running it stepwise, then go back to generation 434 and attempt to identify it, the Identifying... text will appear, but identification will not happen and the viewer remains interactive.

[rowett]

For Margolus rules, GRIDMAJOR is set to 2 regardless of whatever theme is currently in use, which causes a couple of oddities

Fixed, thanks.

I've also wondered for a while if the GRID and GRIDMAJOR colors for the Margolus theme are the wrong way round.

I reversed them, it does look better for larger GRIDMAJOR sizes.

[rowett]

in Help > Info, would it be possible to move the information for Stars somewhere above Randomize so it can be closer to other elements with configurable colors?

Yes, done.

[rowett]

I've checked this a couple times in recent builds and Help > Info > Pattern doesn't seem to include anything about icons. Has this been removed, or has it simply broken within the past month?

It was disabled but has now returned with the icon images (just in Help and only for size 31 icons for now).

Code: Select all

x = 1, y = 1, rule = Langtons-Ant
E!

[rowett]

If we evolve the pattern to generation 435, either through use or Identify or running it stepwise, then go back to generation 434 and attempt to identify it, the Identifying... text will appear, but identification will not happen and the viewer remains interactive.

Fixed, thanks. The issue was that Step Back was not resetting the "everything died" flag so no "Life ended at" message appeared (which normally would clear the "Identifying..." message).

[muzik]

Also, I recall a bug I was unable to reproduce where PCA cells turned blue despite this not being specified in the script. Let's see if they turn green instead if you open the 2013-2023 pattern, close it, and then open the following:

EDIT: Funnily enough, no, that doesn't happen, at least not with build 863. I thought it'd have been related, but perhaps this was just another weird one-time occurrence.

I've finally found a way to reproduce this:

Code: Select all

x = 0, y = 60, rule = PCA_1:P16,64
9o!
[[ COLOR BACKGROUND 16 0 0 COLOR DEAD 192 0 0 COLOR DEADRAMP 128 0 0 ]]

Code: Select all

#N Blues
x = 28, y = 14, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3H3.3B2.3L3F2.3M3.3G$3H3.
3B2.3L3F2.3M3.3G$3H3.3B2.3L3F2.3M3.3G$3.3D16.3N$3.3D16.3N$3.3D7.2E7.3N
$13.2E$11.2J2O2J$11.2J2O2J$13.2E$13.2E!
[[ GRID
COLOR N 0 128 255
COLOR E 0 255 128
COLOR S 128 0 255
COLOR W 255 0 128
COLOR NS 0 0 255
COLOR EW 128 128 255
COLOR NW 96 96 192
COLOR NE 0 192 192
COLOR ES 96 128 192
COLOR SW 192 0 192
COLOR NEW 128 224 255
COLOR NES 128 255 224
COLOR ESW 224 128 255
COLOR NSW 255 128 224
COLOR NESW 224 224 255
COLOR BACKGROUND 0 0 0
COLOR DEAD 0 0 128
COLOR DEADRAMP 0 0 47
]]

Opening the first viewer has the PCA cells set to their default colors. However, if we open the first viewer, then the second viewer, and then reopen the first viewer, LifeViewer seems to remember the colors from the second viewer and applies these to the first viewer.

I assume that the bug that the first viewer intends to demonstrate (history cells being cleared when a PCA pattern dies) is known and not currently a priority issue to fix?

The "Identifying..." bug also happens for this PCA example if you go to the generation it dies out (preferably stepwise), undo one generation (stepping back will not work as the killing of cells is irreversible), and then identify it the generation before it crashes into the border. (I tried stepping forward to the generation before it dies without having it die first and having to rewind, and got "Empty Pattern" once, but I can't seem to reproduce this.)

Also, another PCA theme-related thing I've noticed: using scripts to change the color of a cell type by name correctly results in the theme being considered a custom theme, but changing a cell type using its numeric state value does not change the theme to a custom theme, and that changed color persists across all themes.

Code: Select all

x = 28, y = 14, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3H3.3B2.3L3F2.3M3.3G$3H3.
3B2.3L3F2.3M3.3G$3H3.3B2.3L3F2.3M3.3G$3.3D16.3N$3.3D16.3N$3.3D7.2E7.3N
$13.2E$11.2J2O2J$11.2J2O2J$13.2E$13.2E!
[[ COLOR NESW 255 255 255 ]]

Code: Select all

x = 28, y = 14, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3H3.3B2.3L3F2.3M3.3G$3H3.
3B2.3L3F2.3M3.3G$3H3.3B2.3L3F2.3M3.3G$3.3D16.3N$3.3D16.3N$3.3D7.2E7.3N
$13.2E$11.2J2O2J$11.2J2O2J$13.2E$13.2E!
[[ COLOR 15 255 255 255 ]]

Generations also has weird behaviour pertaining to theme handling if we change the color of a single cell state. I'd expect that all of these would make the theme into a custom one, especially the first three. I'm not sure if the first three should behave identically though, since I can see configuring individual states without changing the ramp colors and other details being useful.

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ COLOR ALIVE 255 255 255 ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ COLOR alive 255 255 255 ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ COLOR 1 255 255 255 ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ COLOR "dying 2" 255 255 255 ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ COLOR 3 255 255 255 ]]

[muzik]

Here's some bugs with script commands - again, fix these at your own pace, as I don't enjoy overwhelming others with bug reports:

The deaths reported by the T menu and the graph when using this script command setup appear to be incorrect, as we get a death reported every second generation after T=16 that don't all have preceding live cells to go with them (a cell only appears every 16 generations as a result of the pasting and so these are the only cells which should have deaths reported for):

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ GRID PASTET EVERY 16 PASTE o! 2 -2 GRAPH SHOWGENSTATS ]]

Also, this throws up an error about "PASTE -2", which doesn't even show up in the script at all:

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ GRID 
PASTET EVERY 16 PASTE o! 1 -2
PASTET EVERY 16 1 PASTE o! -1 -2
PASTET EVERY 16 2 PASTE o! -2 -1
]]

And finally, when setting UIBACKGROUND = HELP, color squares in help sections such as Help > Colours do not render, with only shadows present.

Code: Select all

x = 7, y = 3, rule = B3/S23
o3b3o$3o2bo$bo!
[[ COLOR UIBACKGROUND DeepSkyBlue COLOR HELP DeepSkyBlue ]]

This does not occur if only one of UIBACKGROUND or HELP is set to a custom color, or if they're set to differing custom colors:

Code: Select all

x = 7, y = 3, rule = B3/S23
o3b3o$3o2bo$bo!
[[ COLOR UIBACKGROUND DeepSkyBlue ]]

Code: Select all

x = 7, y = 3, rule = B3/S23
o3b3o$3o2bo$bo!
[[ COLOR HELP DeepSkyBlue ]]

I also tested this bug with the new icon preview tiles, and the same effect is present. Speaking of which, if the state names are sufficiently long, they can intersect the icon previews, so this will likely need to be resolved somehow:

Code: Select all

x = 17, y = 2, rule = Pulse2
ABCDEFGHIJKLMNOPQ$ABCDEFGHIJKLMNOPQ!

[muzik]

There's currently no point in testing patterns where the specified size is not the same as the actual pattern size. This is known not to work and might have all sorts of other side effects.

Just to ask: "specified size" refers to the x and y values that start every RLE, which, to my understanding, are the bounding box of the pattern (and if it differs from the actual size, selections look weird in bounded grids)? If so, are dead cells that the RLE explicitly specifies also counted in this bounding box?

[rowett]

Opening the first viewer has the PCA cells set to their default colors. However, if we open the first viewer, then the second viewer, and then reopen the first viewer, LifeViewer seems to remember the colors from the second viewer and applies these to the first viewer.

Fixed, thanks.

I assume that the bug that the first viewer intends to demonstrate (history cells being cleared when a PCA pattern dies) is known and not currently a priority issue to fix?

Fixed, thanks.

The "Identifying..." bug also happens for this PCA example if you go to the generation it dies out (preferably stepwise), undo one generation (stepping back will not work as the killing of cells is irreversible), and then identify it the generation before it crashes into the border.

Fixed, thanks.

Also, another PCA theme-related thing I've noticed: using scripts to change the color of a cell type by name correctly results in the theme being considered a custom theme, but changing a cell type using its numeric state value does not change the theme to a custom theme, and that changed color persists across all themes.

Fixed, thanks.

Generations also has weird behaviour pertaining to theme handling if we change the color of a single cell state. I'd expect that all of these would make the theme into a custom one, especially the first three. I'm not sure if the first three should behave identically though, since I can see configuring individual states without changing the ramp colors and other details being useful.

Fixed, thanks.

[rowett]

The deaths reported by the T menu and the graph when using this script command setup appear to be incorrect

Fixed, thanks.

Also, this throws up an error about "PASTE -2", which doesn't even show up in the script at all:

Fixed, thanks.

And finally, when setting UIBACKGROUND = HELP, color squares in help sections such as Help > Colours do not render, with only shadows present.

Fixed, thanks.

I also tested this bug with the new icon preview tiles, and the same effect is present. Speaking of which, if the state names are sufficiently long, they can intersect the icon previews, so this will likely need to be resolved somehow

Fixed, thanks.

[muzik]

Identify's output is hidden inconsistently by the Settings and Help menu when opened. The overview menu shown for still lifes, oscillators and spaceships is hidden. For the periods table, only the "Oscillator period x" top bar and the side buttons are hidden, and for the period map, only the side buttons are hidden.

Code: Select all

x = 16, y = 13, rule = B3/S23
11bo$10b2o$2b3o6b2o5$o$o$o11b2o$12bobo$14bo$14b2o!
[[ COLOR UIBACKGROUND Green ]]

That oscillator also has a very nice "% Rotor" value for period-2 cells. "Active Cells" appears to be mismatched as well - I'd expect 4 and 8, not 3 and 9.

Also, is it intended that History Fit still zooms out the viewer a bunch after all cells die? Said behaviour is quite unexpected - I'd assume that the zoom would remain just sufficient to view the entire envelope.

Code: Select all

x = 12, y = 11, rule = B3/S23
9bo$8b2o$3o6b2o7$10b2o$10b2o!
[[ AUTOFIT HISTORYFIT THEME Book ]]

AutoFit doesn't seem to stay centered for hexagonal patterns (I haven't tested triangular patterns):

Code: Select all

#C [[ AUTOFIT "Minor motion sickness/epilepsy warning" ]]
x = 10, y = 10, rule = 2456/23456/8H
CD4.DC$D2EG.G2ED$CECD2ADCEC$.DED3ADED$3.G4AG$5.3A$5.G2DG$6.ECE$6.D2ED
$7.CDC!

For the first example pattern in this post, if we pause at around T=1000 just after the scripts finish, and then step back one generation, many of the alive cells seem to instantly age by a noticeable extent. (The second example in that post has also been subject to errors for a while now - has a state name been changed or something been deprecated?)

Also, for the following pattern, the cell exactly in the center never seems to age unlike all of the other cells in the pattern. I assume this is due to the fact that it dies each generation, but is instantly pasted back in such that there is no overall change in the pattern?

Code: Select all

#CXRLE Pos=-4,-6
x = 13, y = 13, rule = B3/S23
4b2ob2o$4bo3bo$5b3o2$2o3b3o3b2o$obobo3bobobo$2bobobobobo$obobo3bobobo
$2o3b3o3b2o2$5b3o$4bo3bo$4b2ob2o!
[[
PASTET EVERY 8 0 PASTE bo2$o! 2 -2
PASTET EVERY 8 1 PASTE o2$bo! 1 -2
PASTET EVERY 8 2 PASTE o$2bo! 0 -1
PASTET EVERY 8 3 PASTE 2bo$o! 0 0
PASTET EVERY 8 4 PASTE bo2$o! 1 0
PASTET EVERY 8 5 PASTE o2$bo! 2 0
PASTET EVERY 8 6 PASTE o$2bo! 2 0
PASTET EVERY 8 7 PASTE 2bo$o! 2 -1
]]

For Margolus rules, which using a theme that doesn't have a GRIDMAJOR interval of 2 (i.e. themes that have no major grid lines, as well as custom theme definitions), should Display > Alt GridLines be disabled since non-2 GRIDMAJOR intervals forbid this effect?

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID THEME Catagolue ]]

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID GRIDMAJOR 3 ]]

When setting up the above example, I noticed this: when setting a custom GRIDMAJOR interval, LifeViewer will create a custom theme that's based on the Blues theme, regardless of what rulespace is in use. Shouldn't it try to follow the default theme for each rulespace instead, creating a custom theme which is identical to the default theme in every way except for the GRIDMAJOR interval? (In PCA's case, the theme is only Blues-based if it's the first viewer you open before a page load or refresh, as opening some of the other viewers makes it look like normal PCA colors again, but with Blues DEAD and DEADRAMP colors.)

Code: Select all

x = 2, y = 2, rule = B/S012345678
2o$2o!
[[ GRID GRIDMAJOR 4 ]]

Code: Select all

x = 2, y = 2, rule = B/S012345678History
2o$2o!
[[ GRID GRIDMAJOR 4 ]]

Code: Select all

x = 2, y = 2, rule = 012345678//3
2o$2o!
[[ GRID GRIDMAJOR 4 ]]

Code: Select all

x = 2, y = 2, rule = M0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
2o$2o!
[[ GRID GRIDMAJOR 4 ]]

Code: Select all

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

And a typo led to me discovering something funny: the error message for this RLE implies that this is an incorrectly-formatted Larger than Life rulestring. I'm not sure I see much of a resemblance to the usual format (it may resemble the old 1996 notation since it starts with a number).

Code: Select all

x = 2, y = 2, rule = 2PCA0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
2o$2o!

----

An incredibly big thank you for the fixes so far! I still have the aforementioned PCA/Margolus issues to test further and set up good test cases for, so there will still be a while before I end up posting those.

[rowett]

Identify's output is hidden inconsistently by the Settings and Help menu when opened.

Fixed, thanks.

That oscillator also has a very nice "% Rotor" value for period-2 cells. "Active Cells" appears to be mismatched as well - I'd expect 4 and 8, not 3 and 9.

Fixed, thanks.

For the first example pattern in this post, if we pause at around T=1000 just after the scripts finish, and then step back one generation, many of the alive cells seem to instantly age by a noticeable extent.

This is because the pattern starts with a Theme with no history and then at T=1000 switches to one with history.

The second example in that post has also been subject to errors for a while now - has a state name been changed or something been deprecated?

Yes, I fixed the post.

Also, for the following pattern, the cell exactly in the center never seems to age unlike all of the other cells in the pattern. I assume this is due to the fact that it dies each generation, but is instantly pasted back in such that there is no overall change in the pattern?

Correct.

And a typo led to me discovering something funny: the error message for this RLE implies that this is an incorrectly-formatted Larger than Life rulestring.

Indeed. It's because it doesn't have the PCA header 2PCA4 so the pattern decoder checked other rule types and guessed it might be LtL since it contains commas.

[muzik]

A bug that's new to build 875: the functionality of STOP seems to have, um, stopped:

Code: Select all

x = 37, y = 11, rule = B1357/S1357
ob3obo$2bo2b2o$5obo23b3o$obo28bo$5o3b3o3b3o3b3o3b3o3bo$2bobo3bobo3bo2b
2obo2b2obobob5obo$ob4o2bobo2b4o2b4o3bobo2bo3b2o$4bo2bo2bobobo3bobo3b2o
2bob5obo$ob4o2bo3b5o3bo3bobo3b5obo$2o2bo3bo2b2obo2b3o6bo2b2obo2b2o$ob
3o3b3o3b3o2b2o3bob3o3b3obo!
[[ AUTOSTART STOP 63 Y -64 ZOOM 16 ]]

A funny sighting related to this is that toggling the STOP button at the top doesn't have a message, whereas WAYPT does, from my testing of other patterns with it. I don't know if it had a message before but consistency would ultimately be expected. START doesn't have a message either.

Another bug that seems to be new in 875 is that when a Generations pattern dies out, instead of the last alive cell becoming a dying cell, it goes straight to dead:

Code: Select all

x = 13, y = 1, rule = 2//3
13A!
[[ AUTOSTART GPS 2 ]]

Code: Select all

x = 13, y = 1, rule = R1,C3,S2,B
13A!
[[ AUTOSTART GPS 2 ]]

If we have more than one dying state, it seems to skip a generation each time:

Code: Select all

x = 13, y = 1, rule = 2//5
13A!
[[ AUTOSTART GPS 2 ]]

Code: Select all

x = 13, y = 1, rule = R1,C5,S2,B
13A!
[[ AUTOSTART GPS 2 ]]

When changing the theme within the viewer for both of these patterns, the top one has all colors changed accordingly, but the bottom one keeps the alive state white (the same is true if we do COLOR 1):

Code: Select all

x = 7, y = 2, rule = /2/8
ABCDEFG$ABCDEFG!
[[ COLOR ALIVE White COLOR BACKGROUND Black ]]

Code: Select all

x = 7, y = 2, rule = /2/8
ABCDEFG$ABCDEFG!
[[ COLOR alive White COLOR BACKGROUND Black ]]

This script error seems wrong:

Code: Select all

x = 28, y = 14, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3.3A5.3I3C5.3K$3H3.3B2.3L3F2.3M3.3G$3H3.
3B2.3L3F2.3M3.3G$3H3.3B2.3L3F2.3M3.3G$3.3D16.3N$3.3D16.3N$3.3D7.2E7.3N
$13.2E$11.2J2O2J$11.2J2O2J$13.2E$13.2E!
[[ COLOR alive 255 255 255 ]]

For oscillators that could be described as both FlipXorY and RotCWorCCW, could a dedicated transformation type name be added to indicate that both such interpretations are interchangeable?

Code: Select all

x = 7, y = 7, rule = B3/S23
b2ob2o$ob2o2bo$2o4bo$bo3bo$o4b2o$o2b2obo$b2ob2o!

[rowett]

the functionality of STOP seems to have, um, stopped

Fixed, thanks.

A funny sighting related to this is that toggling the STOP button at the top doesn't have a message, whereas WAYPT does

Fixed, thanks.

Another bug that seems to be new in 875 is that when a Generations pattern dies out, instead of the last alive cell becoming a dying cell, it goes straight to dead

Fixed, thanks.

If we have more than one dying state, it seems to skip a generation each time

Fixed, thanks.

When changing the theme within the viewer for both of these patterns, the top one has all colors changed accordingly, but the bottom one keeps the alive state white (the same is true if we do COLOR 1)

Fixed, thanks. They both should have all colours changed.

This script error seems wrong

This script error seems fixed now.

For oscillators that could be described as both FlipXorY and RotCWorCCW, could a dedicated transformation type name be added to indicate that both such interpretations are interchangeable?

Yes, done.

[rowett]

For Margolus rules, which using a theme that doesn't have a GRIDMAJOR interval of 2 (i.e. themes that have no major grid lines, as well as custom theme definitions), should Display > Alt GridLines be disabled

Fixed, thanks.

When setting up the above example, I noticed this: when setting a custom GRIDMAJOR interval, LifeViewer will create a custom theme that's based on the Blues theme, regardless of what rulespace is in use. Shouldn't it try to follow the default theme for each rulespace instead, creating a custom theme which is identical to the default theme in every way except for the GRIDMAJOR interval?

Yes, done.

[muzik]

For Margolus rules, which using a theme that doesn't have a GRIDMAJOR interval of 2 (i.e. themes that have no major grid lines, as well as custom theme definitions), should Display > Alt GridLines be disabled

Fixed, thanks.

Fix confirmed, however I did find a minor catch: if a rule with such a theme is loaded and we then use the in-viewer theme selector menu to change to a rule that does have a GRIDMAJOR of 2, the Alt GridLines button will appear to be off, but grid lines will still alternate. Clicking the Alt GridLines button to turn it on still causes the grid lines to alternate, and clicking it a second time stops them alternating and turns the button off as expected.

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID THEME Catagolue ]]

Also, at least on my end, the "lowercase custom alive color persists across all themes when switching within a viewer" behaviour still exists in builds 877 and 878. Build 878 also changed how the two examples looked: in build 877, both of them were a white to black gradient, however build 878 changes the uppercase-alive example to a white to red gradient, and the lowercase-alive example to the Generations theme's gradient with the alive state replaced with white.

Code: Select all

x = 11, y = 2, rule = /2/12
ABCDEFGHIJK$ABCDEFGHIJK!
[[ COLOR ALIVE White ]]

Code: Select all

x = 11, y = 2, rule = /2/12
ABCDEFGHIJK$ABCDEFGHIJK!
[[ COLOR alive White ]]

Code: Select all

x = 11, y = 2, rule = /2/12
ABCDEFGHIJK$ABCDEFGHIJK!
[[ COLOR 1 White ]]

How long have the grid line colors for the Inverse and Day themes been different from the other classic pre-2019 themes, by the way? I only noticed this the other day.

Finally, the "custom PCA cell colors carry over to other PCA patterns" bug reported earlier on this page also seems to have made a comeback.

[rowett]

if a rule with such a theme is loaded and we then use the in-viewer theme selector menu to change to a rule that does have a GRIDMAJOR of 2, the Alt GridLines button will appear to be off, but grid lines will still alternate

Fixed, thanks.

the "lowercase custom alive color persists across all themes when switching within a viewer" behaviour still exists

Fixed, thanks.

How long have the grid line colors for the Inverse and Day themes been different from the other classic pre-2019 themes, by the way? I only noticed this the other day.

Not sure. There have been several changes recently

Finally, the "custom PCA cell colors carry over to other PCA patterns" bug reported earlier on this page also seems to have made a comeback.

Fixed, thanks.

[muzik]

For the Mono and Inverse themes with Generations patterns (as well as the custom theme before build 878), the final dying state is identical to the background color, making it completely visually indistinguishable from the background, which I don't think is ideal. Would it be possible to have the DYINGRAMP for these themes be calculated similarly to how the initial DYING is, so that the final state's color is not identical to that of the dead color, but it still forms an overall smooth gradient towards the dead color?

Code: Select all

x = 2, y = 2, rule = /2/3
AB$AB!
[[ THEME Mono ]]

Code: Select all

x = 2, y = 2, rule = /2/3
AB$AB!
[[ THEME Inverse ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ THEME Mono ]]

Code: Select all

x = 5, y = 2, rule = /2/6
ABCDE$ABCDE!
[[ THEME Inverse ]]

The other themes would remain unchanged as their dead colors and final dying colors differ significantly.

[rowett]

For the Mono and Inverse themes with Generations patterns (as well as the custom theme before build 878), the final dying state is identical to the background color, making it completely visually indistinguishable from the background

I've adjusted the final Dying state for these two Themes.

[rowett]

I've changed LifeViewer's behaviour so that when all cells die in a pattern playback is automatically paused (unless there are pending PASTEs). This makes it simple to see statistics on the final generation.

Code: Select all

#C [[ AUTOSTART ZOOM 18 SHOWGENSTATS ]]
x = 8, y = 3, rule = B3/S23
6bo$2o$bo3b3o!

I'd welcome any feedback on this change.

[muzik]

I'd welcome any feedback on this change.

Could the "Life ended at" message be removed if the viewer still detects pending paste commands in such cases?

----

An unrelated sighting still on the topic of Generations themes: for three-state rules (one dying state), Help > Themes still displays both DYING and DYINGRAMP for many themes despite only one dying color being in use.

[PHPBB12345]

How to disable secret snow?

Code: Select all

#C [[ RLE a ! ]]
#C [[ RLE b ! ]]
#C [[ RLE c ! ]]
#C [[ ZOOM 8 ]]
x = 0, y = 0, rule = B3/S23
!

[rowett]

How to disable secret snow?

Code: Select all

#C [[ RLE a ! ]]
#C [[ RLE b ! ]]
#C [[ RLE c ! ]]
#C [[ ZOOM 8 ]]
x = 0, y = 0, rule = B3/S23
!

Use script command [[ NOSNOW ]].

[rowett]

Could the "Life ended at" message be removed if the viewer still detects pending paste commands in such cases?

Yes, done.

An unrelated sighting still on the topic of Generations themes: for three-state rules (one dying state), Help > Themes still displays both DYING and DYINGRAMP for many themes despite only one dying color being in use.

Fixed, thanks.

[muzik]

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

Code: Select all

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

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?

Code: Select all

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

Code: Select all

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

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? I know that this is the maximum amount of generations Identify can work with, but since Go To Gen doesn't track the same amount of information about the pattern this limit seems entirely arbitrary.

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

Code: Select all

x = 10, y = 8, rule = 23/3/17
2.3A$.ABDBA$A2BE2A$.AGJDL3.P$D2GLM3.O$.EG2J3ON$2.FGJIOM$4.H.L!
[[ COLOR DEAD DeepSkyBlue ]]

Code: Select all

x = 10, y = 8, rule = 23/3/17
2.3A$.ABDBA$A2BE2A$.AGJDL3.P$D2GLM3.O$.EG2J3ON$2.FGJIOM$4.H.L!
[[ COLOR dead DeepSkyBlue ]]

----

Use script command [[ NOSNOW ]].

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.