Pattern viewer for forum threads

[muzik]

I can confirm that embedded viewers can appear cut off on phone screens:

Fixed in build 1280, thanks.

Thanks for this - waiting on the Minecraft Wiki updating so I can confirm this.

Can the default CLOSEBACKGROUND be changed to a deeper shade of red so that it looks more like it previously did in the Settings menu? It will end up looking more intense on the top bar but I don't think that's much to worry about.

Code: Select all

x = 191, y = 144, rule = B3aiky4ace5aejk6in/S2en3cij4aciw5-cn6aei7e
12$122bo$123bo5$112bo13b3o$110b5o11bobo$108b4ob4o11bo$106b3obo3bob3o$
104b4obo4bo2bo$102b3obobo5bobo$103bobo$102b3obo$101bobobo$104b2o$102b
3o2$112bo$110b5o$108b4ob4o18bo$106b3obo3bob3o15b2o$104b4o2bo3bo2b4o14b
2o$102b3obo7bobobob3o11bobo$100b4o2bo8b2ob2ob4o8bob3o$99b2ob2o2bo8bo3b
o2bob2o6bobob2o$98b2obo17bobobob2o6b3ob2o$98bob2o24bo5bob3obo$97b5o2bo
20b3o7b5o$97b4ob3o21b2o4b3ob4o$96b2ob4o9bo12bob2o5b4ob2o$96bob3o9b5o
13bo7b3obo$95b4o9b4ob4o8b5o8b4o$95b3o9b2ob2ob2ob2o9b3o9b3o$94b2o10b2ob
2o3bo2b2o10b2o10b2o$94bo11bo2bo4b3obo11bo11bo$93b5o7b4o8b3o9b3o9b3o$
93b3o9b3o7b2obo11bo11bo$92b2o10b2o8b2ob2o10b2o10b2o$81bo10bo11bobo8b3o
9b3o10b2o$79bob3o7b3o9b3o10bo10b3o9b3o$80bo11bo11bobo19bobo9bobo$80b2o
10b2o10b2o21b2o10b2o$81b3o9b3o9b2o19b2o9b3o$81bob3o7b3o9b3o16b4o7b5o$
84bo9bobo9bo15b3obo6b2o3bo$94b2o10b2o2bo11bo2b2o7b2ob2o$95b2o10b2ob2o
9b2ob2o10b2o$95b4o9b4ob2o3bo2b4o8b5o$96bo13b3ob2ob2ob3o13bo$96b2o14b4o
b4o8b2o4b2o$97b3o14b5o10bo3b3o$97b3o16bo11b2o3b3o$98bobo2b3o22bob3obo$
98b2o5bo21b5ob2o$99b2ob3obo20b4ob2o$100b4obo20b2ob4o$102b3obobo17bob3o
$104b4obo13bob4o$106b3ob2o2bo3bo2b2ob3o$108b4o2bo3bo2b4o$110b3obo3bob
3o$112b4ob4o$114b5o$116bo!
[[ COLOR CLOSEBACKGROUND 255 64 64 ]]

Is there an in-viewer toggle for snow, and if not, will one be added?

Looks like we're now on the 4000th reply, which means that this thread now accounts for 2/3 of this entire forum as it also recently passed the 6000 mark...

[muzik]

If you do implement this rulespace in LifeViewer, I would recommend using the suffix Lx (triangular, X-neighborhood).

Isn't this neighbourhood already known as Triangular Biohazard?

Code: Select all

x = 1, y = 1, rule = B1/SLB
o!
[[ STARTFROM 1 SHOWGENSTATS ]]

[R2INT]

If you do implement this rulespace in LifeViewer, I would recommend using the suffix Lx (triangular, X-neighborhood).

Isn't this neighbourhood already known as Triangular Biohazard?

Code: Select all

x = 1, y = 1, rule = B1/SLB
o!
[[ STARTFROM 1 SHOWGENSTATS ]]

Thank you for the terminology that I was unaware of. My recommendation changes from Lx to Lb (since the OT version was already implemented with that symbol; changing it would likely result in compatibility issues).

Code: Select all

x = 0, y = 0, rule = B3/S245LB
!
# [[ RANDOMIZE ]]

[muzik]

Annotation polygons appear to have a black shadow, the color of which does not appear to be tied to anything in particular and does not appear to have a script command associated with it either. What exactly is it based on, and can it be made customizable somehow, like my earlier requests regarding the popup gray border and shadow?

Code: Select all

x = 156, y = 75, rule = R3,C2,S2-3,B3,NW0000000000000000111000010100001110000000000000000
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!
[[
COLOR BACKGROUND Purple
COLOR DEAD Purple
COLOR DEADRAMP Purple
COLOR ALIVE Pink
COLOR ALIVERAMP Pink
COLOR GRID Pink
COLOR GRIDMAJOR Pink
COLOR BOUNDARY Pink
COLOR SELECT Pink
COLOR PASTE Pink
COLOR SELECTED Pink
COLOR GRAPHBG Pink
COLOR GRAPHAXIS Pink
COLOR GRAPHALIVE Pink
COLOR GRAPHBIRTH Pink
COLOR GRAPHDEATH Pink
COLOR UIFOREGROUND Pink
COLOR UIBACKGROUND Pink
COLOR UIHIGHLIGHT Pink
COLOR UISELECT Pink
COLOR UILOCKED Pink
COLOR UIBORDER Pink
COLOR TEXT Pink
COLOR ERROR Pink
COLOR HELP Pink
COLOR STARS Pink
COLOR TITLEBACKGROUND Pink
COLOR TITLEFOREGROUND Pink
COLOR CLOSEBACKGROUND Pink
COLOR CLOSEFOREGROUND Pink
COLOR SNOW Pink
MAXGRIDSIZE 9 SNOW SHOWGENSTATS SHOWTIMING EXTENDEDTIMING SHOWINFOBAR
COLOR POLY Pink POLYFILL 70 0 90 0 90 20 70 20 70 0 3 ]]

If these three objects are made customizable, the only hardcoded colors to my knowledge will be the EXTENDEDTIMING debug info and LifeViewer Pro info (which will be removed anyway) and the SHOWTIMING background and colors associated with oscillator maps (which probably won't ever be customizable). Most alpha values are still fixed, however.

The new Help > Info > UI additions don't appear to be changing to the values they're set to.

The viewer embed on viewer.html appears to expand considerably when on an iPad:

IMG_7211.jpeg (264.31 KiB) Viewed 785 times

It also appears much too wide on the homepage:

IMG_7213.jpeg (508.88 KiB) Viewed 783 times

Cells may be bleeding past borders in some cases like this, although this may be computer dependent and seems to change depending on popup size.

Code: Select all

x = 23, y = 23, rule = B3/S23
15bo$14b3o$13b5o$12b7o$11b9o$10b11o$9b13o$8b15o$7b15o$6b15o$5b15o$4b15o
$3b15o$2b15o$b15o$15o$b13o$2b11o$3b9o$4b7o$5b5o$6b3o$7bo!
[[ CELLBORDERS ANGLE 45 ZOOM 32 SNOW ]]

As snow is now a proper scriptable effect, could the old Easter egg trigger and the NOSNOW command be removed so that it only appears when specifically requested? Here's a list of all (to my knowledge) posts that intentionally invoke the old behaviour:

Code: Select all

https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&p=116275#p116275
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&p=116347#p116347
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&p=86429#p86429
https://conwaylife.com/forums/viewtopic.php?p=155175#p155175 and the recent post that quoted it

Why does snow not appear for the bottom two patterns?

Code: Select all

x = 23, y = 23, rule = B/S01234V
15bo$14b3o$13b5o$12b7o$11b9o$10b11o$9b13o$8b15o$7b15o$6b15o$5b15o$4b15o
$3b15o$2b15o$b15o$15o$b13o$2b11o$3b9o$4b7o$5b5o$6b3o$7bo!
[[ CELLBORDERS ZOOM 32 SNOW ]]

Code: Select all

x = 23, y = 23, rule = B/S0123HT
15bo$14b3o$13b5o$12b7o$11b9o$10b11o$9b13o$8b15o$7b15o$6b15o$5b15o$4b15o
$3b15o$2b15o$b15o$15o$b13o$2b11o$3b9o$4b7o$5b5o$6b3o$7bo!
[[ CELLBORDERS ZOOM 32 SNOW ]]

Code: Select all

x = 23, y = 23, rule = B/S0123LV
15bo$14b3o$13b5o$12b7o$11b9o$10b11o$9b13o$8b15o$7b15o$6b15o$5b15o$4b15o
$3b15o$2b15o$b15o$15o$b13o$2b11o$3b9o$4b7o$5b5o$6b3o$7bo!
[[ CELLBORDERS ZOOM 32 SNOW ]]

[rowett]

The new Help > Info > UI additions don't appear to be changing to the values they're set to.

Fixed, thanks.

Why does snow not appear for the bottom two patterns?

Because it's not supported when hexagonal or triangular cells are used. It does work with offset square cells.

[rowett]

Selections still don't appear to work correctly on bounded grids if CXRLE Pos is specified

Fixed, thanks.

It also appears much too wide on the homepage

This should be improved.

[muzik]

Yet to get the viewer to slow down on this page on iPad so I'll report back with results if/when this happens to see how things compare.

Status update: I've managed to get it to report a cap of around 50fps on the homepage. STOP 600 causes it to stop when the timer is at exactly 10.00 seconds, but I think that the timer itself is actually counting up slower than it should be.

IMG_7221.jpeg (435.36 KiB) Viewed 748 times

I've tried this with both Auto and 60 as the set refresh rate and the results are the same. (Build 1284)

EDIT: I manually timed this for 10 seconds and the timing results are as follows:

IMG_7222.jpeg (467.27 KiB) Viewed 743 times

[muzik]

How exactly are @COLORS lines with more than three values defined supposed to work? This does match Golly, but whether Golly itself should be working like this or not is what I don't know.

Code: Select all

x = 16, y = 16, rule = ruledef1
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledef1
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute

Code: Select all

x = 16, y = 16, rule = ruledef2
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledef2
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute
@COLORS
255 0 254 1 253 2

Code: Select all

x = 16, y = 16, rule = ruledef3
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledef3
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute
@COLORS
255 0 254 1 253

Code: Select all

x = 16, y = 16, rule = ruledef4
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledef4
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute
@COLORS
255 0 254 1 253 2 252

[rowett]

How exactly are @COLORS lines with more than three values defined supposed to work?

http://golly.sourceforge.io/Help/formats.html#colors

[rowett]

Status update: I've managed to get it to report a cap of around 50fps on the homepage

What's the model of iPad you have?

[muzik]

Status update: I've managed to get it to report a cap of around 50fps on the homepage

What's the model of iPad you have?

Air (4th generation), operating system version 18.3.2

----

I can't reproduce this consistently at all, but it's happened three times so far: when changing rules in the viewer, sometimes the pattern menu can be left in a glitched, partially-open state.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
A!
[[ ICONS COLOR N White ]]

Code: Select all

x = 6, y = 6, rule = Pulse2
QPO3Q$Q4.Q$Q4.Q$Q4.Q$Q4.Q$6Q!
[[ ICONS COLOR wire White ]]

IMG_7224.jpeg (310.89 KiB) Viewed 725 times

Why is the second pattern invalid? Is the [[ ICONS ]] specification somehow invalidating the rule table?

Code: Select all

x = 16, y = 16, rule = ruledefnoicons
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledefnoicons
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute

Code: Select all

x = 16, y = 16, rule = ruledeficons
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!
@RULE ruledeficons
@TABLE
n_states:256
neighborhood:Moore
symmetries:permute
[[ ICONS ]]

Are icons supposed to be toggleable for invalid rules?

Code: Select all

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

Since we're discussing frame rate: could a toggle be added in Advanced Settings that turns off the locking of 1x playback rate to 60fps, and instead iterates once per frame regardless of the refresh rate, as was the case before build 1210? I want to see if this will improve things on affected devices and browsers in the event that the frame rate detection and limitation itself is being too extreme.

[rowett]

Air (4th generation), operating system version 18.3.2

That has a 60Hz display so you should set Settings>Advanced>Refresh Rate to 60.
Any other value will give incorrect timings.

I can't reproduce this

Me neither.

Why is the second pattern invalid? Is the [[ ICONS ]] specification somehow invalidating the rule table?

Yes. Put your script commands before the rule table definition.

[muzik]

The first two of these four viewers incorrectly use the Cell Age shader, even though I think they shouldn't. In the first case:
- BACKGROUND = DEAD = DEADRAMP, so there's no dead cell history
- AGESTATES = 0, so there's no living cell ageing

For the second:
- ALIVE = ALIVERAMP, so there's no living cell ageing
- HISTORYSTATES = 0, so there's no dead cell history

The two viewers following them work as expected and use the Basic shader.

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ COLOR DEAD Black COLOR DEADRAMP Black AGESTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ COLOR ALIVERAMP Cyan HISTORYSTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ COLOR DEAD Black COLOR DEADRAMP Black COLOR ALIVERAMP Cyan LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ HISTORYSTATES 0 AGESTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Even if the Cell Age shader is in use, I still think the behaviour is incorrect in this following pattern: as AGESTATES is 0, all living cells should stay the same height regardless of how long they've been alive for. (Internally, they should only use state 64.)

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ AGESTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Also, is this supposed to produce an error? There are 64 different alive states from state 64 to state 127 (unlike history trail states, of which there are only 63, as state 0 is used for background cells).

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ AGESTATES 64 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

This somehow produced a NaN value for Zoom in build 1281, but this appears to have been fixed in build 1283. Documenting this here just in case, since there weren't any notes in version.txt about this bug being fixed, and it could show up again somehow.

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ AUTOSTART TRACKLOOP 4 -1 1 ]]

Feature request: could a command be added which offsets the starting generation for a loop? This would make things look better when looping something when using a Theme with history. For example, instead of looping from T=0 to T=9, this would instead loop from T=400 to T=409:

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ GPS 4 AUTOSTART TRACKLOOP 1 -1/4 1/4 LOOPOFFSET 400 ]]

Is it at all possible for LifeViewer to detect it has crashed, and display this accordingly? On iPad the contents of the viewer window become transparent when it resizes, but this doesn't appear to happen on desktop, where it just freezes solid, as though something is taking a long time to compute.

More performance benchmarking hopefully coming soon...

[muzik]

Air (4th generation), operating system version 18.3.2

That has a 60Hz display so you should set Settings>Advanced>Refresh Rate to 60.
Any other value will give incorrect timings.

I've done this but there is still sometimes slower playback than expected, so the issue must be arising somewhere else.

IMG_7225.jpeg (362.4 KiB) Viewed 693 times

[rowett]

I've done this but there is still sometimes slower playback than expected, so the issue must be arising somewhere else.

LifeViewer updates every time it is called by the browser via requestAnimationFrame:
"The frequency of calls to the callback function will generally match the display refresh rate."

LifeViewer measures the actual interval between each call and displays the average of the last 5 calls as the fps value when you use Settings>Advanced>Frame Times. It will cap this at the detected or specified Refresh Rate.

This means if the displayed fps is lower than the Refresh Rate then the browser is not calling LifeViewer often enough - probably because the device is busy. LifeViewer has no control over how often it is called.

[muzik]

Performance tests with some of the newly-discovered circular oscillators and spaceships. Tested on desktop.

Code: Select all

#N test case 1
x = 50, y = 58, rule = R20,C10,S158-320,B240-320,NC
24.9A$20.17A$17.23A$15.27A$13.30A$11.13A7CB13A$10.11A3D9C3B10A$9.B8A
9D7C5B8A$7.3B6A13D6C5B7A$6.5B4A15D6C5B7A$6.5B2A9E9D5C5B7A$5.6BA13E7D
5C5B7A$4.7B16E6D4C5B7A$4.6B18E5D5C4B8A$3.6B19E5D5C5B7A$3.5B5E8F6E6D5C
5B7A$2.C5B2E11F6E5D6C5B7A$.3C3BE14F5E5D6C5B7A$.4C2B15F5E4D6C6B7A$.5C
8FG7F5E3D6C7B7A$6C5F6G6F3E3D6C8B7A$5C5F8G5F3E3D4C10B6A$5C3F11G4F3E2D
3C11B7A$5C2F12G4F2ED2C11B10A$5CF6G2H6G3F2EC23A$5CF5G5H5G2F2E24A$D4C5G
8H3G2FE24A$3D2C4G10H3GFE24A$4DC3G13HGF24A$4DC3G14HG24A$5D2G16H23A$5D
2G7H2I8H22A$5DG6H10I3H7A2.11A$5DG5H14IH5A6.7A$5DG5H13I$6D4H9I$E5D4H6I
$.4ED4H5I$.5E4H4I$.6E3H4I$2.5E3H4I$2.6E2H4I$3.5E2H4I$3.6E2H4I$4.6EH4I
$5.4EFE4I30.I$6.6F4I28.2I$6.7F3I27.3I$7.7F3I25.5I$8.8FI23.7I$9.9F20.H
8I$10.8FG17.2H8I$12.5F5G11.5H7I$13.2F14G9H5I$14.14G10H4I$16.11G10H3I$
19.8G9H$22.4G7H!

Code: Select all

#N test case 2
x = 43, y = 56, rule = R20,C10,S160-316,B240-320,NC
16.6A$13.13A$12.16A$11.19A$10.22A$9.24A$8.12A5B9A$7.10A10B8A$6.9A14B7A
$6.7A8B8CB7A$5.7A6B13C6A$5.7A5B15C6A$4.8A4B17C6A$4.8A4B6C7D5C5A$4.8A4B
6C10D3C5A$3.10A3B5C13DC5A$3.10A3B5C5D4E5D5AB$3.11A3B4C4D7E4D3A3B$4.11A
2B4C3D10E3DA4B$5.10A2B3C3D12E2DA4B$6.10AB3C3D6EF6EDA5B$7.10AB2C2D5E5F
5E6B$8.9AB2C2D4E7F5E5B$9.9ABCD4E9F4E5B$11.8ACD3E11F4E4B$11.8ACD2E5F4G
4F3E2B2C$10.10A2E3F8G4F2EB3C$10.10AE3F10G3F2EB3C$10.10A2F12G4FE4C$11.
9AF14G3F5C$11.8A3G9H4G3F5C$13.5AG12H4G3F5C$14.A3I14H4G2F5C$17.8I7H4G2F
3CD$19.9I4H4GF2C3D$21.8I4H3GFC4D$23.6I4H3G6D$24.5I4H3G5D$25.4I3H4G5D$
26.3I3H3G6D$26.3I3H3G5D$25.4I3H2G4D2E$25.3I4HG6E$25.3I4H6E$24.4I3H6E$
I23.3I3H7E$.I21.4I2H7E$.2I19.4IH4F4E$.5I15.4I9F$.5IH13.4I9F$.6I3H3.G4.
3G10F$.7I6H10G6F$3.5I7H10G3F$5.3I8H10G$8.I8H5G$12.5H!

Code: Select all

#N test case 3
x = 49, y = 55, rule = R20,C10,S162-317,B240-320,NC
24.6A$22.11A$20.15A$19.18A$17.21A$16.23A$15.25A$14.12A8B7A$13.10A13B
6A$13.8A16B6A$12.8A18B6A$11.8A8B10C2B6A$11.9A5B14C6A$10.10A5B15C6A$
10.10A5B5C5D6C5A$10.10A5B4C9D4C5A$10.11A4B3C12D2C5A$11.10A4B3C13DC6A$
11.11A3B2C5D5E6D5A$12.10A3B2C4D8E4D5A$13.10A2B2C3D10E4D3AB$14.9A2B2C
3D11E3D2A3B$15.9ABC3D5E4F4E2DA4B$16.8ABC2D4E7F4EDA4B$17.8AB2D3E9F3EDA
4B$16.10AD2E12F3E5B$16.10ADE13F3E5B$16.10AE4F7G4F2E5B$16.10A3F9G4F2E
4BC$17.8AF13G4FE3B2C$17.7AF14G4FEB4C$18.4A18G3FE5C$20.2I12H6G4F4C$21.
5I10H4G3F5C$23.5I8H4G3F5C$24.6I6H4G3F5C$25.7I5H3G2F5C$26.7I3H4G2F2C3D
$27.6I3H4GFC4D$28.5I3H4GF5D$28.5I3H4G6D$29.3I4H4G5D$.2I25.4I4H3G6D$.
3I24.4I3H3G6D$.4I22.4I4H2G3E3D$.5I20.4I4H2G7E$7I18.5I3HG8E$.6I2H15.5I
3H9E$2.5I4H12.5I3H8E$3.4I6HG7.6I4F7E$5.2I7H6G5I8F4E$7.I7H7G12FE$8.7H
9G9F$10.6H8G8F$14.2H9G4F!

Code: Select all

#N test case 4
x = 49, y = 57, rule = R20,C10,S162-317,B239-320,NC
16.7A$11.18A$8.24A$7.25AB$5.28A3B$4.10A4B7C8A4B$3.8A5B8C5D4A6B$2.8A5B
6C10D2A7B$2.7A5B5C13DA8B$.8A4B5C16D7BC$.7A5B4C7D10ED6B2C$8A4B4C6D15E
3B3C$7A5B4C5D17E2B4C$7A4B4C6D18EB4C$7A4B5C5D18EB5C$7A4B5C5D7E8F4E6C$
6A6B5C4D7E10F3E5C$6A6B5C4D6E13FE6C$6A7B5C4D5E14F6C$7A8B4C3D4E16F5CD$
7A9B4C2D4E6F4G7F3C2D$9A8B3C2D4E5F7G5F2C3D$12A7B2C2D3E4F10G4F4D$18A4BD
2E4F12G3F4D$.22ADE3F6G3H5G2F4D$.23AE3F4G6H4G2F4D$.24A2F3G9H4GF5D$2.
23A2F2G11H4G5D$2.23AF2G13H3G5D$3.22AFG7H2I5H3G5D$4.21AG2H9I5H2G4DE$5.
7A5.7A2H12I4H2G2D2E$17.6A15I4H2G4E$25.13I5H5E$30.9I4H5E$33.6I4H5E$34.
5I4H5E$34.5I3H5E$34.5I3H5E$34.5I2H6E$34.5I2H5E$34.5IHE5F$34.4IH6F$34.
4I7F$33.5I6F$33.4I6F$32.4I7F$32.3I7F$31.2I4G4F$8.2I21.8GF$8.4I17.10G$
9.7I10.12G$9.8I10H9G$9.9I10H6G$9.9I11H3G$12.7I10H$18.I5H!

Code: Select all

#N test case 5
x = 54, y = 56, rule = R20,C10,S160-316,B239-318,NC
24.6FG$20.11F4G$17.5E9F7G$15.8E9F8G$13.11E9F7G3H$11.12E3H7IF6G4H$10.
2D8E5H10I5G6H$9.5D3E2G5H7I7.3G6H$8.7D3G5H5I12.G7H$7.7D3G5H5I14.6H2I$
7.6D4G4H4I18.4H3I$6.6D4G4H5I19.3H3I$5.6DF4G4H4I21.2H4I$4.3CD2C2F4G3H
5I22.H5I$4.5C3F3G4H5I23.5I$3.6C3F3G4H5I24.5I$3.5C3F4G4H6I23.6I$2.6C3F
4G5H5I24.4I$2.5C4F4G6H5I23.3I$2.5C4F4G7H5I23.I$.5CE4F5G7H4I23.I$.3C2B
E4F7G7H3I22.I$.5BE4F10G6H2I$.4B3E4F15G2HI$5B3E4F12G2F5A$5B3E8F3G5F8A$
5B4E14FD8A$5BD3E12F2E10A$4B2D4E10F2ED10A$3BA3D3E8F3E2D10A$3BA3D4E5F5E
2DB9A$B3A4D12E3DB9A$5A4D10E3DC2B9A$5A5D8E4DC3B9A$5A6D5E6DC3B10A$6A7D
2E6D2C4B10A$.5AC13D3C4B10A$.5A2C12D3C5B10A$.6A3C9D4C5B10A$2.5A5C7D4C
6B10A$3.5A7C2D6C6B10A$3.5AB14C6B10A$4.5A2B11C7B9A$4.5A5B7C9B8A$5.5A
20B7A$5.6A18B8A$6.6A16B8A$7.6A13B9A$7.8A7B12A$8.25A$9.23A$10.21A$12.
17A$13.15A$16.10A$20.3A!

Code: Select all

#N test case 6
x = 40, y = 42, rule = R14,C10,S80-158,B120-160,NC
17.4I$14.7I$12.H9I$10.4H9I$8.8H$7.6H$6.5H$5.2G3H$4.5G$4.4G$3.4G$2.4G
18.6A$2.4G17.9A$2.3GF16.12A$.4F16.14A$.4F16.15A$.3F2I15.16A$.3F2I14.
10A2B6A$4F2I12.10A5B6A$4F2I11.9A8B5A$3FE3I9.I8A9B5A$F3E3I7.2IH7A11B5A
$4E4I4.4IH7A11B5A$4EH10I2HF5A2B7C4B4A$.3E2H8I3HGF2A12C3B4A$.3E3H7I2H
2GF2E4D8C3B4A$.3ED3H4I4H2G2F3E5D5C3B4A$.3ED11H2G3F3E6D3C3B3A$2.E2DG9H
3G3F4E5D3C3B3A$2.4D2G7H3G4F4E4D3C2B4A$3.3D4G4H4G4F5E3D3CB4A$3.4D11G4F
5E3D3C5A$3.4DC9G5F4E4D3C4A$4.3D2C12F5E3D3C4A$5.2D3C10F5E4D2C4A$6.D4C
7F6E4D2C5A$7.5CBEF8E4DC6A$8.5C2B7E4D7A$9.4C6B12A$11.2C7B10A$13.7B8A$
16.5B2A!

Code: Select all

#N test case 7
x = 31, y = 36, rule = R12,C10,S63-119,B90-120,NC
15.4G2H$11.F7G4H$9.4F7G5HI$7.8FG4.G4H3I$6.5F2H2I8.2H4I$5.4E2H3I11.H4I
$5.3E3H2I14.4I$4.4E2H3I15.3I$3.4E3H2I17.2I$3.3EG3H2I$2.4DG3H2I$2.3D2G
3H2I$.4D2G3H3I$.3DF3G4H3I$.2DC2F2G9H$2D2C2F2G7HG4A$3C3F8GF6A$3C4F6G2F
6A$4C3F4G4F9A$3CB4FG5FEC4AI5A$.2CBE8FE2D11A$.3B2E7FE2DCB10A$.3B3E5F2E
2D2C2B8A$.3BD4E2F3E2D3C3B6A$2.3BD7E3D3C4B5A$2.3B3D5E3D4C4B4A$2.3BA10D
4C4B3A$3.B3AC7D5C3B4A$4.4A11C4B4A$5.4A9C4B5A$6.5A4C6B5A$7.6A7B6A$8.17A
$10.14A$13.10A$17.A!

Results:

WASM off:
1: 6.9s / 9.8s
2: 16.0s / 20.8s
3: 6.1s / 7.9s
4: 39.2s / 56.9s
5: 44.6s / 64.5s
6: 1.9s / 2.5s
7: 0.6s / 0.8s

WASM off, HISTORYSTATES 0:
1: 6.6s / 9.4s
2: 14.4s / 18.6s
3: 5.5s / 6.1s
4: 36.8s / 53.2s
5: 41.1s / 59.5s
6: 1.8s / 2.4s
7: 0.6s / 0.8s

WASM on:
1: 3.4s / 4.8s
2: 7.7s / 10.0s
3: 3.0s / 3.9s
4: 18.5s / 27.6s
5: 21.1s / 31.2s
6: 1.0s / 1.3s
7: 0.4s / 0.5s

WASM on, HISTORYSTATES 0:
1: 3.2s / 4.6s
2: 6.9s / 9.0s
3: 2.7s / 3.5s
4: 17.3s / 25.8s
5: 19.5s / 28.8s
6: 0.9s / 1.2s
7: 0.3s / 0.4s

Higher range cell age processing may be something to optimize, as the time difference scales noticeably for higher periods.

For further convenience, could the elapsed time for Identify also be displayed in the table near the bottom, rather than it only being available in Help?

[muzik]

You can define your own custom Theme using script commands. This pattern creates a custom Theme that is all black so it can advance the pattern to a specific state before displaying it:

Code: Select all

#C When loaded automatically run to T=1000 with the display off
#C [[ AUTOSTART ZOOM 1 STOP 1000 STEP 10 ]]
#C [[ COLOUR DEAD Black COLOUR ALIVE Black COLOUR ALIVERAMP Black ]]
#C [[ T 999 THEME CUSTOM "Please wait..." ]]
#C [[ T 1000 STEP 1 THEME 1 POPUPWIDTH 640 ]]
x = 555, y = 283, rule = B013468/S02
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$555o$
555o$555o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$424o$
424o$424o$424o!

Something may have changed about theme handling since this was posted. Does DEADRAMP no longer default to DEAD if unspecified?

[muzik]

I can confirm that embedded viewers can appear cut off on phone screens:

Fixed in build 1280, thanks.

Thanks for this - waiting on the Minecraft Wiki updating so I can confirm this.

Can confirm that this is fixed for embeds such as the one described.

Screenshot_20250314-174717_Samsung Internet.jpg (222.52 KiB) Viewed 646 times

I do want to point out that the LifeViewer Pro embed page is more than a bit too tall to be useful on such a screen size and shape, though.

Screenshot_20250314-175348_Samsung Internet.jpg (50.81 KiB) Viewed 646 times

There's also a considerable gap between the bottom of the viewer and the boxes it's linked to, which further impacts usage of this page. Zooming out is required to see the extent of this

Screenshot_20250314-175516_Samsung Internet.jpg (62.1 KiB) Viewed 646 times

Ideally I want to get test results on multiple types of devices, so having the page act like this on one of them is going to get in the way.

[muzik]

We are at post 4,000 on this thread! I have found a potentially interesting triangular INT rulespace with 104 transitions. Here is the neighborhood for this rulespace (blue cells are the neighborhood, with the white cell representing the center cell):

Code: Select all

# [[ COLOR ALIVE 255 255 255 COLOR DYING 0 0 255 COLOR DYINGRAMP 255 192 0 ]]
x = 5, y = 3, rule = 0123456789xyz//4L
.B.B$2BA2B$.3B!

Could this system also be applied to the 9-cell Triangular Vertices neighbourhood?

Code: Select all

x = 1, y = 1, rule = B1/SLV
bo!
[[ STARTFROM 1 ]]

I assume the same naming scheme could be used. The six cells touching the central triangle only at the vertices would stay the same, whereas the three which touch the central triangle along and edge would be rotated 60 degrees (so to speak) such that they become the "far" triangles that make contact at vertices.

[confocaloid]

^^ I think it would be better to begin by looking for already known "interesting" objects/reactions that would be enabled by such a notation.
That, and also double-checking to make sure that the notation/space is well-defined and consistent.

Maybe it's worth noting here that there are already multiple implemented/supported notations, not all of which get enough attention.
For example, the notation for non-totalistic isotropic CA with honeycomb neighbourhood already got some use, despite not (yet) being implemented in Golly. Implementing it in Golly might be more of a priority than implementing new spaces without much known objects.

Additionally, weighted neighbourhoods provide an already available way to explore large subsets of many such spaces. This allows searching for "interesting" objects/reactions, to have some evidence to be able to decide whether or not a given space needs any dedicated notation at all.

The following example should show a way of working with a large subspace of "two-state isotropic CA with range-1 neighbourhood on the triangular tiling". The three side-by-side adjacent neighbours, the three distant neighbours, and the six intermediate neighbours are counted separately. Combined with two possible states of the middle cell, this yields (2 x 4 x 7 x 4 = 224) distinguishable fully-specified cell conditions. For each of those 224 conditions the rules can prescribe either "the cell will live in the next generation" or "the cell will be dead in the next generation", which means this weighted neighbourhood allows to specify any of 2^224 different isotropic cellular automata. It's a subset, but it's a large subset.
search.php?keywords=NW000000000001041C0 ... 000000000L

Code: Select all

#C [[ THEME MCell GRID STARTFROM 1 ]]
x = 10, y = 1, rule = R2,C0,S0,B1,4,28,NW000000000001041C0401041C001C0400040104000000000000L
o8bo!

Code: Select all

#C [[ THEME Caterer GRID STARTFROM 1 ]]
x = 10, y = 1, rule = R2,C0,S0,B1,4,NW000000000001041C0401041C001C0400040104000000000000L
o8bo!

Code: Select all

#C [[ THEME Caterer GRID STARTFROM 1 ]]
x = 10, y = 1, rule = R2,C0,S0,B1,28,NW000000000001041C0401041C001C0400040104000000000000L
o8bo!

Code: Select all

#C [[ THEME Caterer GRID STARTFROM 1 ]]
x = 10, y = 1, rule = R2,C0,S0,B4,28,NW000000000001041C0401041C001C0400040104000000000000L
o8bo!

[muzik]

Has the Identify period limit of 2^22 / 10^7 been intentionally removed? A welcome change if so, but it doesn't appear to have been announced anywhere.

Code: Select all

x = 29, y = 19, rule = B345/S5
9bobobobobobo$7bobobobobobobobo$8bobobobobobobo$6bo5bobo7bo$6bo5bobo7b
o$4bo7bobo9bo$4bo19bo$2bo23bo$2bo23bo$o27bo$o27bo$2bo5bobo17bo$2bobobo
bobo17bo$4bobobobo15bo$4bobobobo15bo$6bobobo13bo$6bobobobobobobobobobo
$7bobobobobobobobobo$7bobobobobobobobobo!
[[ THEME Mono SHADER Basic AUTOIDENTIFY ]]

This appears to get incorrectly identified as period-114 after around 118 million generations. Possible hash collision or out-of-memory error?

Code: Select all

x = 23, y = 16, rule = M0,1,2,3,4,10,6,11,8,9,5,13,12,14,7,15
14b2o$14bo$10b2obob2o$9b4obob3o$6b2o2b4o3b3o$5bob3ob4o2bob2o$2b4ob5ob
3o3bobo$b5obobob3ob2o2bo2bo$b5obobob3ob2o2bo2bo$2b4ob5ob3o3bobo$5bob3o
b4o2bob2o$6b2o2b4o3b3o$9b4obob3o$10b2obob2o$14bo$14b2o!

All of this aside, things seem to perform smoothly until 100 million generations or so, after which things get choppy; if a cap is to be reimplemented, this seems like a reasonable upper limit.

If this is unintentional and the memory limit is to be reimplemented: how can I help to understand what LifeViewer's memory limitations are so we can set an upper bound that makes the most sense?

----

Additionally, weighted neighbourhoods provide an already available way to explore large subsets of many such spaces.

Related: I remember "layer-totalistic" rules being discussed in relation to 3D isotropic rules here - could a similar system be applied for the triangular grid? Here, the red, green and blue neighbours could get separate sets of conditions, and gray cells could possibly also be included in an extended version. This would be a subset of weighted rules in general, am I correct?

Code: Select all

x = 7, y = 4, rule = //6L
3.E$2.CDC$.CBABC$EDCBCDE!
[[ COLOR alive White COLOR "dying 1" Red COLOR "dying 2" Lime COLOR "dying 3" Blue COLOR "dying 4" Gray ]]

----

EDIT: Seems LifeViewer actually pulled through with White Whale. The results aren't without their imperfections, but this came out to be much more than what I expected it to be:

Screenshot_20250315_124439.png (103.31 KiB) Viewed 584 times

Screenshot_20250315_124449.png (136.44 KiB) Viewed 584 times

Periodicity was recognised first at generation 198148449.

[R2INT]

We are at post 4,000 on this thread! I have found a potentially interesting triangular INT rulespace with 104 transitions. Here is the neighborhood for this rulespace (blue cells are the neighborhood, with the white cell representing the center cell):

Code: Select all

# [[ COLOR ALIVE 255 255 255 COLOR DYING 0 0 255 COLOR DYINGRAMP 255 192 0 ]]
x = 5, y = 3, rule = 0123456789xyz//4L
.B.B$2BA2B$.3B!

Could this system also be applied to the 9-cell Triangular Vertices neighbourhood?

Code: Select all

x = 1, y = 1, rule = B1/SLV
bo!
[[ STARTFROM 1 ]]

I assume the same naming scheme could be used. The six cells touching the central triangle only at the vertices would stay the same, whereas the three which touch the central triangle along and edge would be rotated 60 degrees (so to speak) such that they become the "far" triangles that make contact at vertices.

I am certain that the same system can be used for both the Triangular Biohazard andTriangular Vertecies neighborhood. Both of them have 9 cells, and the geometries are very similar. Compare the two neighborhoods and their sets of neighbors (light blue represents edge cells, while blue represents hexagonally adjacent cells):

Code: Select all

#N Biohazard Neighborhood
# [[ COLOR 1 255 255 255 COLOR 2 0 128 255 COLOR 3 0 0 255 ]]
x = 5, y = 3, rule = 23/3/4LB
.C.C$CBABC$.CBC!

Code: Select all

#N Vertecies Neighborhood
# [[ COLOR 1 255 255 255 COLOR 2 0 128 255 COLOR 3 0 0 255 ]]
x = 5, y = 3, rule = 23/3/4LV
.CBC$C.A.C$BC.CB!

Notice that the geometries are identical for both neighborhoods. Thus, the same Hensel-like INT notation can be used for both neighborhoods.

[muzik]

If we want to get really ridiculous, this oscillator has a period of 113725632. This is a few orders of magnitude above the current limit, but Identify used on this reaches 1 million generations in just 21 seconds for me. Extrapolating from this result, we could have it conclude one evolution cycle in just about 40 minutes, and probably detect its period in under twice that. It also appears to stay enclosed inside of a 3-by-201 bounding box, which contains less cells than a 25-by-25 square. Perhaps it'd be a stretch to ask for things like this to be identifiable, but again, this last thing is just so,etching that's been on my mind and is in no way a serious suggestion.

Code: Select all

x = 3, y = 199, rule = B2cei3j4c5i6c8/S1e2i3-ckqr4air5i6ci8
bo$3o$3o$3o$3o$3o$3o$3o$obo$3o$obo$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o
$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$3o$3o$3o$
3o$3o$3o$3o$3o$obo$3o$obo$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o
$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$
3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$
3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$obo$3o$obo$3o$obo$3o$obo$3o$3o$
3o$3o$3o$obo$3o$obo$3o$obo$3o$obo$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$3o$
3o$obo$3o$obo$3o$obo$3o$obo$3o$3o$3o$3o$3o$3o$3o$3o$3o$obo$3o$obo$3o$o
bo$3o$obo$3o$3o$3o$3o$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo$3o$obo
$3o$obo$3o$3o$3o$bo!

Update: with the newly removed limit we get these results. Identification took longer than with white-whale.rle:

Screenshot_20250315_145539.png (102.6 KiB) Viewed 562 times

Screenshot_20250315_145552.png (140.21 KiB) Viewed 562 times

I assume that an integer overflow is occurring when summing populations to calculate an average?

[rowett]

Has the Identify period limit of 2^22 / 10^7 been intentionally removed? A welcome change if so, but it doesn't appear to have been announced anywhere.

It's not complete yet which is why it wasn't announced.

[confocaloid]

[...] Related: I remember "layer-totalistic" rules being discussed in relation to 3D isotropic rules here - could a similar system be applied for the triangular grid? [....]

While probably it *could* be applied, most likely it shouldn't be applied, until and unless it is clear and widely agreed exactly how it should be defined, understood, and applied.

The thread you linked to discusses a more complicated notational system, compared to the majority of existing notations. It boils down to a compressed encoding of the definition of a cellular automaton.
Given that the already existing notations (including Hensel notation for two-state isotropic CA with Moore neighbourhood) already cause substantial confusion, with people commonly (mis)using related terminology in inconsistent, counterintuitive, and/or outright self-contradictory and nonsensical ways, it would be probably better to avoid inventing notations adding more layers of complexity on top of what is already there.

As far as I can tell, straightforward definitions using weighted neighbourhoods already suffice to cover the same subspaces. They are simple to understand, and they don't require memorization or tables of letters. Any newly-invented notation on top of that is going to add unnecessary headaches.

There are many different subspaces. Some of those subspaces might deserve a dedicated notation at some point (in which case the notation should be consistent and intuitively understandable, as opposed to being an awkward ad-hoc kludge). But the majority of possible subspaces don't need any dedicated notation at all, because most subspaces are basically "boring" and the existing notation using weighted neighbourhoods suffices for them.

Which subspaces are "interesting", can only become clear after they are already explored to some extent. Golly/LifeViewer cannot implement notations for dozens or hundreds of subspaces in a maintainable way, that is going to lead to maintenance hell (and also to usability hell). That means the above suggestions about adding newly-invented notations are likely misplaced in this thread. If you think your subspace is interesting, then the first step may be for you to write a Golly script (Lua/Python) to implement some notation for it, converting it (or a subset) into weighted neighbourhood based definitions.

Tangential, were the large-scale wiki changes discussed anywhere? It looks like some sort of editing campaign, I don't remember any discussion leading to it, and I can see more than one way how it is likely to lead to further problems.