Pattern viewer for forum threads

[rowett]

Back on the topic of PCA Identify, there's still a handful of patterns for which I'd probably expect that a mod value lower than the period should be reported, but is ultimately not.

Fixed, thanks!

[muzik]

If a pattern initially contains no alive cells, paste commands do not work properly when advancing generations, but will correctly appear when stepping back. This pattern should change at T=1, but does not change at all. Going to T=2 or later and stepping back will correctly have the command RLE pasted over it:

Code: Select all

x = 24, y = 9, rule = 0345/2/10
22.B$22.B$B7.B.B3.B7.B$10.B11.B$B.B.2B2.B.3B.B.4B2.B$B.2B2.B.B.B3.B5.
B.B$B.B3.B.B.B3.B2.4B.B$B.B3.B.B.B3.B.B3.B.B$B.B3.B.B2.2B.B2.3B3.B!
[[ ZOOM 10
PASTEMODE COPY
RLE example 17.F24.F$17.F24.F$17.F24.F$F.2F2.3F2.F.2F2.F2.4F3.3F3.3F3.2F.F$2F3.F3.
F.2F2.F.F6.F.F3.F.F3.F.F2.2F$F4.4F2.F3.F.F3.4F.F5.4F2.F3.F$F4.F5.4F2.
F2.F3.F.F3.F.F5.F3.F$F5.4F.F6.F2.3F3.3F3.4F2.4F.F$11.F$11.F!
PASTET 1 PASTE example -10 0
]]

Also, with AUTOSTART, there's a "Life ended at" message that appears for Generations patterns consisting solely of dying cells, which does not appear from normal playback or stepwise advancement:

Code: Select all

x = 2, y = 2, rule = //5
2B$2B!
[[ THEME Red GPS 1 ]]

Code: Select all

x = 2, y = 2, rule = //5
2B$2B!
[[ THEME Red GPS 1 AUTOSTART ]]

Code: Select all

x = 2, y = 2, rule = R1,C5,S,B
2B$2B!
[[ THEME Red GPS 1 ]]

Code: Select all

x = 2, y = 2, rule = R1,C5,S,B
2B$2B!
[[ THEME Red GPS 1 AUTOSTART ]]

EDIT: LifeSuper is also affected:

Code: Select all

x = 2, y = 2, rule = LifeSuper
2B$2B!
[[ THEME Red GPS 1 AUTOSTART ]]

[muzik]

The first bug in the previous post still seems to occur if the paste occurs at T=2 or later and there are no history cells.

Code: Select all

x = 5, y = 7, rule = 0345/2/10
.3B$B3.B$B3.B$5B$B3.B$B3.B$B3.B!
[[ COLOR BACKGROUND Gray COLOR DEAD Gray
ZOOM 10 GPS 2
PASTEMODE COPY
RLE letter 4B$B3.B$B3.B$4B$B3.B$B3.B$4B!
PASTET 2 PASTE letter 6 0
]]

It does not happen for a paste at T=1:

Code: Select all

x = 5, y = 7, rule = 0345/2/10
.3B$B3.B$B3.B$5B$B3.B$B3.B$B3.B!
[[ COLOR BACKGROUND Gray COLOR DEAD Gray
ZOOM 10 GPS 2
PASTEMODE COPY
RLE letter 4B$B3.B$B3.B$4B$B3.B$B3.B$4B!
PASTET 1 PASTE letter 6 0
]]

Nor does it happen if there is a distinct dead color:

Code: Select all

x = 5, y = 7, rule = 0345/2/10
.3B$B3.B$B3.B$5B$B3.B$B3.B$B3.B!
[[ COLOR BACKGROUND Gray COLOR DEAD Purple
ZOOM 10 GPS 2
PASTEMODE COPY
RLE letter 4B$B3.B$B3.B$4B$B3.B$B3.B$4B!
PASTET 2 PASTE letter 6 0
]]

[muzik]

An important announcement:

Code: Select all

x = 23, y = 7, rule = Fireworks
.3B3.3B4.B4.3B$B3.B.B3.B2.2B3.B3.B$4.B.B3.B.B.B7.B$4.B.B3.B3.B4.3B$.3B
2.B3.B3.B7.B$B5.B3.B3.B3.B3.B$5B2.3B2.5B2.3B!
[[
GPS 2 AUTOSTART
ZOOM 8
PASTEMODE COPY
COLOR BACKGROUND Black
COLOR ALIVE Black
COLOR DEAD SpringGreen
COLOR DYING SpringGreen
COLOR DYINGRAMP SpringGreen
RLE zero .3B$B3.B$B3.B$B3.B$B3.B$B3.B$.3B!
RLE one 2.B$.2B$B.B$2.B$2.B$2.B$5B!
RLE two .3B$B3.B$4.B$4.B$.3B$B$5B!
RLE three .3B$B3.B$4.B$.3B$4.B$B3.B$.3B!
RLE four B3.B$B3.B$B3.B$5B$4.B$4.B$4.B!
RLE five 5B$B$4B$4.B$4.B$B3.B$.3B!
RLE six .3B$B3.B$B$4B$B3.B$B3.B$.3B!
RLE seven 5B$B3.B$4.B$3.B$3.B$2.B$2.B!
RLE eight .3B$B3.B$B3.B$.3B$B3.B$B3.B$.3B!
RLE nine .3B$B3.B$B3.B$.4B$4.B$B3.B$.3B!
PASTET 2 PASTE four 18 0
PASTET 4 PASTE five 18 0
PASTET 6 PASTE six 18 0
PASTET 8 PASTE seven 18 0
PASTET 10 PASTE eight 18 0
PASTET 12 PASTE nine 18 0
PASTET 14 PASTE zero 18 0 PASTE two 12 0 PASTE two 0 0 PASTE zero 6 0
PASTET 16 PASTE one 18 0
PASTET 18 PASTE two 18 0
PASTET 20 PASTE three 18 0
T 24 "\n"
PASTET 25 PASTE RANDCELLS 23 7 0 0
PASTET 30 PASTE RANDCELLS 23 7 0 0
PASTET 35 PASTE RANDCELLS 23 7 0 0
T 500 GPS 64 AUTOFIT THEME LifeHistory "LifeViewer: 31 Jan 2013 - 31 Jan 2023\nThanks for everything!"
]]

Congratulations on ten years of ConwayLife.com membership!

[rowett]

If a pattern initially contains no alive cells, paste commands do not work properly when advancing generations, but will correctly appear when stepping back.

Fixed, thanks.

Also, with AUTOSTART, there's a "Life ended at" message that appears for Generations patterns consisting solely of dying cells, which does not appear from normal playback or stepwise advancement

Fixed, thanks.

[rowett]

Congratulations on ten years of ConwayLife.com membership!

Thank you!

The next significant event will be on February 17th, 2025.

[muzik]

Something random I noticed: if the first LifeViewer window you open on this page is the first of the three code boxes with the "AB" no-history paste bug example, the color of the dying cells will be various shades of gray. However, if you open the 10th anniversary pattern and then open the first "AB" example, the dying cells become shades of green instead. I'd assume that properties like these aren't supposed to carry over to subsequent viewers on this way, and that LifeViewer just isn't resetting the value for DYINGRAMP for newly opened viewers if the code box doesn't specify a new value?

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:

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 ]]

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.

[rowett]

if the first LifeViewer window you open on this page is the first of the three code boxes with the "AB" no-history paste bug example, the color of the dying cells will be various shades of gray. However, if you open the 10th anniversary pattern and then open the first "AB" example, the dying cells become shades of green instead.

Fixed, thanks!

[muzik]

Identify isn't recognising spaceship mods anymore:

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ GRID THEME Generations TRACK -1/2 0 ]]

Code: Select all

x = 34, y = 23, rule = B3/S23
4b2o10b2o10b2o$4b2o10b2o10b2o$3bo2bo8bo2bo8bo2bo$3b4o8b4o8b4o$2bob2obo
6bob2obo6bob2obo$3bo2bo8bo2bo8bo2bo2$2b2o2b2o6b2o2b2o6b2o2b2o$bo6bo4bo
6bo4bo6bo2$2bo4bo6bo4bo6bo4bo$3bo2bo8bo2bo8bo2bo$4b2o10b2o10b2o2$b2o4b
2o4b2o4b2o4b2o4b2o$o2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo2bo$b2o4b2o4b2o4b2o
4b2o4b2o$2bo4bo6bo4bo6bo4bo2$14bo2$17b3o$17bo!
[[ GRID THEME Generations TRACK 0 -1/10 ]]

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ GRID THEME Generations TRACK -1/4 1/4 ]]

----

There's also a weird case for PCA I've found: Identify calculates that the period of this oscillator is 24. Moreover, the mirror image of the initial phase appears exactly halfway through its evolution, so it concludes that the mod of this oscillator must also be 12.

Code: Select all

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

However, this Mod result is not entirely accurate. If we compare how it looks at T=2 and T=14, the positions of the cells in the oscillator are completely different. The pattern becoming its mirror image at exactly halfway through its evolution cycle is far more coincidental than anything, so saying it has a mod of 12 isn't entirely right.

This ultimately comes down to the fact that the rule PCA_4, while invariant under rotation, is not invariant under reflection. So while FlipXY (which is equivalent to an 180-degree rotation), RotCW, RotCCW and RotCWorCCW are all perfectly valid transformations for an oscillator in PCA_4, FlipX is not. This isn't to say that FlipX isn't valid for the entirety of PCA - for example, it's a perfectly normal sight in PCA_1:

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
IC3.B2.IC$LF6.LF!

Ultimately, for Identify, LifeViewer should either compare more phases of patterns to conclude whether an output of Mod is valid, or check how symmetric the rule itself is and block certain transformation types from being produced if incompatible with the rule.

----

Are there any plans to fix false pattern classifications by Identify for Margolus rules? There are still a handful of oscillators which Identify classifies as spaceships, particularly the small oscillators consisting of a single cell. Here's a typical p4:

Code: Select all

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

A single-cell figure-eight p8:

Code: Select all

x = 4, y = 4, rule = M15,11,7,5,13,3,6,8,14,9,10,4,12,2,1,0
2$2bo!

A p8 with a wider cycle:

Code: Select all

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

And a larger example, a period-28 oscillator:

Code: Select all

x = 3, y = 3, rule = MargSingRot
bo$b2o$b2o!

From what I can see, Identify's classification of these as spaceships is entirely due to it jumping to conclusions far too early. When identified from T=0, the value of T after identification is complete is always less than or equal to the oscillator's actual period. While I'm not too sure about how to fix these cases, it seems like having Identify actually test the spaceship period and displacement it calculates first, by evolving the pattern for that number of generations and checking if the phases match and that the pattern has actually displaced itself by that distance and direction, would get rid of these false positives.

For actual spaceships such as the following, it wouldn't change anything, since these would pass such a test.

Code: Select all

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

Code: Select all

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

----

Identify doesn't recognise spaceships in [R]Super if they have a trail:

Code: Select all

x = 3, y = 3, rule = B3/S23History
A$A.A$2A!

Code: Select all

x = 3, y = 3, rule = B3/S23Super
A$A.A$2A!

Code: Select all

x = 3, y = 3, rule = B3/S23Super
I$I.I$2I!

Code: Select all

x = 3, y = 3, rule = B3/S23Super
K$K.K$2K!

Code: Select all

x = 3, y = 3, rule = B3/S23Super
M$M.M$2M!

It can, however, if a spaceship with a trail has its trail overwritten with a spaceship without a trail:

Code: Select all

x = 12, y = 12, rule = B3/S23Super
9.M$9.M.M$9.2M7$K$K.K$2K!

[rowett]

Identify isn't recognising spaceship mods anymore

Fixed, thanks.

There's also a weird case for PCA I've found: Identify calculates that the period of this oscillator is 24. Moreover, the mirror image of the initial phase appears exactly halfway through its evolution, so it concludes that the mod of this oscillator must also be 12.

Fixed, thanks.

Are there any plans to fix false pattern classifications by Identify for Margolus rules?

Not currently.

Identify doesn't recognise spaceships in [R]Super if they have a trail

Fixed, thanks.

[muzik]

It appears that the [R]Super spaceship identification fix has also fixed mod calculations for oscillators in [R]Super patterns, which is obviously fantastic since they didn't work before.

On that topic, would it be possible to have strict volatility and period mapping enabled for [R]Super, since [R]History already has it?

Code: Select all

x = 22, y = 7, rule = B3/S23History
12.A$12.A.A$2A11.A.A4.2A$2A11.A2.A3.2A$13.A.A$12.A.A$12.A!

Code: Select all

x = 22, y = 7, rule = B3/S23Super
12.A$12.A.A$2A11.A.A4.2A$2A11.A2.A3.2A$13.A.A$12.A.A$12.A!

[rowett]

would it be possible to have strict volatility and period mapping enabled for [R]Super

Yes, done.

[muzik]

Would it be possible to enable Tilt, Angle, Layers and Depth for the none rule on a square grid?

Code: Select all

x = 16, y = 16, rule = none:P16,16
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!

[muzik]

The MCell, Catagolue and Book themes' handling of Generations patterns might be flawed slightly: for rules with only one dying state, distinct DYING and DYINGRAMP colors are listed in Help > Themes for these three themes in specific, and no other themes.

Code: Select all

x = 32, y = 10, rule = 12/34/3
5A22.A$A26.A$A5.A.A.2A2.A.A.A2.A.2A2.A2.A$3A3.A.A3.A.2A.A.A.2A2.A.A.A
.A$A6.A3.2A.A2.A.A.A3.A.A.2A$A5.A.A.A.A.A2.A.A.2A2.A.A.A$5A.A.A2.A2.A
2.A.A.A.2A2.A2.2A$21.A$21.A$21.A!

Code: Select all

x = 32, y = 10, rule = 12/34/3
5A22.A$A26.A$A5.A.A.2A2.A.A.A2.A.2A2.A2.A$3A3.A.A3.A.2A.A.A.2A2.A.A.A
.A$A6.A3.2A.A2.A.A.A3.A.A.2A$A5.A.A.A.A.A2.A.A.2A2.A.A.A$5A.A.A2.A2.A
2.A.A.A.2A2.A2.2A$21.A$21.A$21.A!
[[ THEME MCell ]]

Code: Select all

x = 32, y = 10, rule = 12/34/3
5A22.A$A26.A$A5.A.A.2A2.A.A.A2.A.2A2.A2.A$3A3.A.A3.A.2A.A.A.2A2.A.A.A
.A$A6.A3.2A.A2.A.A.A3.A.A.2A$A5.A.A.A.A.A2.A.A.2A2.A.A.A$5A.A.A2.A2.A
2.A.A.A.2A2.A2.2A$21.A$21.A$21.A!
[[ THEME Catagolue ]]

Code: Select all

x = 32, y = 10, rule = 12/34/3
5A22.A$A26.A$A5.A.A.2A2.A.A.A2.A.2A2.A2.A$3A3.A.A3.A.2A.A.A.2A2.A.A.A
.A$A6.A3.2A.A2.A.A.A3.A.A.2A$A5.A.A.A.A.A2.A.A.2A2.A.A.A$5A.A.A2.A2.A
2.A.A.A.2A2.A2.2A$21.A$21.A$21.A!
[[ THEME Book ]]

I'm also not sure if the DYING and DYINGRAMP definitions for the Book theme are backwards or not. Are dying cells meant to start out a light color somewhat similar to the background before fading to a dark color very similar to living cells? For most of the other themes it's the other way around.

Code: Select all

x = 16, y = 10, rule = 24/24/151
9.D5.I$4.A3.EFE$3.BAB2.GFG.HI$2.2ABCF.3H2.H$2AB3D2GH.I2.I$2ABDCEGCH$
2.3BEDB2FHI$2.A.ADBCFHFH$8.EDGF$8.DCE!
[[ AUTOFIT THEME Book ]]

[muzik]

Reverse playback and stepping back for alternating PCA rules isn't working correctly. Since this pattern is periodic and both rules are reversible. it'd be expected that the evolution sequence would be identical, though reversed, in backwards playback, however it can be seen that the pattern functions entirely differently.

Code: Select all

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

Code: Select all

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

For the reverse pattern, if we advance to generation -1 and then replace everything with the initial pattern (one NESW), it appears to work right, however this may require some further confirmation.

[rowett]

Would it be possible to enable Tilt, Angle, Layers and Depth for the none rule on a square grid?

No.

[rowett]

The MCell, Catagolue and Book themes' handling of Generations patterns might be flawed slightly

Fixed, thanks.

I'm also not sure if the DYING and DYINGRAMP definitions for the Book theme are backwards or not.

Fixed, thanks.

[rowett]

Reverse playback and stepping back for alternating PCA rules isn't working correctly.

Fixed, thanks.

[muzik]

It appears that the Catagolue theme has been changed such that the colors of dying cells in Generations rules no longer accurately resemble their generated preview icons:

Code: Select all

x = 9, y = 9, rule = 23/3/17
3.F.B$2.GICDA$.H3I2D2A$.ILNLGF2A$J2LOFAD2A$.K2.N2A$N$.O$2.P!
[[ THEME Catagolue ]]

Catagolue has distinct alive and initial dying colors.

Here's a page with the pattern above for comparison: https://catagolue.hatsya.com/census/g17b3s23/C1/xp32

Here's a page containing a pattern with a much wider range of dying cells: https://catagolue.hatsya.com/census/g143b3s23/C1/xq4

Previously, DYING was 2 129 2 and DYINGRAMP was 96 192 139. From the long spaceship, the initial dying cells appear to be 2 129 2 and the ready to fully die cells are 96 191 119.

[rowett]

It appears that the Catagolue theme has been changed such that the colors of dying cells in Generations rules no longer accurately resemble their generated preview icons

Fixed, thanks.

[muzik]

When Using Identify on a Generations spaceship about to hit the border, we get a message saying "Empty Pattern" (as opposed to "Life ended at"), and there visually still appears to be live cells present.

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 ]]

Compare to this 2-state example:

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 COLOR BACKGROUND Black COLOR DEAD 64 64 64 COLOR DEADRAMP 32 32 32 COLOR ALIVE White STARTFROM 500 X -250 ]]

And a bug I found while testing this: STARTFROM acts strangely when specified for an empty pattern.

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ STARTFROM 5 ]]

And a bug I found while testing that: for Generations, if the pattern dies during STARTFROM, we get a permanent dying cell. This permanently fixes itself until the page is refreshed if the pattern is rewound to T=0.

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ STARTFROM 5 ]]

Code: Select all

x = 1, y = 1, rule = G3/B3/S23
o!
[[ STARTFROM 5 ]]

EDIT: Even the two-state case is bugged, since the dead cell doesn't fade to DEADRAMP.

[muzik]

In a future build it will be possible to set MAXGRIDSIZE separately for width and height. The minimum width will stay at 9 (512 pixels) but the minimum height will reduce to 8 (256 pixels).

Did this ever end up being implemented? I clearly recall changes to grid size handling happening around late 2021 where it can expand dynamically per axis to save performance, however checking the scripting help doesn't display anything about per-axis configurability for how big a grid can be.

----

Whether or not the ability to manually set grid size limits per axis exists yet, I've been wondering if it'd be possible to somehow implement a way for the grid's size to exceed 16384 cells, but in such a way that the size of the grid is overall less than 16384x16384 (=268435456, 2^28). For example, it could be possible to set the grid's width to 32768 cells, which would allow for wider patterns to be viewed. This would end up capping the grid's height to 8192 at the absolute maximum as to have the total grid dimensions be within the 2^28 threshold.

My main motive for suggesting this is due to some of the larger syntheses listed on Catagolue, particularly those of the next-step-up-from-Canada-Grey spaceships, whose widths exceed 16384 cells: https://catagolue.hatsya.com/object/xq4 ... x131/b3s23

Since the pattern's width exceeds 16384 cells, LifeViewer outright rejects the pattern even with MAXGRIDSIZE pushed to its limit. However, despite being quite long in the X direction, incremental synthesis patterns don't tend to be particularly tall on the Y axis, so having the Y axis necessarily expand with the X axis seems wasteful of that vertical space. The ability to sacrifice (or rather, repurpose) some height for an expanded pattern width would be perfect for this situation and allow for every step of this synthesis to be viewed in full in the browser.

[muzik]

For PCA, random fills don't seem to accurately randomly fill a region with the density selected on the slider. Two example patterns are listed for easy Select All usage as well as bounded grids for a density value display. Life is correctly randomly filled with roughly 50% live and 50% dead cells each time, but PCA averages around 26%, likely because state 0 cells make up 50% of the randomly selected states, with the other 50% taken up by all non-state 0 cells.

Code: Select all

x = 100, y = 100, rule = Life:T100
o99$99bo!
[[ SHOWGENSTATS ]]

Code: Select all

x = 100, y = 100, rule = PCA_1:T100
o99$99bo!
[[ SHOWGENSTATS ]]

I haven't tested random cell regions created via scripts, so these should probably also be tested.

[rowett]

When Using Identify on a Generations spaceship about to hit the border, we get a message saying "Empty Pattern" (as opposed to "Life ended at"), and there visually still appears to be live cells present.

Fixed, thanks.

STARTFROM acts strangely when specified for an empty pattern.

Fixed, thanks. STARTFROM will now notify "Empty Pattern" in this case.

for Generations, if the pattern dies during STARTFROM, we get a permanent dying cell

Fixed, thanks.

Even the two-state case is bugged, since the dead cell doesn't fade to DEADRAMP.

Fixed, thanks.

[rowett]

In a future build it will be possible to set MAXGRIDSIZE separately for width and height. The minimum width will stay at 9 (512 pixels) but the minimum height will reduce to 8 (256 pixels).

Did this ever end up being implemented? I clearly recall changes to grid size handling happening around late 2021 where it can expand dynamically per axis to save performance, however checking the scripting help doesn't display anything about per-axis configurability for how big a grid can be.

No it's still on the backlog. What was implemented was the ability to have separate grid width from height, and to grow the grid independently vertically or horizontally as the pattern grows.