Pattern viewer for forum threads

[muzik]

I understand it is impolite to constantly reiterate... but the period map colour pull request has been open for one year as of today. Is there a possibility that it can be merged, or otherwise processed, some time soon?

[rowett]

... the period map colour pull request has been open for one year as of today. Is there a possibility that it can be merged, or otherwise processed, some time soon?

Delighted to celebrate the 1 year anniversary.

Please check that the auto-generated colours don't duplicate (or are very close to) any of the predefined colours.

[muzik]

Please check that the auto-generated colours don't duplicate (or are very close to) any of the predefined colours.

The test case is here.

For arrangements with very high numbers of state counts, such as the following (p175 and p4), we may get close matches, however I imagine the actual impact of these is minimal as dealing anything beyond 20 distinct periods is going to be a rare occurrence anyway (and in cases where this does happen they should be distinguishable by other means).

Code: Select all

x = 254, y = 229, rule = B3/S23
184b2o9b2o48b2o$183bo2bo9bo48bo$184b3o9bobo44bobo$183bo3bo9b2o9b2o22b
3o8b2o$182bob4o18b2o2bo19bo3b2o$169b2o11bobob2o18bo2b3o2b2o10b2o2bobo
2b2o$170bo12bobobobo16bo4bo2b2o10b2obo5bo$170bobo12b2obobo16b5o18b5o$
171b2o3bo8b4obo$177b2o6bo3bo17b5o18b5o$177b2o7b3o17bo4bo2b2o10b2obo5bo
$166b2o5bo3bo3bo4bo2bo16bo2b3o2b2o10b2o2bobo2b2o$171bobo3bo3b3o3b2o17b
2o2bo19bo3b2o$165bo3bo6b2o3b3o13b2o9b2o22b3o8b2o$164bo4bo6b2o4b3o11bob
o44bobo$163bobobo5b3o4b2o14bo48bo$79b2o81bobobo7b3o3b2o13b2o48b2o$80bo
75b2o2bo4bo8b3o3bo3bobo$80bobo73b2o2bo3bo11bo3bo3bo$81b2o3bobo81bo2bo
5b2o36b2o6b2o$85bo3bo62bo9b2o6bo8b2o35bo2bo4bo2bo$85bo65bobo15bo4bo6bo
3b2o29bo2bo4bo2bo$84bo67bo15bobo2b2o10bobo28bo2bo4bo2bo$62b2o20b3o69b
3obo5b2obo17bo29b2o6b2o$62b2o23bo67bob2ob2o25b3o7b2o$53b2o14bo7bo6bo2b
o2b3o62bo5b2o27bo6bo$53b2o13b2o6bobo6b3o2bo2bo61b2o5bo3bo2bo19b2o4bobo
15b2o16b2o$46b2o14b2o3bob2o6bo12bo44b3o2bo15b2ob2obo5b2o25b2o17bo16bo$
46bobo4bo6b2obo2b3o2bo19b3o42b2obo17bob3o29b3o12b2o6bob2o10b2obo$47bo
4bobo5b3o5bobobo20bo42b3o4bo21bo25b3o11bo2bo6bo3bo6bo3bo$51bo3bo13bobo
bo5b3o10bo39bo3bobo25bobo38bobobo10bo4bo$51bo3bo14bo2b3o2bob2o6bo3bo
25b2o5b2o5b4o2bo6bo19bo3bo18b2o16bo2bo6bo3bo4bo3bo$51bo3bo8bo6b2obo3b
2o9bobo3b2o21b2o5b2o5b3o33bobo16bobo4b2o14bo9bo4bo$52bobo3b2o3bobo6b2o
21bobo20b2o5b2o7b3o2bo20b2o6bobo16bo6bo12bobo5bo3bo6bo3bo$53bo4bobo3bo
7bo24bo20bo7bo6bo4bobo3b2o14b2o4b3o2b2o13b2o7b3o16bob2o10b2obo$60bo17b
2o17b3o16b2ob2o3b2ob2o3bo6bo2b2o21b2o2bobo8bo16bo16bo16bo$60b2o16b2o
20bo15b2ob2o3b2ob2o35bobob2o2bo6bobo15bob2o10b2obo16b2o$47b2o50b2o15b
2o2bo3bo2b2o11bo21b3obo3b2o3bo13b2o7bo3bo6bo3bo38b2o$48bo40bo27b2obo3b
ob2o6bo5bo13b2o5bo4bob2o5bo2bo2bo4b2o2bo12bo4bo26bobo2b2o6b3o2bo$48bob
o4bo33b3o10b2o14b2o5b2o12bo14bobo4b2o3b2obo4bob2o7b2ob2o9bo3bo4bo3bo
21bo2bo2bobo8b2o$49b2o3bobo35bo8bobo15bo5bo10bo2bo16bo2b2o17b2o5b2o16b
o4bo9b2o15b2obo3bo4bo$53bo3bo33b2o8b2o29b2o13b2o6b2obobo14b2o2bo5b2o
11bo3bo6bo3bo4b2o19b2ob2o3bo$53bo3bo72bo2bo13b2o9bo16b2o3b2o3b2ob2o7bo
b2o10b2obo24b2o2bo7b2o$53bo3bo96b5o2bo15bo8b2o2bo6bo16bo10b5o5b3o3b3o
4b3o2bo$54bobo4bo46b3o7b2o5b2o28bo3b3o17b3o7b2o5b2o16b2o9bo9bo2b2o12b
2o$55bo4bobo55b2o5b2o3b2obo20b2ob2o67bo2bo5b2ob2o$61b2o55b2o5b2o5bobo
2b2o14bo5bo67b2o7bo3bob2o$54b2o62bo7bo6bo4bo14b6o47b2o16b2o10bobo2bo2b
o$54b2o44b2ob2o11b2ob2o3b2ob2o5bo63bo6bobo3b2o10bo2bo10b2o2bobo$96b3ob
o3bo11b2ob2o3b2ob2o5bo2bo17b2o22b3o16b2o4bo2bo3b2o14bo$95bo3bob3o12b2o
2bo3bo2b2o26b2o12bo12bo4b3o12bo3bo16b5o$95b2ob2o17b2obo3bob2o41b2o7bo
3bo3bo3bo11bobo$118b2o5b2o20b3o27bobo2bo2bo5bo41b2o$119bo5bo20bo3bo14b
obo2b3o2bo2bobo21bobo28b2o$145bo5bo13b4obo4bo3bo4bo7bo9bo3bo$89b3o54bo
3bo14b2o8bo8bo7bo5b2o4bo2bo3b2o$147b3o26b3o19bo6bobo3b2o$118b2o5b2o20b
3o35bo5bo14b2o$97b2o8b2o9b2o5b2o59bo3bo29b2o15b2o$96bobo8bo10b2o5b2o
60b3o30b2o15b2o$96b2o10b3o7bo7bo48b2o$110bo5b2ob2o3b2ob2o18b2o25bo2bo$
99b2o15b2ob2o3b2ob2o18b2o25bobobo$99bo16b2o2bo3bo2b2o46bob3o53b2o$100b
3o14b2obo3bob2o8b2o39b3o15bo2b2o4b2o2bo24bobo$102bo15b2o5b2o5b3o2bo56b
o3b3o2b3o3bo18b3o$73bo45bo5bo9b2o58bo2b2o4b2o2bo18bo3bo$74b2o34b2o19bo
42b2o50b2o3b2o$72b2o34bob2o19bo40bo4bo49bo$74bo4b2o26bo27b2o34bo6bo22b
2o25b5o$78bo2bo28bo7b2o5b2o5b3o2bo32bo8bo3b3o43bo$77bo2bo25b2obo8b2o5b
2o9b2o32bo8bo5bo17bo5bo$76bo29b2o10b2o5b2o43bo8bo4bo18bo5bo3bo$76bo41b
o7bo44bo6bo22b4o3b4o17bo$76b3o37b2ob2o3b2ob2o43bo4bo22b2o9b2o13b5o$
116b2ob2o3b2ob2o45b2o23b3o2b2ob2o2b3o17bo$bo2b2o4b2o2bo101b2o2bo3bo2b
2o70b2o3b2ob2o3b2o12b2o3b2o$o3b3o2b3o3bo101b2obo3bob2o42bo2bo26b3obo3b
ob3o14bo3bo$bo2b2o4b2o2bo50b2o36b2o13b2o5b2o47bo26b2o7b2o16b3o$18bobo
44bo2bob2o31bobo13bo5bo7b2o34bo5bo26b3o3b3o12bobo$19b2o45b3obobo32bo
26bo2bo33b2o4bo28b2ob2o15b2o$19bo50bobo32b2o24bobobo38bo28bobobobo$68b
2obo10b2o47bo2bo38bo21b2o7bo3bo$67bobobobo9bo34b2o5b2o3bo41b4obo17b2o$
68bo3b2o6b3o35b2o5b2o4bobo38bo3bo43b2o15b2o$80bo89bo3bo21bo23b2o15b2o$
134b2o33bob4o20bobo$132bo4bo35bo16b2o2bo2bo4b3o3b3o$131bo6bo33bo17b2ob
o8b2obobob2o$130bo8bo3b3o25bo4b2o16b2o9bobo$130bo8bo5bo25bo5bo$130bo8b
o4bo27bo31b2ob2o$131bo6bo34bo2bo6bo4bo$132bo4bo43b3o3bob2o$134b2o44bo
6bobo5b2o$180b2o6bobo3bobo$193b3o$174bob2o15b2o$173bo2bob2o14bobo$173b
o2bo3bo14bobo2b2o$173b3o20bo2bobo$168bo11bo16b4o$167bo11bo18b2o$172b3o
$167bo3bo2bo$168b2obo2bo$170b2obo$149bo$149b3o14b2o$152bo14bo$151b2o
11b3o$164bo$162bobo$162b2o2$186b3o$177b3o6b3o$177bo2bo6bo$176bo3bo6bo$
95bo80bobob2o5bo$94bo63bobo16b2ob2o4bobo$94b3o60bo2bo11b2o4b3o$139b2o
16bo2bo11b2o$136b2ob2o17bo19b3o5bobo$135bo41b2ob2o5bo$71bo2b2o4b2o2bo
54b2o12bo22bobob2o5bo$70bo3b3o2b3o3bo54bo10bo2bo21bo3bo6bo$71bo2b2o4b
2o2bo49b2o3bo2bo8bo2bo22bo2bo5b3o$134b5o3bo8bobo23b3o6b3o$142bo$182bo$
181bobo$90b3o25b2o4b2o56b2o$89bo3bo24b2o3b3o$88bo5bo23b2o2bo3bo$118b3o
3b4obo18b2o$87bo7bo22bo10bo17bobo$87bo7bo22bob4o3b3o17bo$121bo3bo2b2o
15b3o11b2o$88bo5bo27b3o3b2o14bo14bo$89bo3bo28b2o4b2o14b2o14b3o$90b3o
69bo$134b3o$69b2o64bo$69b2o71bo$141b3o$75bo2bob2obo2bo$69b2o4b4ob2ob4o
45b2o$69b2o4bo2bob2obo2bo46bo$130b3o$64b2o64bo$64b2o4$65bo$64bobo8bo$
65bo10bo$74b3o43$129bo$128bobo$129bo4$129b2o$129b2o19b2o$150bobo7b8o$
108bo2bob2obo2bo4b2o24bo9bob4obo$108b4ob2ob4o4b2o34b8o$108bo2bob2obo2b
o$153bo$124b2o26bobo$124b2o2$152b3o$152b3o$153bo3$153bo$152b3o$152b3o
3$152bobo$153bo!
[[ AUTOIDENTIFY SHADER Basic ZOOM 1 ]]

The closest I could get was p6 versus p18 in the following reduction of the above pattern:

Code: Select all

x = 66, y = 98, rule = B3/S23
18b2o$19bo$19bobo$20b2o2bo2bo$24bo2bo$23bo4bo$24bo$24bob2o$14b3o$14b3o
$14b3o$11b3o$5b2o4b3o14b2obo$5b2o4b3o17bo$27bo4bo$bo16b2o8bo2bo$obo15b
2o2b2o4bo2bo2b2o$bo4bo9b2obo2b2o10bobo$5bobob2o5b3o17bo$4bo2bobobo24b
3o7b2o$3b2obo2bobo27bo6bo$4bobo2bob2o4b2o19b2o4bobo$4bobobo2bo5b2o25b
2o$5b2obobo30bo13b2o$9bo4bo25bobo11bo2bo$13bobo23b2obo11bobo$14bo22b3o
b3o11bob2o$36bobo4b2o11b3o$9b2o25bo6bo13b2o5b2o$9b2o24b2o7b3o16bobo$29b
o16bo16bo$29bo16bobo12bobo$27b3o5bo2b2o7b2o12b2o$23b2ob2o7b2o2bo11b8o
$23b2obobo5b5o12bob4obo$23b3o2b2o21b8o$28b3o16b2o12b2o$24b2o3b2o3b5o7b
obo12bobo$30bo4b2o2bo6bo16bo$28b2o5bo2b2o5b2o16b2o3$55b2o$37bo9b2o5bo
b2o2b2o$29bo6b3o8b2o5bobo3b2o$54bo$27b3obo20bo$26bob2o6b3o$26b2obo22b
o$24bob3o7bobo15bo$36bobo8b2o5bobo3b2o$26bo20b2o5bob2o2b2o$36b3o16b2o
3$24b2o10b3o$23bo2bo10bo$23bobobo$24bo2bo19bo6bo$28bo17b2o6b2o$25bobo
17b3o6b3o$46b2o6b2o$47bo6bo$34b2o$35b2o$18bo2bob2obo2bo4bo$17b2o2bo4b
o2b2o$18bo2bob2obo2bo$53bo3bo$52bobobobo$53b2ob2o2$50bo9bo$49bobo7bob
o$49bo3b2ob2o3bo$50bo3bobo3bo$51b2obobob2o$44b2o7bo3bo$44b2o$44b2o$45b
o$44bobo5bo5bo$39b3obobo5bobo3bobo$39b4obo6bo2bobo2bo$43bo9bo3bo$53b2o
b2o3$36b2ob2o$36b2ob2o3b2o$42bo2bo3$42b2obo$44bobo2b2o$45bo4bo$46bo$46b
o2bo!
[[ AUTOIDENTIFY SHADER Basic ZOOM 4 ]]

However even in this case I would say the proposed system is much better since the current auto-generated system assigns most of the common periods to slightly different shades of green, which are hard to tell apart from each other especially when cross-referencing with the key.

Should anything further be done with respect to this pull request?

Actually LifeViewer will update the cell grid at the playback speed (1x = 60 generations per second, 2x = 120 generations per second and so on). It will render at the monitors refresh rate.

This matches what I see, but (unless I'm reading it wrongly) the changelog indicates that the cell grid is updated at the refresh rate, rather than rendering being updated at the refresh rate and the cell grid being updated 60n times per second for playback speed n.

[rowett]

Should anything further be done with respect to this pull request?

No, it's deployed in build 1371.

[muzik]

I did some more messing with the following premature boundary kill bug a while ago:

Code: Select all

x = 1, y = 1, rule = R1,C2,S1,B1,NN
o!
[[ AUTOSTART ZOOM 1 MAXGRIDSIZE 9 ]]

Apparently, for Generations rules in Pro specifically, cells with negative states can manifest?

Code: Select all

x = 1, y = 1, rule = R1,C3,S1,B1,NN
o!
[[ AUTOSTART STOP 509 ZOOM 1 MAXGRIDSIZE 9 ]]

IMG_5321.jpeg (461.02 KiB) Viewed 1753 times

[unname4798]

LifeViewer can support up to 65536 (or 512) states, apparently.

...
Apparently, for Generations rules in Pro specifically, cells with negative states can manifest?

Code: Select all

x = 1, y = 1, rule = R1,C3,S1,B1,NN
o!
[[ AUTOSTART STOP 509 ZOOM 1 MAXGRIDSIZE 9 ]]

IMG_5321.jpeg

This pattern crashes LifeViewer Pro at T 191:

Code: Select all

x = 1, y = 1, rule = R4,C2,S,B1,NN
o!
[[ AUTOSTART ZOOM 1 STOP 190 MAXGRIDSIZE 9 ]]

And this crashes standard at T 24:

Code: Select all

x = 1, y = 1, rule = R7,C2,S,B1,NN
o!
[[ AUTOSTART ZOOM 1 STOP 23 MAXGRIDSIZE 9 ]]

[rowett]

I did some more messing with the following premature boundary kill bug a while ago

Apparently, for Generations rules in Pro specifically, cells with negative states can manifest?

This pattern crashes LifeViewer Pro at T 191

And this crashes standard at T 24

Fixed in build 1372.

[muzik]

In build 1372 there still appear to be cases where cells are killed even though they should not be - compare how this looks when it automatically stops to when you step back and then forward again from that point:

Code: Select all

x = 1, y = 1, rule = R7,C2,S,B1,NN
o!
[[ AUTOSTART ZOOM 1 STOP 18 MAXGRIDSIZE 9 ]]

Golly correctly rejects this rulestring, but LifeViewer instead converts it to something valid but ultimately different and runs with it:

Code: Select all

x = 4, y = 4, rule = R1,C2,S9,1,B9,1,NN
b2o$o2bo$o2bo$b2o!
[[ SHOWGENSTATS ]]

Despite AutoFit being active, pressing the reset button will keep the camera focused at the prior position rather than changing it to fit where alive cells are following this action (pressing it again shows the expected behaviour, as does turning autofit off and on again):

Code: Select all

x = 3, y = 506, rule = R1,C2,S2-3,B3
o$obo$2o501$2o$obo$o!
[[ MAXGRIDSIZE 9 STARTFROM 1024 AUTOFIT ]]

Interestingly, this exact pattern doesn't run in the [R]Standard algorithm even though it has (to my understanding) less restrictive boundary requirements.

Code: Select all

x = 3, y = 506, rule = B3/S23
o$obo$2o501$2o$obo$o!
[[ MAXGRIDSIZE 9 STARTFROM 1024 AUTOFIT ]]

If you Select All and try to move the pattern left or right, it says there's no room to do so even though there is.

Code: Select all

x = 1, y = 8186, rule = R1,C2,S2-3,B3
o8185$o!

Code: Select all

x = 1, y = 506, rule = R1,C2,S2-3,B3
o505$o!
[[ MAXGRIDSIZE 9 ]]

This old issue which previously only affected the top and left boundaries now also appears to happen on the bottom and right as well as of build 1372:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 X 255 PASTE o$o$o$o$o$o! 252 -6 AUTOSTART LOOP 500 THEME Book THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 Y 255 PASTE 6o! -6 252 AUTOSTART LOOP 500 THEME Book THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

The period/frequency map includes extra gray cells at the bottom left and top right that are not actually there in the pattern:

Code: Select all

x = 1, y = 1, rule = B1/SH:P2,1
o!
[[ AUTOIDENTIFY ]]

[muzik]

Help > Info > Cells is wrong here: despite the DEADRAMP colour being used in practice, it instead lists the DEAD colour in that section. Help > Themes also lists both DEAD and DEADRAMP despite only the latter being used.

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ HISTORYSTATES 1 STARTFROM 32 ZOOM 16 ]]

Another similar thing: for this pattern, there are two distinct "alive" states (one "just became alive", one "was alive before") and two distinct "dead" states (one "just became dead", one "was dead before"). However, the script commands used to achieve this outcome, alongside the displayed values in Help > Themes and Help > Info > Theme, differ. Should the AGESTATES command be changed such that 2 needs to be specified for this outcome (and AGESTATES 0 becomes invalid, like how HISTORYSTATES 0 is in [R]History)? Or is it this way for a reason?

Code: Select all

x = 13, y = 13, rule = B3/S23
2b3o3b3o2$o4bobo4bo$o4bobo4bo$o4bobo4bo$2b3o3b3o2$2b3o3b3o$o4bobo4bo$
o4bobo4bo$o4bobo4bo2$2b3o3b3o!
[[ AGESTATES 1 HISTORYSTATES 2 AUTOSTART GPS 4 ]]

Here is a comparison of three rotationally equivalent patterns - note the different degrees of visual intersection of alive cells:

Code: Select all

# intersection minimal - one screen pixel in width?
x = 4, y = 3, rule = B1/SHHistory
3F$F.AF$.3F!
[[ THEME Blues ZOOM 64 AUTOSTART GRID OFF ]]

Code: Select all

# intersection thicker
x = 4, y = 4, rule = B1/SHHistory
2F$FAF$.F.F$2.2F!
[[ THEME Blues ZOOM 64 AUTOSTART GRID OFF ]]

Code: Select all

# intersection thicker
x = 3, y = 4, rule = B1/SHHistory
2F$F.F$FAF$.2F!
[[ THEME Blues ZOOM 64 AUTOSTART GRID OFF ]]

Finally, to more closely match Golly's user interface, would it be possible to show cell icons in the Draw menu if they exist, even if icons aren't currently switched on?

Code: Select all

x = 1, y = 1, rule = sphere
o!
@RULE sphere

Override the default colors and icons for Life (B3/S23).

@TABLE
n_states:2
neighborhood:Moore
symmetries:none
# do nothing

@COLORS

0 255 255 255   white (matches icon background below)
1 54 54 194     dark blue (average color of icon below)

@ICONS

XPM
/* width height num_colors chars_per_pixel */
"31 31 78 2"
/* colors */
".. c #FFFFFF"   white background
"BA c #CECEDE"
"CA c #7B7BAD"
"DA c #4A4A84"
"EA c #18187B"
"FA c #08006B"
"GA c #18186B"
"HA c #29297B"
"IA c #6B6BAD"
"JA c #ADADDE"
"KA c #EFF7FF"
"LA c #ADADC6"
"MA c #39398C"
"NA c #3939BD"
"OA c #7B7BCE"
"PA c #ADB5DE"
"AB c #8C8CD6"
"BB c #4A4A9C"
"CB c #18188C"
"DB c #EFEFEF"
"EB c #EFEFFF"
"FB c #525A9C"
"GB c #08088C"
"HB c #ADADE7"
"IB c #DEDEEF"
"JB c #D6D6F7"
"KB c #DEE7F7"
"LB c #BDBDEF"
"MB c #525ABD"
"NB c #21219C"
"OB c #292984"
"PB c #CECEE7"
"AC c #ADB5CE"
"BC c #2929BD"
"CC c #7B7BDE"
"DC c #BDC6E7"
"EC c #CECEF7"
"FC c #8C8CE7"
"GC c #4242C6"
"HC c #A5A5BD"
"IC c #08087B"
"JC c #3939CE"
"KC c #5A5AC6"
"LC c #BDBDF7"
"MC c #BDBDDE"
"NC c #6B6BD6"
"OC c #9494DE"
"PC c #3931DE"
"AD c #1818AD"
"BD c #2929CE"
"CD c #9C9CC6"
"DD c #10087B"
"ED c #9C9CBD"
"FD c #1818B5"
"GD c #1818C6"
"HD c #847BCE"
"ID c #181094"
"JD c #6B6BCE"
"KD c #7B7BB5"
"LD c #2121AD"
"MD c #BDC6D6"
"ND c #0808AD"
"OD c #4A42B5"
"PD c #00009C"
"AE c #3942BD"
"BE c #3129B5"
"CE c #B5B5CE"
"DE c #0000BD"
"EE c #0000CE"
"FE c #0000DE"
"GE c #42427B"
"HE c #C6CECE"
"IE c #0000EF"
"JE c #9494AD"
"KE c #F7FFEF"
"LE c #10086B"
"ME c #7B849C"
"NE c #0000F7"
/* icon for state 1 */
".............................................................."
".............................................................."
"......................BACADAEAFAGAHAIAJA......................"
"................KALAMAFANAOAJAPAJAABBBCBEAIADB................"
"..............EBFBGBNAHBIBDBJBKAKBEBJBLBMBNBOBPB.............."
"............ACHABCCCDCECIBPBJBPBIBPBJBIBECFCGCCBCAKA.........."
"..........HCICJCKCLBLCLBMCLBLBLBLBMCLBLBMCLCNCJCCBCAKA........"
"........DBOBBCJCCCJAJAJAJAJAJAJAJAJAJAJAJAJAOCJCPCICAC........"
"......KADAADBDBCABABOCABOCOCOCOCABOCABOCABCDFCJCBDBCDDBA......"
"......EDGBFDGDADCCABOAOAOAOAOAOAOAOAHDOAHDCCCCNAADGDIDMA......"
"....KAHAADFDFDADJDMBOAJDJDJDJDJDKDJDJDJDJDJDJDLDFDFDFDICBA...."
"....MDFANDNDNDADODMBMBMBMBMBMBMBKCKCMBMBMBMBODADNDNDNDGBIA...."
"....CAGBNDPDNDPDADGCODODODODODODNAODODGCODAEBCPDNDPDNDPDGA...."
"....OBPDPDNDPDNDNDADBCBEBCBEBCBCBEBCBCBCNAADPDNDNDPDPDNDICPB.."
"....ICNDNDPDNDNDNDPDNDADADADADADADADADADNDNDNDNDNDNDNDPDGBCE.."
"....FANDNDDENDNDNDDENDDENDNDNDNDNDNDNDNDNDNDNDNDNDNDNDNDGBLA.."
"....FANDDENDDEDENDDEDENDDENDDEDEDEDEDEDEDEDEDEDEDENDDEDEGBED.."
"....GANDEEDEDEDEDEDEDEDEDEDEDEDENDDENDDEDEDEDEDEDEDEDEDEGBLA.."
"....BBPDEEDEEEDEEEDEEEDEEEDEDEDEEEDEEEDEDEDEDEDEEEDEEEDEFABA.."
"....EDGBDEEEDEEEEEEEDEEEDEEEEEEEEEEEEEEEEEEEEEEEEEDEEENDGADB.."
"....KBICDEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEGBDA...."
"......FBNDFEFEEEEEEEEEFEEEEEFEEEEEEEEEEEEEEEEEEEEEFEDEICHC...."
"......IBEADEFEFEEEFEFEFEFEFEEEFEFEFEFEFEFEFEFEFEFEDEGBGEDB...."
"........LAGBFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFEFENDGAHE......"
"..........FBNDFEFEIEFEFEIEIEIEFEIEFEFEIEFEFEFEFEEEDDJEKE......"
"..........EBFBIDEEIEIEIEFEFEFEIEFEIEIEIEIEIEIENDLEMEKE........"
"..............CDGBDEIEIENENEIEIEIEIEIEIEIEGDPDGAJEKE.........."
"................BAOBGBADFEIENEIENEIEIEEENDFAGECEKE............"
"....................CDBBDDPDIDNDADPDICEAGEJEDB................"
"........................EBBALAEDEDHCMCDBKE...................."
".............................................................."

[rowett]

In build 1372 there still appear to be cases where cells are killed even though they should not be - compare how this looks when it automatically stops to when you step back and then forward again from that point:

I can't reproduce this.

Golly correctly rejects this rulestring, but LifeViewer instead converts it to something valid but ultimately different and runs with it:

Fixed in build 1373.

Despite AutoFit being active, pressing the reset button will keep the camera focused at the prior position rather than changing it to fit where alive cells are following this action (pressing it again shows the expected behaviour, as does turning autofit off and on again)

This is expected. The first reset is a soft reset and doesn't move the camera.

Interestingly, this exact pattern doesn't run in the [R]Standard algorithm even though it has (to my understanding) less restrictive boundary requirements.

If you Select All and try to move the pattern left or right, it says there's no room to do so even though there is.

This old issue which previously only affected the top and left boundaries now also appears to happen on the bottom and right as well as of build 1372

I'm not going to change these boundary cases.

The period/frequency map includes extra gray cells at the bottom left and top right that are not actually there in the pattern:

Fixed in build 1374.

[muzik]

Some embeds now have text intersection going on with the new menu: https://catagolue.hatsya.com/object/xp1 ... 7777/b3s23

embedintersect.png (165.61 KiB) Viewed 1651 times

There is also unwanted intersection in the Help menu in some cases (scale, pixel ratio, window zoom all 1.00):

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ POPUPHEIGHT 400 LABEL 0 0 32 "click Help, top right" ]]

In build 1372 there still appear to be cases where cells are killed even though they should not be - compare how this looks when it automatically stops to when you step back and then forward again from that point:

I can't reproduce this.

If you press Play after it pauses, the explosion will only expand from the left and right, since the top and bottom tips disappeared even though they're not close enough to the top and bottom boundaries for this to happen normally. If you step back then forward one generation and then press Play it continues in all four directions as expected.

[rowett]

Some embeds now have text intersection going on with the new menu

Fixed in build 1375.

[wirehead]

Some embeds now have text intersection going on with the new menu

Fixed in build 1375.

It's still not fixed (with the current popup on the forums here).

Macbook Pro, Safari 26.2 (window.devicePixelRatio == 2)

Screenshot 2026-02-28 at 5.25.13 PM.png (253.27 KiB) Viewed 1613 times

[muzik]

For embedded thumbnails before rendering speed settings are registered, can it be made more clear that action has to be taken than just graying things out, or perhaps still have things animate but at a slower speed and only prompt upon expansion? Having everything be disabled at first and darkened takes away from embeds such as this in the first place which are intended to clearly show patterns first.

https://web.archive.org/web/20260301090 ... eriod_maps

[muzik]

In build 1372 there still appear to be cases where cells are killed even though they should not be - compare how this looks when it automatically stops to when you step back and then forward again from that point:

I can't reproduce this.

Perhaps this is clearer:

Code: Select all

x = 1, y = 1, rule = R7,C2,S,B1,NN
o!
[[ AUTOSTART ZOOM 1 STOP 23 MAXGRIDSIZE 9 ]]

The top and bottom cells should not be killed but are. Resetting to T=0 and playing will result in the intended behavior of those cells not dying.

[muzik]

Open the cell map for this and switch between period and frequency modes. There appears to be a pixel at the bottom right of the grid which is absent in period mode but correctly present in frequency mode.

Code: Select all

x = 1, y = 1, rule = B3/S23Investigator
J!
[[ AUTOIDENTIFY ]]

[rowett]

Open the cell map for this and switch between period and frequency modes. There appears to be a pixel at the bottom right of the grid which is absent in period mode but correctly present in frequency mode.

Fixed in build 1377.

[rowett]

Perhaps this is clearer

Fixed in build 1378.

[rowett]

... would it be possible to show cell icons in the Draw menu if they exist, even if icons aren't currently switched on?

Yes, added in build 1379.

[muzik]

Help options appear to be unnaturally clustered at the very top of the popup window (scale 1.11, pixel ratio 2.00, window zoom 1.00). Could they be spread out more than this across the vertical axis?

IMG_5786.jpeg (332.39 KiB) Viewed 1428 times

[muzik]

Is it intended that the code boxes in this post are unopenable and result in an error?

[muzik]

When HISTORYSTATES is set to 0 and cells die through normal evolution, no high layered cells are created in either the range-1 or general-range algorithms, which is correct. However, for cells killed by the outer boundary the story is different: the range-1 algorithm correctly produces no such cells, but the general-range algorithm incorrectly does. Note how the grid lines are obscured in the second pattern after it dies.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ MAXGRIDSIZE 9 PASTE o$o$o$o$o$o$o$o! -253 0 HISTORYSTATES 0 LAYERS 10 GRID THEME Caterer AUTOSTART GPS 2 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ MAXGRIDSIZE 9 PASTE o$o$o$o$o$o$o$o! -252 0 HISTORYSTATES 0 LAYERS 10 GRID THEME Caterer AUTOSTART GPS 2 ]]

Also unexpected: with the way this theme is set up, any cell that has been dead for two or more generations should look identical to the background. Pay attention to the leftmost cell, however, which stays red for two generations straight for some reason.

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,2,4,B1,3,NN
!
[[ MAXGRIDSIZE 9 PASTE 2o! -251 0 HISTORYSTATES 2 COLOR DEAD Red COLOR DEADRAMP Black SHOWGENSTATS GPS 1 AUTOSTART STOP 5 ]]

These two patterns run in LifeViewer, but are rejected by Golly. Is this expected behaviour? Or is one of the two programs doing something wrong?

Code: Select all

x = 7, y = 7, rule = B0/SSuper
7R$V5.R$V5.T$V2.A2.T$V5.T$V5.T$3V4T!

Code: Select all

x = 26, y = 26, rule = B026/S1Investigator
24.E$25.E14$7.A.A$10.A$7.A$8.A.A6$E$.E!

Unlike when I posted them last week, neither of these two patterns appear to paste any living cells anymore:

This old issue which previously only affected the top and left boundaries now also appears to happen on the bottom and right as well as of build 1372:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 X 255 PASTE o$o$o$o$o$o! 252 -6 AUTOSTART LOOP 500 THEME Book THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 Y 255 PASTE 6o! -6 252 AUTOSTART LOOP 500 THEME Book THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

The only difference between these patterns is the HISTORYSTATES setting, yet the evolution when set to 1 or 2 is different from all other values, which I think is incorrect and unexpected. HISTORYSTATES should only have a bearing on visual/cosmetic cells. Only the Standard engine appears to be affected by this issue - Pro does not.

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 THEME Book GRID OFF HISTORYSTATES 0 ]]

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 THEME Book GRID OFF HISTORYSTATES 1 ]]

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 THEME Book GRID OFF HISTORYSTATES 2 ]]

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 THEME Book GRID OFF HISTORYSTATES 3 ]]

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 THEME Book GRID OFF ]]

Put the mouse cursor on one of the two highlighted cells and they'll be shown as [bounded] 0 rather than [buundary] like the others:

Code: Select all

x = 1, y = 1, rule = B123/SHT:P2,2
o!
[[ GRID ARROW -4 1 -2.5 1 32 ARROW 3 -2 1.5 -2 32 ]]

Can stuff outside of the bounded grid be displayed as [background] instead, since it gets its colour from COLOR BACKGROUND, not COLOR BOUNDARY? This matches up better with true [bounded] cells being based on COLOR BOUNDED.

The default horizontal position is different for these two despite only tweaking one number in the rule:

Code: Select all

x = 1, y = 1, rule = /123/192HT:P2,2
A!
[[ GRID ]]

Code: Select all

x = 1, y = 1, rule = /123/193HT:P2,2
A!
[[ GRID ]]

Not finding many issues with Pro any longer (besides the unwanted history trail from a year ago). I imagine it's probably near enough to launch?

I've updated the "known bugs" page on the wiki to hopefully cover everything remaining from the last six months or so. I particularly want to see the "hexagonal grid is rendered at the same time as the offset square grid at 4x zoom" issue fixed since it looks horrid and makes its presence very known when working with hexagonal rules, especially when we consider that there have been many other improvements to hexagonal rendering and manipulation recently (oscillator map improvements, continuous lines when drawing fast, annotation coordinates, etc.).

[rowett]

Is it intended that the code boxes in this post are unopenable and result in an error?

Yes since they both have illegal RLE headers:

Code: Select all

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

RLE headers must have a space or = after x.

The parser is assuming the x is a pattern state and then correctly complaining about the comma.

[muzik]

If this is the first thing you open when loading this page and then you go to the Draw menu, the icons may be absent or use the wrong colour:

Code: Select all

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

Bounding boxes are also calculated incorrectly when saving PCA patterns. Load this and see that it fits in a 3x3 box as specified, but saving the pattern will cause the RLE to incorrectly expand to 5x5 as though the history cells are also counted:

Code: Select all

x = 3, y = 3, rule = 2PCA4,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
.D$B.H$.A!
[[ STARTFROM 2 ]]

Another example of boundary killing acting incorrectly I previously noticed, now with a test case. Load this pattern, and then select the highlighted region and clear all cells outside of the selection. The resulting block will behave as a p6 oscillator for 7 period cycles, but will then act explosively starting from generation 454. This is obviously unexpected behaviour - either the explosive behaviour should have started the first time playback was initiated, or it should remain a p6 oscillator for all eternity. For a non-alternating rule, the value of T should never affect the manner in which a pattern evolves, so there is clearly something incorrect happening.

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,2,4,B1,3,NN
2o$2o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 STARTFROM 406 X -246 Y 14 ZOOM 16 COLOR POLY Red POLYLINE -248 12 -243 12 -243 17 -248 17 -248 12 16 LABEL -245.5 2 16 "Select contents,\nclear outside,\nthen Play" ]]

A secondary thing to notice: the history cells in the leftmost column in which they appear seem to fade slower than all other history cells on the board, which is presumably an issue linked to some previous reports.

The top right boundary cell of this period/frequency map isn't adjacent to any internal cells and therefore can probably be removed. On the other side of things, it may be worth adding some more boundary cells elsewhere on the left and right boundaries of this map so that cells inside aren't diagonally adjacent to the exterior (similarly to what was done for triangular bounded grids a year or so ago).

Code: Select all

x = 33, y = 33, rule = B135/S0246HInvestigator:P39
E15.E16$E15.A15.E16$16.E15.E!
[[ AUTOIDENTIFY ]]

Here's a more intense demonstration of a bug from the last post showing that zoom is also affected:

Code: Select all

x = 2, y = 2, rule = 23/3/192H:P32
2A$2A!

Code: Select all

x = 2, y = 2, rule = 23/3/193H:P32
2A$2A!

Code: Select all

x = 2, y = 2, rule = 23/3/254H:P32
2A$2A!

Code: Select all

x = 2, y = 2, rule = 23/3/255H:P32
2A$2A!

Saving this pattern then attempting to load it will produce an error saying the pattern is too large, despite the pattern being able to exist in this grid just fine before saving. Can either the maximum loadable pattern size be increased, or some sort of warning or error be produced blocking too-large patterns from being saved?

Code: Select all

x = 2, y = 1, rule = B1e/S1e2i
2o!
[[ MAXGRIDSIZE 9 STARTFROM 240 ]]

In themes with no distinct death trail colour, when running Generations patterns with high state counts, the grid boundary ends up being invisible. Since there are no history trail colours to overwrite it, is there some way to have it appear as normal in these cases?

Code: Select all

x = 2, y = 2, rule = /2/193:T20,20+2
AB$AB!
[[ THEME Golly ]]

Much like the aforementioned PCA example try saving both of these patterns. The first will correctly remain unchanged, but the second will expand in bounding box to include all of its dead cells.

Code: Select all

x = 2, y = 4, rule = B2/S
bo$o$o$bo!
[[ STARTFROM 32 ZOOM 8 ]]

Code: Select all

x = 3, y = 4, rule = /2/3
.AB$AB$AB$.AB!
[[ STARTFROM 32 ZOOM 8 ]]

Is it intended that the code boxes in this post are unopenable and result in an error?

Yes since they both have illegal RLE headers.

Should I report these posts (either using the functionality or some dedicated thread) so they can be edited to no longer use an invalid format?

[rowett]

These two patterns run in LifeViewer, but are rejected by Golly. Is this expected behaviour?

This is expected. For those rules LifeViewer supports B0 without Smax whereas Golly does not.

Put the mouse cursor on one of the two highlighted cells and they'll be shown as [bounded] 0 rather than [boundary] like the others

Fixed in build 1380.

Not finding many issues with Pro any longer (besides the unwanted history trail from a year ago). I imagine it's probably near enough to launch?

I've still got a bit of work to do around memory management. I might just have the faster engine enabled for the PopUp viewer but still looking at that.

If this is the first thing you open when loading this page and then you go to the Draw menu, the icons may be absent or use the wrong colour

Fixed in build 1380.

Should I report these posts (either using the functionality or some dedicated thread) so they can be edited to no longer use an invalid format?

No need - I've corrected them.