Pattern viewer for forum threads

[muzik]

I've noticed on desktop that pattern playback seems to exceed 60gps again sometimes. This probably isn't intended given previous changes but it's what I prefer - I don't know if this could be made a toggle somehow.

If the speed slider is 1x then LifeViewer will be attempting to keep processing at 60gps regardless of the reported frame rate.

What I've been noticing is seemingly the opposite - despite displaying 60fps, patterns at 1x appear to be running closer to 144gps.

I'm not sure if this is related, but LifeViewer seems to be running considerably slower on the ipad now, at 30fps and 30gps at 1x:

IMG_6554.jpeg (259.52 KiB) Viewed 1932 times

[muzik]

I've noticed that some patterns that Identify would previously consistently generate period maps and strict volatility values for no longer will have any generated at all:

Code: Select all

x = 54, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
54o!

Testing the above pattern, I always get a map and strict volatility in build 1226, and neither in build 1228. (The intermediate build 1227 does not appear to be available for whatever reason.)

[confocaloid]

Identify says that this oscillator has mod 107334. I believe the mod is 53667 instead.

[...] And here is a p107334 oscillator with bounding box 9-by-9:

Code: Select all

x = 9, y = 9, rule = B23678/S3478Investigator
9O$O.2A4.O$O2A.A.A.O$O7AO$O4A3.O$O.A.A.2AO$O2.3A2.O$O6.AO$9O!
#C [[ GRID ]]

[muzik]

Try turning on the grid, cell borders, starfield, or adjusting the angle or layers sliders:

Code: Select all

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

[muzik]

AUTOIDENTIFY will "work" in the wiki's thumbnail viewers, but this is ultimately useless and wastes processing power as when clicking on the thumbnail everything will end up being computed again.

True. I've silently disabled it for [[ THUMBLAUNCH ]] viewers.

Much the same is also true of STARTFROM - those could also eat up a bunch of performance despite resetting once the popup is created:

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ THUMBLAUNCH THEME Mono STARTFROM 4194304 ]]

I'm not sure if this should be changed, though, since there is definitely justification for having a thumbnail display a given generation.

If we save a pattern at a given time such that it has a much shorter RLE, the code box's size will not adjust to match, and will retain a bunch of empty space within:

Code: Select all

x = 121, y = 121, rule = B/S0
121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$57o7b57o$57o7b57o$57o7b57o$57o3bo3b57o$57o7b57o$57o7b57o$57o7b57o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o$121o
$121o!
[[ STARTFROM 1 ]]

The inverse is not true. However, it can produce code boxes which are considerably larger than the new "maximum" size, which I'm not sure is intended:

Code: Select all

x = 1, y = 1, rule = B12345678/S012345678
o!
[[ STARTFROM 120 ]]

Open both of these patterns, remove the block at the top right by drawing on it to delete it, and then save the pattern. The x and y values in the RLEs will differ for some reason.

Code: Select all

x = 11, y = 19, rule = B3/S23
9b2o$10bo15$o4b3o$2o$6bo!
[[ STARTFROM 130 ]]

Code: Select all

x = 11, y = 19, rule = R1,C2,S2-3,B3
9b2o$10bo15$o4b3o$2o$6bo!
[[ STARTFROM 130 ]]

This is probably known, but the neighbour shader doesn't work for hexagon or triangle cell shapes, rendering things as black instead, even though it does at least render some relevant colours when rectangles are forced:

Code: Select all

x = 1, y = 2, rule = B123456/S0123456H
$o!
[[ STARTFROM 20 ZOOM 4 SHADER Neighbor ]]

Code: Select all

x = 1, y = 2, rule = B123456789xyz/S0123456789xyzL
$o!
[[ STARTFROM 20 ZOOM 4 SHADER Neighbor ]]

I've updated the known bugs list on the wiki with more test cases.

[rowett]

I've noticed that some patterns that Identify would previously consistently generate period maps and strict volatility values for no longer will have any generated at all

That pattern requires 437Mb for the calculation which is over the 256Mb limit in LifeViewer Standard.

[muzik]

This Identify issue appears to be occurring once again much like how it did a year prior:

Code: Select all

x = 378, y = 392, rule = B3-r4cekz5ai6-ae78/S2ae3-ai4-cekz5r678
25$62b2o$61bob2o$61b3o$62bo$66bo$65bobo$66bob2o$67b3o$67b3ob2o$72bo$
69bob2o$69b3o7$73bo$72b4o$72b4o$73b4o$74b2o$69bobo$69bo$69b3o2$64bobo$
64bob2o$64b2o$65b3o8$95bo$93bo$92b3o$93bo$91bo$96b2o$96b2obo2$97bo3b4o
$100bob2o$99bob3o$99b4obo$99b3o$99bo2bo6$102bobo$101b3o2bo$101b4o$102b
4obo$103b4o$104b4o$99bobo3b2o2$101bo2$97bo2$95bo8$124bo2$124bo$118b4o
4b2o$118bo2b5obo$118bo2b3ob2o$118b4ob2o$119b2o2bo$119b4o$115bobobobo$
119b2o$118bobo$118b2o4$121b2o$121b3o$121bo2bo$122b4o$122b4o$122b2o2b2o
$121bo2bob3o$120b4ob3obo$120b4ob3ob2o$121b4o3b3o$122b2o15$150b2o$151b
2o$148bob4o$150b5o$149bo3bobo14b4o$151b2ob3o12bob3o$153bob3o11b4obo$
153bob4o10b4o$155b2obo7b3o$154bo10bob2o$156bo8b4o$165b4o$165b2o$167bo
19$189bo$189b3obo$189b3o2bo$189bob2o11bobo$190bob3o7bo2b3o$191bob2o9b
4o$192b4o5bob4o$188bo13b4o$201b4o$202b2o3bobo2$207bo2$211bo2$213bo28$
233bo$232b4o$231b4o$233b3o$229b6o$229b4ob2o$227bob2ob2o$226b2ob4o$225b
5obo$226b5o$226bobobo18bo$245bob3o$244bo2b3o$246b2obo$244b3obo$244b2ob
o$243b4o$250bo23$279bo$275bob3o$274bo2b3o$276b2obo$274b3obo$274b2obo$
273b4o$280bo4bo$285b2o$284bobo7$289bo$288b4o$287b4o$289b3o$285b6o$285b
4ob2o$283bob2ob2o$282b2ob4o$281b5obo$282b5o$282bobobo16$320bo$321b2o$
319b4o$319b4o$319b2obo$319b3o$315b4o$313bob4o11b3o$314b3obo13bo$314b4o
13bo2$333b2o$332b3o$332b3o$338b2o$337b4o$336b4o$335b5o$335b5o$336bo!
[[ AUTOIDENTIFY MAXGRIDSIZE 9 KILLGLIDERS ZOOM -1 ]]

[rowett]

Identify says that this oscillator has mod 107334. I believe the mod is 53667 instead.

Fixed, thanks!

[rowett]

Try turning on the grid, cell borders, starfield, or adjusting the angle or layers sliders

Fixed, thanks!

This Identify issue appears to be occurring once again much like how it did a year prior

Fixed (again), thanks!

Open both of these patterns, remove the block at the top right by drawing on it to delete it, and then save the pattern. The x and y values in the RLEs will differ for some reason.

Fixed, thanks.

[rowett]

Much the same is also true of STARTFROM:
I'm not sure if this should be changed, though, since there is definitely justification for having a thumbnail display a given generation.

It shouldn't be changed.

If we save a pattern at a given time such that it has a much shorter RLE, the code box's size will not adjust to match, and will retain a bunch of empty space within

The inverse is not true. However, it can produce code boxes which are considerably larger than the new "maximum" size, which I'm not sure is intended

If a code box is changed after the page scan (typically via Save Pattern or Settings>Pattern>Randomize) then the browser will resize the box since it detects the contents have changed. I like this since it is then obvious there was a change.

[muzik]

On LifeViewer Pro specifically (happens on /lifeviewer/pro/ regardless of whether WASM Engine is enabled, but does not happen on plain /lifeviewer/) when using iPad Safari, this pattern will consistently cause LifeViewer to completely run out of memory.

Code: Select all

x = 393, y = 201, rule = R50,C0,M0,S0..0,B5..5,NM
8bo379bo$7bo$6bo$5bo$4bo387bo$3bo4$2bo4$bo4$o175$392bo4$o387bo$bo193bo
$2bo191bo$3bo189bo$4bo187bo!
[[ MAXGRIDSIZE 14 ZOOM -16 STARTFROM 83 SHOWTIMING EXTENDEDTIMING ]]

Interestingly the second pattern can be shown-in-viewer despite being invalid for twice as many reasons as the first pattern:

Code: Select all

x = 73, y = 3, rule = R1,C2,S5,B3,NW111101111History
$b72o$b72o!

Code: Select all

x = 73, y = 3, rule = R1,C2,S5,B3,NW111101111History
$b72o$b72B!

Results differ across algorithms with the same input pattern and rule with respect to camera zoom and positioning if we press Play:

Code: Select all

x = 2, y = 4, rule = B2/S
o$bo$bo$o!
[[ STARTFROM 260 AUTOFIT MAXGRIDSIZE 9 THEME Book ]]

Code: Select all

x = 2, y = 4, rule = R1,C2,S,B2
o$bo$bo$o!
[[ STARTFROM 260 AUTOFIT MAXGRIDSIZE 9 THEME Book ]]

Also, does the grid boundary simply not kill Generations patterns at all if the general-range algorithm is in use? We get no messages about cells being killed, unlike for range-1.

Code: Select all

x = 2, y = 2, rule = /2/3
2o$2o!
[[ STARTFROM 240 ZOOM 1 MAXGRIDSIZE 9 ]]

Code: Select all

x = 2, y = 2, rule = R1,C3,S,B2
2o$2o!
[[ STARTFROM 240 ZOOM 1 MAXGRIDSIZE 9 ]]

[muzik]

If we mouse over the rule name at the bottom left, the neighbourhood is correctly given as 1D for even rules, but says Moore for odd emulated rules.

Code: Select all

x = 1, y = 1, rule = W30
o!
[[ AUTOFIT STARTFROM 71 SHOWGENSTATS ]]

Code: Select all

x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71 SHOWGENSTATS ]]

Instead of using the 2-state method and killing every cell each generation, could alternating 1D rules instead use the 3-state emulation method for consistency? We know from the rulestring what to use for state 1 and for state 2.

Code: Select all

x = 24, y = 1, rule = W37
ob3o3bobo2bo2b5o2bo

Code: Select all

x = 24, y = 1, rule = W218|W164
ob3o3bobo2bo2b5o2bo

Also, here are some example Theme definitions for emulated Wolfram rules (grid color and major definitions are not included, but these would simply be the same as 2-state versions):

Code: Select all

#N Mono
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 192 192 192
COLOR 2 144 144 144
]]

Code: Select all

#N Blues - same as current, no change
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71 ]]

Code: Select all

#N Fire
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 240 144 0
COLOR 2 192 96 0
]]

Code: Select all

#N Poison
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 96 240 96
COLOR 2 0 192 160
]]

Code: Select all

#N Yellow
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 32 128
COLOR 1 255 255 128
COLOR 2 255 160 96
]]

Code: Select all

#N Gray
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 128 128 128
COLOR 2 96 96 96
]]

Code: Select all

#N Day
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 255 255 255
COLOR 1 0 64 128
COLOR 2 0 128 64
]]

Code: Select all

#N Occupied
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 255 255 255
COLOR 2 255 255 255
]]

Code: Select all

#N Red
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 240 240 240
COLOR 2 240 240 240
]]

Code: Select all

#N History
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 0 240 0
COLOR 2 0 192 144
]]

Code: Select all

#N Generations
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 255 255 0
COLOR 2 255 144 0
]]

Code: Select all

#N Golly
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 0 255 127
COLOR 2 127 0 255
]]

Code: Select all

#N MCell
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 255 255 0
COLOR 2 255 219 0
]]

Code: Select all

#N Catagolue
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 192 255 238
COLOR 1 0 0 0
COLOR 2 0 128 0
]]

Code: Select all

#N Caterer
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 54 57 62
COLOR 1 255 255 255
COLOR 2 192 192 192
]]

Code: Select all

#N Life32
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 255 255 255
COLOR 1 0 0 128
COLOR 2 0 0 254
]]

Code: Select all

#N Margolus
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 0 0 0
COLOR 1 255 192 0
COLOR 2 192 144 0
]]

Code: Select all

#N Book
x = 1, y = 1, rule = W73
o!
[[ AUTOFIT STARTFROM 71
COLOR 0 255 255 255
COLOR 1 0 0 0
COLOR 2 96 96 96
]]

Can proper names be added for states 1 and 2 to indicate which is an odd generation and which is an even generation?

[muzik]

I managed to reduce the pattern to the following mod1275 p750975 oscillator on a torus with a shift in one direction. How long this takes to identify on the same system?

Code: Select all

x = 589, y = 23, rule = B378/S23:T589-3,23
11bo26b2o176b2o205bo$39bo176bo26b2o176b2o$37b2o205bo176bo26b2o$37bo26b
2o176b2o205bo$65bo176bo26b2o176b2o$63b2o205bo176bo26b2o$63bo26b2o176b
2o205bo$91bo176bo26b2o176b2o$89b2o205bo176bo26b2o$89bo26b2o176b2o205bo
$117bo176bo26b2o176b2o$115b2o205bo176bo26b2o$115bo26b2o176b2o205bo$
143bo176bo26b2o176b2o$141b2o205bo176bo26b2o$141bo26b2o176b2o205bo$169b
o176bo26b2o176b2o$167b2o205bo176bo26b2o$167bo26b2o176b2o205bo$195bo
176bo26b2o176b2o$15b2o176b2o205bo176bo$16bo176bo26b2o176b2o$14b2o205bo
176bo26b2o!

Pro 1257 manages this in 83.3s for period and 105.6s for evaluation (Safari).

[rowett]

On LifeViewer Pro specifically (happens on /lifeviewer/pro/ regardless of whether WASM Engine is enabled, but does not happen on plain /lifeviewer/) when using iPad Safari, this pattern will consistently cause LifeViewer to completely run out of memory.

This is expected. There's work to do on the allocator since the memory model is completely different.

[muzik]

Grayed-out scroll arrows are present for the period map but not the frequency map in this following case, even though neither case requires scrolling for the legend.

Code: Select all

x = 5, y = 34, rule = M0,2,1,12,4,5,6,7,8,9,10,11,3,13,14,15
$bo2bo$2b2o3$bo2bo$2b2o3$bo2bo$2b2o3$bo2bo$2b2o3$bo2bo$2b2o3$bo2bo$2b
2o3$bo2bo$2b2o3$bo2bo$2b2o3$bo2bo!
[[ AUTOIDENTIFY ]]

I don't think KILLGLIDERS should be killing things when it's about to interact with other cells:

Code: Select all

x = 29, y = 25, rule = B3/S023History
$29F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.
F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F3.A23.F$F2.A24.F$F2.3A22.F$F27.
F$29F!

Code: Select all

x = 29, y = 25, rule = B3/S023History
$29F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.
F$F27.F$F27.F$F27.F$F27.F$F27.F$F27.F$F3.A23.F$F2.A24.F$F2.3A22.F$F27.
F$29F!
[[ KILLGLIDERS ]]

Also, is this supposed to have a mod of 742? The period map, outer box's symmetry and Go To Gen 742 imply so, but I haven't checked every single generation.

Code: Select all

x = 81, y = 91, rule = B3/S023History
35F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F
$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.
F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F
33.F$F3.A29.F$F2.A30.F$F2.3A28.F$F33.F$35F!

...seemingly yes, since [R]Super and [R]Investigator detect it just fine.

Code: Select all

x = 81, y = 91, rule = B3/S023Super
35F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F
$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.
F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F33.F$F
33.F$F3.A29.F$F2.A30.F$F2.3A28.F$F33.F$35F!

Code: Select all

x = 35, y = 41, rule = B3/S023Investigator
35C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C
$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.
C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C33.C$C
33.C$C3.A29.C$C2.A30.C$C2.3A28.C$C33.C$35C!

Help > Info > Cells displays a value for ALIVERAMP here, even though it omits DEAD and DEADRAMP (as expected). Also, does setting HISTORYSTATES and AGESTATES to 0 cause the Basic shader to be used? It probably should as there's no cell ageing to be processing.

Code: Select all

x = 3, y = 2, rule = B2a/S2a3n:P0,2
obo$b2o!
[[ ZOOM -2 STARTFROM 256 HISTORYSTATES 0 AGESTATES 0 ]]

A small Identify suggestion: for oscillators, could the number of subperiods and the number of nonzero frequencies present in an oscillator be counted and displayed in the Res table?

[muzik]

Code: Select all

#C [[ ICONS AUTOSTART GPS 8 SHOWTIMING EXTENDEDTIMING ]]
x = 74, y = 47, rule = AnimatedPixelArt
pJuOpJuOpJuOpJuOpJuOpJuOpJuO6.pJBpJBpJBpJBpJBpJBpJB6.pJBpJBpJBpJBpJBpJ
BpJB6.pJBpJBpJBpJBpJBpJBpJB$uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.uPuQuPuQuPuQ
uPuQuPuQuPuQuPuQ6.uPBuPBuPBuPBuPBuPBuPB6.14B$pJuOKtLKtLKtLKtLKtLpJuO
6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB$uPuQ10tLuPuQ6.
uPuQ10tLuPuQ6.uPBtL.tL.tL.tL.tL.uPB6.2B10.2B$pJuOKtLOtVpXvGOtVKtLpJuO
6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB$uPuQ2tLtTtU
vEuUtTtU2tLuPuQ6.uPuQ2tLtTtUvEuUtTtU2tLuPuQ6.uPBtL.tT.vECtT.tL.uPB6.
2B4.2C4.2B$pJuOKtLpTvGpTuUOtLKtLpJuO6.pJBK.pTCpTCO.K.pJB6.pJBK.pTCpTC
O.K.pJB6.pJBK.pTCpTCO.K.pJB$uPuQ2tLuUvF2uUtTtU2tLuPuQ6.uPuQ2tLuUvF2uU
tTtU2tLuPuQ6.uPBtL.uUCuUCtT.tL.uPB6.2B2.4C4.2B$pJuOKtLOtVpXvGOtVKtLpJ
uO6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB6.pJBK.O.pXCO.K.pJB$uPuQ2tLtT
tUvEvFtTtU2tLuPuQ6.uPuQ2tLtTtUvEvFtTtU2tLuPuQ6.uPBtL.tT.vECtT.tL.uPB
6.2B4.2C4.2B$pJuOKtLOtLpTuUKtVKtLpJuO6.pJBK.O.pTCK.K.pJB6.pJBK.O.pTCK
.K.pJB6.pJBK.O.pTCK.K.pJB$uPuQ4tL2uUtTtU2tLuPuQ6.uPuQ4tL2uUtTtU2tLuPuQ
6.uPBtL.tL.uUCtT.tL.uPB6.2B4.2C4.2B$pJuOKtLpXvGpXvGpXvGKtLpJuO6.pJBK.
pXCpXCpXCK.pJB6.pJBK.pXCpXCpXCK.pJB6.pJBK.pXCpXCpXCK.pJB$uPuQ2tLvEuUvE
uUvEvF2tLuPuQ6.uPuQ2tLvEuUvEuUvEvF2tLuPuQ6.uPBtL.vECvECvECtL.uPB6.2B
2.6C2.2B$pJuOKtLKtLKtLKtLKtLpJuO6.pJBK.K.K.K.K.pJB6.pJBK.K.K.K.K.pJB
6.pJBK.K.K.K.K.pJB$uPuQ10tLuPuQ6.uPuQ10tLuPuQ6.uPBtL.tL.tL.tL.tL.uPB
6.2B10.2B$pJuOpJuOpJuOpJuOpJuOpJuOpJuO6.pJBpJBpJBpJBpJBpJBpJB6.pJBpJB
pJBpJBpJBpJBpJB6.pJBpJBpJBpJBpJBpJBpJB$uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.
uPuQuPuQuPuQuPuQuPuQuPuQuPuQ6.uPBuPBuPBuPBuPBuPBuPB6.14B4$60.KtLKtLWtX
WtXWtXKtLKtL$60.4tL6tX4tL$60.KtLWtXKtLKtLKtLWtXKtL$60.2tL2tX6tL2tX2tL
$60.KtLWtXKtLKtLKtLWtXKtL$60.2tL2tX6tL2tX2tL$27.KtLKtLWtXWtXWtXWtXWtX
WtXKtLKtL13.KtLWtXKtLKtLKtLWtXKtL$27.4tL12tX4tL13.2tL2tX6tL2tX2tL$27.
KtLWtXWtXpTuXpTuXpWuUpWuUWtXWtXKtL13.KtLKtLWtXWtXWtXKtLKtL$27.2tL4tX
8uU4tX2tL13.tM3tL6tX4tL$6.KtLKtLpIuJNtPKtL11.WtXWtXKtOWtXWtXWtXWtXNtL
WtXWtX13.LtMKtLKtLWtXKtLKtLKtL$6.3tLtVuMuJ4tL11.4tXtLtO8tXtOtL4tX13.tL
3tM2tL2tX6tL$6.KtPKtLqEvGKtLNtL11.WtXKtOWtXWtXsVyAsVyAWtXWtXNtLWtX13.
VtWWtXWtXWtXWtXWtXVtW$6.4tLvAvBtOtV2tL11.2tXtLtO4tXxWxXxWxX4tXtOtL2tX
13.4tW6tX4tW$6.pIuJqEvGKtLqEvGpIuJ11.WtXKtLWtXsVyAsVyAsVyAsVyAWtXKtLW
tX13.KtLKtLKtLWtXKtLKtLLtM$6.2uJvAvB2tLvAvB2uJ11.2tX2tO2tXxW2xXyAxXyA
xWxX2tX2tO2tX13.6tL2tX2tL2tMtLtM$6.NtLKtLqEvGKtLKtP11.WtXKtLWtXsVyAsV
yAsVyAsVyAWtXKtLWtX13.KtLKtLKtLWtXKtLKtLKtL$6.2tLtOtVvAvB4tL11.2tX2tO
2tXxW2xXyAxXyAxWxX2tX2tO2tX13.6tL2tX4tLtMtL$6.KtLNtPpIuJKtLKtL11.WtXN
tLWtXWtXsVyAsVyAWtXWtXKtOWtX13.KtLKtLKtLWtXKtLKtLKtL$6.4tLuMuJtLtV2tL
11.2tXtOtL4tXxWxXxWxX4tXtLtO2tX13.6tL2tX6tL$27.WtXWtXNtLWtXWtXWtXWtXK
tOWtXWtX13.KtLKtLWtXKtLWtXKtLKtL$27.4tXtOtL8tXtLtO4tX13.4tL2tX2tL2tX
4tL$27.KtLWtXWtXpWuUpWuUpTuXpTuXWtXWtXKtL13.KtLWtXKtLKtLKtLWtXKtL$27.
2tL4tX8uU4tX2tL13.2tL2tW2tM2tL2tM2tW2tL$27.KtLKtLWtXWtXWtXWtXWtXWtXKtL
KtL13.VtWLtMKtLKtLKtLLtMVtW$27.4tL12tX4tL13.2tWtL2tM3tLtM2tLtM2tW!

This now seems far laggier than it previously was when icons were first implemented, but I'll need to check this on other devices as well.

I haven't timed this precisely, but when icons aren't shown, on iPad Safari, this reaches T 80 in ten seconds, while when icons are shown it only reaches T 40. This is despite the FPS counter not going into the red zone in either case (though the framerate is cut in half). I don't know.

However, on desktop, when icons aren't present, we reach T 110, yet when they are we reach T 200.

How can I provide more useful results for Icons rendering performance?

Speaking of performance, could any of the optimizations that specifically work when the board is at 0 degrees rotation also bee applied when the rotation is exactly 90, 180 or 270 degrees?

[confocaloid]

Mouse over a cell in the displayed pattern conveniently displays in the lower-left corner the coordinates and the current state of that cell of the pattern.

After doing Identify on an oscillator, on mouse over a cell in a map (either periods of cells or frequencies of cells), would it be possible to display the information about that cell of the map (its period and its frequency) in the lower-left corner?

Additionally, after closing the results of Identify and switching back to the displayed pattern, would it be possible to add the same information about cells in the lower-left corner? For example instead of only "5,20=2 (history)" show something like "5,20=2 (history), p742 cell frequency 10/1484". (This will likely need to be invalidated/discarded after any editing of the pattern.)

[muzik]

Is it intended that COLOR doesn't affect icons, even if they're single-color?

Code: Select all

x = 6, y = 6, rule = Pulse2
3CEDC$C4.C$C4.C$C4.C$C4.C$6C!
[[ COLOR "gate on" Blue ]]

Changing PCA colors does affect the icons, so I'd expect the same logic would apply for ruletables.

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
C!
[[ COLOR E White ]]

Also note how toggling icons seems to shift the positions of major grid lines.

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
C!
[[ GRID ]]

Select All and flip horizontally for two bugs:
- the pattern becomes more symmetric, which it is not supposed to do
- iterating this one more generation replaces two history cells with was-never-alive cells

Code: Select all

x = 3, y = 4, rule = R1,C3,S,B2
BA$.BA$.BA$BA!
[[ MAXGRIDSIZE 9 STARTFROM 252 X 255 ]]

Turning on State Number and mousing over the history trail shows 0 for all Generations History states, unlike what is shown for 2-state rules. Is this intended? I assume Generations handles history trails differently.

Code: Select all

x = 2, y = 4, rule = /2/2
o$bo$bo$o!
[[ STARTFROM 4 ]]

Code: Select all

x = 2, y = 4, rule = /2/3
o$bo$bo$o!
[[ STARTFROM 4 ]]

[muzik]

This spaceship is killed upon hitting the edge of the grid in the top pattern after periodicity is detected but before results are calculated, resulting in different population values from the bottom pattern.

Code: Select all

x = 124, y = 9, rule = B3aceiy4ekqrty5cijn6ck78/S2c3-y4cejkqt5i6cei7c8
b2o$2o$42bo$34b3o4b3o70b3o5bo$34b3o3b5o69b3o4b3o$34b3o4b3o70b3o5bo$42b
o$2o$b2o!
[[ MAXGRIDSIZE 9 AUTOIDENTIFY ]]

Code: Select all

x = 124, y = 9, rule = B3aceiy4ekqrty5cijn6ck78/S2c3-y4cejkqt5i6cei7c8
b2o$2o$42bo$34b3o4b3o70b3o5bo$34b3o3b5o69b3o4b3o$34b3o4b3o70b3o5bo$42b
o$2o$b2o!
[[ MAXGRIDSIZE 10 AUTOIDENTIFY ]]

Speaking of inaccurate Identify results, the following should be identified as Flip⟍ but is not.

Code: Select all

x = 4, y = 4, rule = R2,C2,S3,12,B4,13,NW01010100000108010000010100000000000000000000000000
2bo$3o$b3o$bo!

Why is icon data shown in Help > Info > Pattern? There's probably a good reason for this (possibly due to them being tied to rule definitions), but I'd expect these to be present in Help > Info > Cells instead.

[confocaloid]

[...] Speaking of inaccurate Identify results, the following should be identified as Flip⟍ but is not.

Code: Select all

x = 4, y = 4, rule = R2,C2,S3,12,B4,13,NW01010100000108010000010100000000000000000000000000
2bo$3o$b3o$bo!

[...]

With non-fully-symmetric custom or weighted neighbourhoods, I think it may be a simpler reasonable choice to not attempt to compute the mod at all. Note that an isotropic cellular automaton can be defined using a weighted neighbourhood that isn't fully-symmetric (for a simple example, R1,NW111105555 allows defining Conway's Life which is isotropic). Also, an evolutionary sequence existing in a non-isotropic cellular automaton can exist unchanged in some isotropic cellular automaton. There may be other reasonable ways to resolve these issues, but I think the simplest choice is to skip the mod computation.

[muzik]

Oscillators like these have reported volatility values of 1 in Identify. While I haven't manually checked every generation, I think this is incorrect as the central cores in this rulespace tend to be indestructible, and as such would be expected to be stator cells. The volatility may be arbitrarily close to 1, but in cases like these the volatility is displayed as "1.00" rather than "1".

Code: Select all

x = 25, y = 29, rule = R2,C0,M1,S10..19,B4..4,NM
3b3obo$2b5o$2b4o2bo$3b2ob2o$5bobo$4b4o$3b4o$2b3obobo$obob2o$2bobo$2bo3bo$ob5o
$ob5o$3b4o$4bo7$18b2o$17b4o$17b4o$18b3o$21b3o$21b4o$21b4o$22b2o!

The issue seems to only arise if the strict volatility would be impossible to calculate within memory constraints. Compare:

Code: Select all

x = 15, y = 11, rule = R2,C0,M1,S10..19,B4..4,NM
b4o$b4o2bo4b2o$6obo3b4o$2bob2o5b4o$3obo7b2o$4obo$3ob2o$2ob3o$2b4o$2b3o$bo!

Running the top pattern in LifeViewer Pro, which has enough memory to handle the full strict volatility processing, gives a value of 0.99 rather than 1, and the rocky cores indeed persist unchanged through all phases.

[rowett]

Oscillators like these have reported volatility values of 1 in Identify. While I haven't manually checked every generation, I think this is incorrect

Fixed in build 1260, thanks!

[muzik]

Is it possible to customize the colours of age states other than just using a single gradient?

For context, I'm trying to recreate the following gif in LifeViewer: https://commons.wikimedia.org/wiki/File:Oscillator.gif


The background colour and initial alive colour are straightforward enough:

Code: Select all

x = 20, y = 16, rule = B2/S34H
bo$o$2bo4$13bo3$13b2o$14bo$15b2o$9bo6bo2bo2$10bo$9bo!
[[ GPS 6 COLOR BACKGROUND 255 255 255 COLOR ALIVE 147 254 0 COLOR ALIVERAMP 147 254 0 COLOR DEAD 255 255 255 HISTORYSTATES 0 AGESTATES 0 SHADER Basic ]]

The gif, however, uses seven age states for living cells:
1 - 147 254 0
2 - 108 0 254
3 - 13 0 254
4 - 0 45 254
5 - 0 83 254
6 - 1 110 254
7 - 0 131 254

We can have the first one work with relative ease:

Code: Select all

x = 20, y = 16, rule = B2/S34H
bo$o$2bo4$13bo3$13b2o$14bo$15b2o$9bo6bo2bo2$10bo$9bo!
[[ GPS 6 COLOR BACKGROUND 255 255 255 COLOR ALIVE 147 254 0 COLOR ALIVERAMP 254 0 210 COLOR DEAD 255 255 255 HISTORYSTATES 0 AGESTATES 1 ]]

However, getting the six above it to work correctly is a problem. We can use the State Number toggle to see what each color state is. The following example highlights the four cells which survive for seven consecutive generations in white - we can see that they are state 70, progressing from state 64 continuously from the preceding generations if we step back and check.

Code: Select all

x = 20, y = 16, rule = B2/S34H
bo$o$2bo4$13bo3$13b2o$14bo$15b2o$9bo6bo2bo2$10bo$9bo!
[[ STARTFROM 66 AGESTATES 7 ]]

However, trying to customize these cell states accordingly so that they use these colours doesn't work at all and we get errors.

Code: Select all

x = 20, y = 16, rule = B2/S34H
bo$o$2bo4$13bo3$13b2o$14bo$15b2o$9bo6bo2bo2$10bo$9bo!
[[ GPS 6 COLOR BACKGROUND 255 255 255 COLOR ALIVE 147 254 0 COLOR 65 108 0 254 COLOR 66 13 0 254 COLOR 67 0 45 254 COLOR 68 0 83 254 COLOR 69 1 110 254 COLOR 70 0 131 254 COLOR DEAD 255 255 255 HISTORYSTATES 0 AGESTATES 7 ]]

Could some way to customize certain ages for living cells and dead cells beyond the generated gradients be added?

For comparison, this is already possible for dying states. If use of the "internal" state numbers is not desirable, perhaps a naming system could be implemented for cell ages instead to be more consistent with this.

Code: Select all

x = 7, y = 2, rule = /2/8
GFEDCBA$GFEDCBA!
[[ COLOR "alive" 147 254 0 COLOR "dying 1" 108 0 254 COLOR "dying 2" 13 0 254 COLOR "dying 3" 0 45 254 COLOR "dying 4" 0 83 254 COLOR "dying 5" 1 110 254 COLOR "dying 6" 0 131 254 ]]

[confocaloid]

edit 2: I crossposted this into the bugs thread: viewtopic.php?p=205562#p205562

Steps to reproduce (build 1260): (edit: the bugs remain in build 1261)

1. Click "Show in viewer".
2. Enter selection mode (F4), and select the "top half" of the pattern's generation 0 (select all alive cells that are above the horizontal line dividing the pattern in half).
3. Advance the selected region by 4 ticks (Ctrl+Space four times).
   The first bug: this step unexpectedly changes the current generation number from 0 to 4 (this is unlike in Golly, where advancing selection doesn't change the current generation number).
4. Run the changed pattern to generation 70.
5. Step back (Shift+Tab) one tick at a time.
   The second bug: when stepping back from generation 70 in this way, around generation 61 or 62, most of the lower half of the pattern unexpectedly disappears. Continuing to step back "to the beginning" fails to restore either the original pattern or the pattern obtained by advancing selection four ticks.

Code: Select all

x = 33, y = 31, rule = B3/S23
22bo$13b2o5b3o$14bo4bo$14bob2o2bo$15bo5bo$16bo3b2o$17bo2$10bo$2o3bo4b
2o$2o2b2o5b2o$5b2o4bo$6bo3bo6$22bo3bo$21bo4b2o$20b2o5b2o2b2o$21b2o4bo
3b2o$22bo2$15bo$11b2o3bo$11bo5bo$12bo2b2obo$13bo4bo$10b3o5b2o$10bo!

[rowett]

Is it possible to customize the colours of age states other than just using a single gradient?

It's possible in the engine but there's no way to specify the custom colours at the moment. The engine doesn't know anything about gradients - it's just given a palette of colours to use.

It will need a naming convention for the alive states that isn't the state numbers. Thoughts?