Pattern viewer for forum threads

[rowett]

I've been thinking for a while if it'd be a good idea to shorten "RotCWorCCW" to "Rot90". Rot90 is ambiguous, but intentionally so, since it doesn't matter if the rotation is 90 degrees clockwise or 90 degrees anti-clockwise - both are valid.

Extending upon this idea: it could be a good idea to rename directional rotations as well, so RotCW would become Rot90CW and RotCCW would become Rot90CCW. This would be future-proof for when mod calculations come to hexagonal and triangular grids, since RotCW and RotCCW would be ambiguous since the rotation can be either 60 or 120 degrees (so in those cases we'd have Rot60CW, Rot60CCW, Rot120CW and Rot120CCW).

Yes, done. Note that if (in a galaxy far, far away) Mod calculations come to hexagonal and triangular grids Flip will need to change as well since there is an additional axis.

[muzik]

It seems like the recent fixes to mod calculations have resulted in some unwanted false results cropping up elsewhere. I hope this is easy to fix, since as per the Fundamental Theorem of Debugging, every time an Identify issue is fixed somewhere, it breaks somewhere else...

Firstly, this Generations RRO from earlier seems to, for a second time, not have its quarter-mod detected as a single unit, but is correctly found when doubled up:

Code: Select all

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

Code: Select all

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

I tested the spaceships from the same post and they all seem to work fine.

On the topic of things rotating 90 degrees, these don't seem to be recognised in Identify at all anymore for PCA patterns, and appear to be detected as half-mods rather than quarter-mods. This affects the single-cell oscillators (as well as larger squares made out of single cells):

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
A!

The mod-8-even-though-that's-impossible from recently also should have a mod of 44, but gets assigned 88 instead:

Code: Select all

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

As do pretty much all other RROs from before:

Code: Select all

x = 4, y = 3, rule = PCA_4
A.B$3.B$2.F!

Code: Select all

x = 6, y = 7, rule = PCA_4
5.H3$H.L.D3$5.B!

This pattern's mod of 782 also goes undetected now:

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
O2$2.O!

For the Model_1 family, those are now classed as FlipXorY instead of FlipXorYorRot90, and the seventh member's mod is not detected at all.

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

This final one is probably a different issue so might be worth fixing separately - this spaceship should have a mod of 1 instead of 2, of type RotCWFlipY, as it's functionally glider reflective (N reflects to E, and vice versa, over a diagonal line that goes the bottom left to the top right).

Code: Select all

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

I really do hope that most of these are an easy fix, preferably something that can be chalked up to a single root issue or wrong assumption somewhere. The joys of programming are endless...

[Book]

This is from Alan Hensel's lifebc collection. It is the only RLE in that collection that the viewer does not like. The pattern works if the comments after the ! are removed, but such comments are also present in the other RLEs in the collection.

Code: Select all

x = 187, y = 206, skip = 5, fps = 40
141boo$141bo$159boo$128boo29bo$128bo$173boo$173bo3$139boo3boo$142bo$
139bo5bo10boo3boo$95boo43booboo12b5o$95bo31b3o11bobo14b3o$126bo3bo11bo
16bo$82boo41bo5bo10bo27booboboo$82bo42bo5bo$128bo41bo5bo$126bo3bo$127b
3o41booboo$128bo44bo$82bo55bobo19bo$82bo13bo41boo21boo$81bobo11b3o27b
3o11bo3b3o14boo$80booboo9b5o26b3o14bo3bo$79bo5bo7boo3boo24bo3bo12bo5bo
$82bo11b5o33bobo6booboboo$79boo3boo8bo3bo24boo3boo3boo39b3o$95bobo35bo
20boo3boo12bo3bo$96bo59b3o$155bo3bo12bo5bo$156bobo13boo3boo$98bo58bo$
96booboo45boo$146bo$95bo5bo45b3o4boo$149bo5bo$95booboboo24boo24b3o$77b
ooboboo42bo9b4o12bo$77bo5bo47boo7bo33boo$78bo3bo48bo3boo3bo24boo7bo6bo
$79b3o53bo3bo15bo6bobobboboo8b3o$153boo6boobbo4bo7bo$154boo10bo11boo$
142boo23bo$100boo40bo19bo$100bo28boo9bobo17b3o13bo$97bo3b3o27bo8boo17b
o14booboo$59boo34bobo5bo17boo9bo26boo$59bo20boo14boo23bo10bo40bo5bo$
80bo8boo41bo$46boo37boobboobboo36bo41booboboo$46bo38bobobbobbo35boo5bo
$86b3o47bobo$60bo26boo47boo40bo$60bo114bobbo$59bobo116bo$58booboo83bo
27boo$57bo5bo82bobo5boo3boo13bo$43bo5bo10bo85boo8b3o15bobo$43bo5bo7boo
3boo30bo60bo3bo15boo$44bo3bo45boo60bobo$45b3o34boo11boo27boo31bo$81b3o
3bo7b3o7boo17bo50boo3boo$78boboo4b4o5boo8bo53boo14bo5bo$71boo5bobbo4bo
4bobboo63bo$71bo6boboo5bo3bobbo65b3o13bo3bo$81b3o3boobo71bo14b3o$82boo
23boo$106bobbo$109bo$59booboboo43bo15bo10boo$59bo5bo40boobo13boo11bobo
15bo$60bo3bo42bo16boo10bo17boo$61b3o$24boo129bo$24bo16boo3boo33bo25boo
45bobo$55bo24bobo24bo19bo25bobbo$11boo29bo3bo9bo11boo9bo3boo8bo9bo21bo
bo24bobbo12bo$11bo31b3o8b3o11bo10bo3boo5b4o10boo20boo39boo3boo3boo$43b
3o33bo3boo4b4o10boo50bo11bobo$64boo14bobo6bobbo47bo13boo17bo3bo$64bo
16bo7b4o45b3o33b3o$65b3o22b4o7boo34bo36b3o$22boo3boo38bo25bo7bobo6bo
26boo$25bo18boo57bo5bo$22bo5bo15bo9bo48boo4b3o50boo9bo$23booboo21b3ob
oobboo57bo41boobboobboo4b3o$10b3o11bobo22b4o4bo58bobo39bobobbobbo4bo3b
o$9bo3bo11bo27boo61boo41b3o11bo$8bo5bo10bo134boo8bo5bo$8bo5bo155bo5bo$
11bo58bo100bo3bo$9bo3bo57bo100b3o$10b3o56b3o61b5o$11bo120bob3obo$21bob
o35bobo71bo3bo$21boo36bo3bo70b3o$8b3o11bo3b3o14bo19bo71bo$8b3o14bo3bo
11b4o14bo4bo4boo50boo$7bo3bo12bo5bo9boboboo17bo5bo51bo60boo$24booboboo
4boobbobbob3o12bo3bo31bo70boo7boo5bo$6boo3boo3boo17bo4boboboo13bobo31b
oo40boo23bo5bobo6bo$16bo24b4o49boo11bo10bobo14bo24b3o3bo9b3o$43bo28bo
33bo10bobbo42bo14bo$71boo33b3o7boo44boo$114boo3bo8boo$72bo43boo10bo$
23bo5boo40bobo43bobbo$24boo3bo31bobo6bobbo44bobo61b3o$23boo5b3o29boo5b
obbo38bo69bo3bo$32bo29bo47b3o67bo5bo$9boo21bobo8boo27bo36b5o66booboboo
$9bo8boo13boo7b3o26boo89booboboo$14boobobboboo15boboo12bo24bo$14bo4bo
bbo16bobbo12boo22bo82bo5bo$18bo20boboo13boo21b3o$17bo24b3o11b3o27bo17b
o58booboo$43boo11boo28bobo13b3o60bo$55boo8boo19boo13bo7b5o$55bo9bobo
33boo7b3o$67bo43bo55bo$67boo97bobo$165bo3bo8boo3boo$76bobo14bobo69b5o
11bo$77boo14boo4bo64boo3boo7bo5bo$77bo16bo3b3o64b5o9booboo$28bo69b3o
65b3o11bobo$28b4o135bo13bo$12bo16b4o63boo3boo78bo$11bobo5boo8bobbo5boo
56bo4bo$9boo3bo14b4o5bo26bo$4boo3boo3bo4boboboo3b4o31boo$4bo4boo3bo5b
oo3bobbo35boo11bo$11bobo10bo51bo103boo$12bo8bobbo15boo34b3o6boo93bo$
40bobo42bo$41b3o123boo$42boo9bo45boo66bo$25b3o3bo7boo13boo43bo$27bo4bo
6b3o11boo$oo24bo3b3o$bo$bobo8boo26boo$bboo8bo5bo21bo9bo$9boo6b5oboo24b
o$8b3o5bobboo4bo23b3o$9boo5boo8bo29bo$12boo4bo7bo29bobo$12bo13bo29boo$
25bo8boo26bo$23boo9bobo23boo$36bo24boo14bo$36boo37b3o$74bo$74boo$32bo$
32bobo$32boo4$69boo3boo$47bo21bobobobo$46bo23b5o$46b3o22b3o$53bo18bo$
53bobo$53boo$$58boo$58bo$$72boo$72bo4$22boo$22bo$32bo$30boo$31boo11$
17bo$16bo$16b3o$23bo$23bobo$23boo6$12boo$12bo!
Single Glider Elbow Ladder

Can the Game of Life support artificial Life? Unfortunately, despite the name 
of the game, Conway's rules have proven less than ideal for the 
construction of patterns that mimic the behavior of life. The pattern would 
be horrendously large and complex. But it has been proven that it can be 
done. To do so, one must imagine a pattern that can construct a copy of 
itself in another location. This is a little hard to imagine without the help
of patterns like Elbow Ladder.

Elbow Ladder is one of many patterns that demonstrate the ability of a finite
pattern to place another object essentially anywhere in the universe. One
detail that aids the imagination is the fact that it consists mostly of p30
glider guns, which can be built from gliders (see GliderGunSyntheses). 

By Scot Ellison, April 1997, based on Dieter Leithner's side shooting 
pseudoperiod 124 glider gun (improved by Dean Hickerson).

[rowett]

This is from Alan Hensel's lifebc collection. It is the only RLE in that collection that the viewer does not like. The pattern works if the comments after the ! are removed, but such comments are also present in the other RLEs in the collection.

Thanks for reporting! Will be fixed in the next release.

[muzik]

This also takes a while (30 seconds plus on my end) to fully identify after it recognises periodicity, and also produces the same kind of map:

Code: Select all

x = 6, y = 47, rule = B2in3-kq4cjy5eky6-e78/S3-jk4-cjnw5ce678
3b2o$2b2o$b4o$b4o$5o$b5o$2b3o$3bo25$2bo$2bo6$bobo$b4o$b4o$b4o$5o$b5o$
2b3o$3bo!

Identifying this now seems to take far, far longer. Once it determines the object to be periodic, it takes upwards of an entire minute for it to actually produce statistics, if at all.

Also, Identify can't decide if this is an oscillator or a spaceship when identified from T=0:

Code: Select all

x = 18, y = 13, rule = B13/S13VHistory
2.F.F.F.F.F2$F9.A.F2$2.F.F.F.F.F!

[rowett]

Identifying this now seems to take far, far longer. Once it determines the object to be periodic, it takes upwards of an entire minute for it to actually produce statistics, if at all.

It's probably not worth any further testing for Identify at the moment until I've released a new version. The requirements to have to check multiple phases for rules like PCA_4 introduced some significant changes (and performance penalty) which would benefit from a re-design rather than continued tweaking.

[muzik]

It's probably not worth any further testing for Identify at the moment until I've released a new version. The requirements to have to check multiple phases for rules like PCA_4 introduced some significant changes (and performance penalty) which would benefit from a re-design rather than continued tweaking.

Understood - I had found those at around the same time as the other 2-state examples (before the report containing all of the PCA issues).

One thing I do want to ask, though, in relation to Identify: why are diagonally-flipping objects described in terms of a rotation followed by an orthogonal flip? I personally have always found these comparatively harder to visualize than the others, since other transforms just say one thing rather than stringing two together (aside from FlipXY, I suppose, but that's arguably different since it's two flips rather than one flip and one rotation).

Another thing on the topic of Identify: there have been several cases where I've clicked "Rand All" instead of Identify, resulting in the entire pattern being overwritten and forcing a page refresh to get to the original pattern (assuming I hadn't isolated it manually from the ash of something, in which case I'd have to rediscover it). While I recall the existence of a "Create new random pattern?" confirmation dialog box, it doesn't appear to show up consistently anymore. (EDIT: It does seem to show up if Identify has been used at least once before on the pattern.)

[rowett]

Another thing on the topic of Identify: there have been several cases where I've clicked "Rand All" instead of Identify, resulting in the entire pattern being overwritten and forcing a page refresh to get to the original pattern (assuming I hadn't isolated it manually from the ash of something, in which case I'd have to rediscover it). While I recall the existence of a "Create new random pattern?" confirmation dialog box, it doesn't appear to show up consistently anymore.

The confirmation box only shows up if the pattern changed.

[muzik]

Here's something not-Identify-related: I tried using paste commands in [R]History and [R]Super to paste in patterns containing cells exclusive to those rulespaces, but the pasted content is solely composed of state-0 and state-1 cells, seemingly the state number modulo 2 (which also means that normally invalid RLEs containing cells with state values outside of what is normally acceptable can be pasted into patterns).

Is this a bug, or are paste commands only intended for the pasting of normal alive and dead cells?

Code: Select all

x = 3, y = 3, rule = B3/S23History
C$A.A$2A!
[[ ZOOM 8 RLE blockofdeath 8F$8F$8F$8F$8F$8F!
RLE notaglider C$A.A$2A$$$ABCDEFGHIJK!
PASTET 30 PASTE blockofdeath -30 30
PASTET 10 PASTE notaglider 20 -20 ]]

Code: Select all

x = 3, y = 3, rule = B3/S23Super
C$A.A$2A!
[[ ZOOM 8 RLE blockofdeath 8F$8F$8F$8F$8F$8F!
RLE notaglider C$A.A$2A$$$ABCDEFGHIJK!
PASTET 30 PASTE blockofdeath -30 30
PASTET 10 PASTE notaglider 20 -20 ]]

If we try this with other rulespaces with higher state counts, the paste commands appear to work as expected:

Code: Select all

x = 3, y = 3, rule = /2/20
C$A.A$2A!
[[ ZOOM 8 RLE blockofdeath 8F$8F$8F$8F$8F$8F!
RLE notaglider C$A.A$2A$$$ABCDEFGHIJK!
PASTET 30 PASTE blockofdeath -30 30
PASTET 10 PASTE notaglider 20 -20 ]]

For 2-state rules (range-1 and general-range) all pasted cells are treated as state-1:

Code: Select all

x = 3, y = 3, rule = B3/S23
A$A.A$2A!
[[ ZOOM 8 RLE blockofdeath 8F$8F$8F$8F$8F$8F!
RLE notaglider C$A.A$2A$$$ABCDEFGHIJK!
PASTET 30 PASTE blockofdeath -30 30
PASTET 10 PASTE notaglider 20 -20 ]]

Code: Select all

x = 3, y = 3, rule = R1,C2,S2-3,B3
A$A.A$2A!
[[ ZOOM 8 RLE blockofdeath 8F$8F$8F$8F$8F$8F!
RLE notaglider C$A.A$2A$$$ABCDEFGHIJK!
PASTET 30 PASTE blockofdeath -30 30
PASTET 10 PASTE notaglider 20 -20 ]]

[muzik]

Some visual bugs I've discovered (none of these are particularly major problems - I'd like to see the Identify fixes sooner, so you don't need to spend too much time on these if you don't want to):

----

Firstly, a bug with higher-range rules. Specifically in the case of 2-state rules, the presence of invalid states causes holes to appear in the viewer. This effect can be overridden if other viewers with other rulespaces have been opened before this one, in the same manner as this bug with [R]Super Niemiec cells from a month ago:

Code: Select all

x = 3, y = 3, rule = R1,C2,S2-3,B3
C$A.A$2A!

Code: Select all

x = 3, y = 3, rule = R1,C3,S2-3,B3
C$A.A$2A!

Since range-1 2-state patterns convert all cells with states greater than 1 to state-0 cells, it might be a good idea to fix this by making higher-range 2-state patterns do the same thing, and therefore make the pattern valid, since this would make them behaviourally more consistent.

Code: Select all

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

----

When the Grid button is disabled (for example, when using Identify, Go To Gen, or when the pattern is loading), the grid shape seen on the button changes to a dark color:

Code: Select all

x = 40, y = 50, rule = B3aeikr4cekrtwy5ckq6cei7/S2cen3-jr4cei5eikq6-a7c8
16bo$15b3o$14b5o$13b7o$12b9o$11b2o2b3o2b2o$10b3o3bo3b3o$9b2o5bo4b3o$8b
5o8b4o$7b4o11b4o$6b4o15b2o$5b2obo16b3o$4b2ob2o7bo7bo2b2o$3b2obo8b3o9b
3o$2b3o9b5o10b2o$b3o9b7o8bob2o$2obo8b9o9b3o$2bobo6b5o2bob2o4bo4b3o$2o
8b5o4b4o9b3o$2bo6b5o7b3o8b4o$8b5o6bobob2o7bob3o$9b5o8b4o9b3o$10b5o8b4o
8b4o$11b5o7b5o6b6o$12b3o8b4o6bob4o$13bo8b4o9b3o$23b2o7bo2b2o$32b4o$32b
3o$32b2o$30b3o$29b3o$27bob2o$28b2o$24b5o$23b5o$22b5o$22b4o$22b3o$21b3o
$18bo2b2o$19b3o$6bo12b2o$9b4o4b3o$8b3o6b2o$9b4ob4o$10b7o$11b5o$12b3o$
13bo!
[[ SHOWTIMING EXTENDEDTIMING
COLOR BACKGROUND Purple
COLOR DEAD Purple
COLOR DEADRAMP Purple
COLOR ALIVE Pink
COLOR ALIVERAMP Pink
COLOR MARK1 Pink
COLOR MARK2 Pink
COLOR MARKOFF Purple
COLOR KILL Purple
COLOR GRID Pink
COLOR GRIDMAJOR Pink
COLOR BOUNDARY Pink
COLOR BOUNDED Pink
COLOR SELECT Pink
COLOR PASTE Pink
COLOR ADVANCE 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
MAXGRIDSIZE 9 ]]

----

When hexagonal and triangular cells are in use and RAINBOW is set to on via commands, the color of bounded-grid boundary cells is also affected. This does not affect square-grid rules (and it can be seen that zooming out beyond 4x or toggling Use Rectangles gets rid of the effect for the duration non-rectangular cells are in use).

Code: Select all

x = 22, y = 17, rule = B3/S23:T20
$bo2b2o2b3obob4ob3o$2b2o3bo2bo2b2ob2obobo$2b2o3bobob2o3b3o2bo$o2b2obo
2bo6b2o2b2o$o2b2o6bob5o3bo$2b4obo5b5obobo$3obob2o2b2ob3ob3obo$bob2o2b
o2bob2o2b4o$2bob6obo3b6o$bo2b4o4b3o3b4o$2o5b3ob2o4bo$6bob3obo2b3o3bo$
4ob2o3b2o2b6obo$4bob3ob2o2b2ob3obo$ob3ob4ob4ob2o2bo$ob4obo2b2ob2ob5o!
[[ SHADER Rainbow ]]

Code: Select all

x = 22, y = 17, rule = B3/S23H:T20
$bo2b2o2b3obob4ob3o$2b2o3bo2bo2b2ob2obobo$2b2o3bobob2o3b3o2bo$o2b2obo
2bo6b2o2b2o$o2b2o6bob5o3bo$2b4obo5b5obobo$3obob2o2b2ob3ob3obo$bob2o2b
o2bob2o2b4o$2bob6obo3b6o$bo2b4o4b3o3b4o$2o5b3ob2o4bo$6bob3obo2b3o3bo$
4ob2o3b2o2b6obo$4bob3ob2o2b2ob3obo$ob3ob4ob4ob2o2bo$ob4obo2b2ob2ob5o!
[[ SHADER Rainbow ]]

Code: Select all

x = 22, y = 17, rule = B3/S23L:T20
$bo2b2o2b3obob4ob3o$2b2o3bo2bo2b2ob2obobo$2b2o3bobob2o3b3o2bo$o2b2obo
2bo6b2o2b2o$o2b2o6bob5o3bo$2b4obo5b5obobo$3obob2o2b2ob3ob3obo$bob2o2b
o2bob2o2b4o$2bob6obo3b6o$bo2b4o4b3o3b4o$2o5b3ob2o4bo$6bob3obo2b3o3bo$
4ob2o3b2o2b6obo$4bob3ob2o2b2ob3obo$ob3ob4ob4ob2o2bo$ob4obo2b2ob2ob5o!
[[ SHADER Rainbow ]]

Turning RAINBOW off and back on appears to correct this until the page is refreshed (and is also likely the reason why this issue doesn't manifest if RAINBOW isn't turned on by default via scripting). Like the "LifeViewer has encountered a problem in the form of some Windows" bug at the top of this post, this rendering issue also appears to vary depending on what was opened before it - if the first popup you open on this page is one of the ones for the issue below, the boundaries might render completely black, but I haven't been able to explicitly reproduce this result.

When all cells die as a result of playback, the boundary color also changes rapidly before everything turns black (excluding the edges of the boundary cells, for some reason).

----

Another thing for hexagonal and triangular grids: I'm going to assume that it's known that the area outside of unbounded grids don't render when hexagonal and triangular cell shapes are in use? You did imply yesterday that it isn't "rendered with cells", so I'm going to assume that this is the reason why it doesn't render in these cases. I feel like this has also been known for a while, but don't remember reporting it myself.

Code: Select all

x = 5, y = 5, rule = B2/S2H
o$2o$bo2$obobo!
[[ GRID ZOOM 16 X -128 Y -256 STARTFROM 370 MAXGRIDSIZE 9 ]]

Code: Select all

x = 5, y = 3, rule = B36/S12LV
bobo$b2obo$2bo!
[[ GRID ZOOM 16 X -256 STARTFROM 250 MAXGRIDSIZE 9 ]]

Code: Select all

x = 5, y = 5, rule = B2/S2H
o$2o$bo2$obobo!
[[ GRID ZOOM 16 SQUARECELLS X -128 Y -256 STARTFROM 370 MAXGRIDSIZE 9 ]]

Code: Select all

x = 5, y = 3, rule = B36/S12LV
bobo$b2obo$2bo!
[[ GRID ZOOM 16 SQUARECELLS X -256 STARTFROM 250 MAXGRIDSIZE 9 ]]

There also appears to be a spelling error in Help > Scripts > Display for triangular rules in specific: "rectangular" in the SQUARECELLS description is "rectangualr".

----

This one is incredibly minor, but when playing these two otherwise identical patterns, the living cells appear to physically overlap each other in [R]History but have noticeable gaps in [R]Super:

Code: Select all

x = 2, y = 2, rule = B2/S34HHistory
o$o!

Code: Select all

x = 2, y = 2, rule = B2/S34HSuper
o$o!

I assume that for hexagonal rules, certain cells have priority when rendering over other cells, so state 1 should be considered more important than state 2 for [R]Super.

----

Cell borders render on top of snow, which looks quite bizarre. I can see why the normal grid and major grid lines would render on top of snow, but cell borders are supposed to be gaps between cells, so it looks odd in this case. It results in a flickering effect as the particles fall, makes them appear to levitate once they hit the top of a cell, and the cell borders remain on top of the snow even after large amounts have piled up.

Code: Select all

#C [[ ZOOM 8 ]]
#C [[ RLE null b! ]]
#C [[ NOGUI ]]
#C [[ CELLBORDERS ]]
x = 29, y = 8, rule = B/S012345678
200o!

For comparison, the starfield effect is notably not occluded by cell borders, meaning that stars can even be seen through gaps between cells. If we turn on the grid, the grid occludes the stars, as expected.

Code: Select all

#C [[ ZOOM 4 CELLBORDERS STARS ]]
x = 29, y = 8, rule = B/S012345678
20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o!

----

Depending on the zoom level, viewer size and where the camera is centered, high-quality rendering can cause parts of cells to visually bleed out from grid lines or cell borders:

Code: Select all

x = 6, y = 6, rule = B3/S23
b3o$bob3o$4obo$ob4o$3obo$2b3o!
[[ CELLBORDERS QUALITY ZOOM 4.82 ]]

[Book]

Thanks for reporting! Will be fixed in the next release.

Thanks. How to know when the next release is available?

[muzik]

Not an Identify bug, but a thought: would it make more sense to use the period-1 color for "period-2" cells on period maps for alternating rules? Since period-1 cells technically cannot exist in an oscillator in an alternating rule due to LifeViewer's current handling of Identify, and period-2 cells are considered stator cells, having said cells be displayed as such would make this more clear.

Code: Select all

x = 13, y = 13, rule = B3/S23
2b3o3b3o2$o4bobo4bo$o4bobo4bo$o4bobo4bo$2b3o3b3o2$2b3o3b3o$o4bobo4bo$
o4bobo4bo$o4bobo4bo2$2b3o3b3o!

Code: Select all

x = 13, y = 13, rule = B3/S23|B3/S238
2b3o3b3o2$o4bobo4bo$o4bobo4bo$o4bobo4bo$2b3o3b3o2$2b3o3b3o$o4bobo4bo$
o4bobo4bo$o4bobo4bo2$2b3o3b3o!

Code: Select all

x = 1, y = 1, rule = B1e/S0|B2i/S3e4e
o!

Code: Select all

x = 5, y = 1, rule = B1e/S0|B2i/S3e4e
o3bo!

[muzik]

Is it just a bug on my end, or do "SHOW IN VIEWER" prompts not appear in the first two pages of this thread? Other threads seem to work just fine, as does the third page, but even after waiting a considerable amount of time they just don't appear on this one.

[hotdogPi]

Is it just a bug on my end, or do "SHOW IN VIEWER" prompts not appear in the first two pages of this thread? Other threads seem to work just fine, as does the third page, but even after waiting a considerable amount of time they just don't appear on this one.

I'm getting the same thing.

[rowett]

Is it just a bug on my end, or do "SHOW IN VIEWER" prompts not appear in the first two pages of this thread? Other threads seem to work just fine, as does the third page, but even after waiting a considerable amount of time they just don't appear on this one.

It works for me. There is a delay which is caused by an image failing to load (for example in this post).

LifeViewer doesn't put up the "Show In Viewer" prompts until the entire page has loaded and that's being blocked by it attempting (and eventually timing out) to load the image I mentioned. Chrome log shows:
Failed to load resource: net::ERR_CONNECTION_REFUSED 69435.jpeg:1

[muzik]

LifeViewer doesn't put up the "Show In Viewer" prompts until the entire page has loaded and that's being blocked by it attempting (and eventually timing out) to load the image I mentioned. Chrome log shows:
Failed to load resource: net::ERR_CONNECTION_REFUSED 69435.jpeg:1

After having waited on the page for a while I can confirm that this is the case and that the code boxes eventually do become usable. I had noticed after posting that the page was taking extra time to load.

[rowett]

It's probably not worth any further testing for Identify at the moment until I've released a new version.

The latest build (897) of LifeViewer contains an experimental new Identify engine. It's typically faster than the original and has more robust checks to ensure oscillator mods are calculated correctly and that spaceships are really spaceships.

Note 1: It's not yet complete and for multi-state patterns does not calculate Active Cells, Temperature or Volatility.

Note 2: Fast Identify has gone. I'll rebalance the menu at some stage.

[rowett]

Identifying this now seems to take far, far longer. Once it determines the object to be periodic, it takes upwards of an entire minute for it to actually produce statistics, if at all.

The new engine is significantly faster. On my machine the total detection is now around 10 seconds.

Also, Identify can't decide if this is an oscillator or a spaceship when identified from T=0:

Code: Select all

x = 18, y = 13, rule = B13/S13VHistory
2.F.F.F.F.F2$F9.A.F2$2.F.F.F.F.F!

Fixed, thanks.

[rowett]

Firstly, a bug with higher-range rules. Specifically in the case of 2-state rules, the presence of invalid states causes holes to appear in the viewer.

Fixed, thanks.

When hexagonal and triangular cells are in use and RAINBOW is set to on via commands, the color of bounded-grid boundary cells is also affected.

Fixed, thanks.

There also appears to be a spelling error in Help > Scripts > Display for triangular rules in specific: "rectangular" in the SQUARECELLS description is "rectangualr".

Fixed, thanks.

[rowett]

Thanks for reporting! Will be fixed in the next release.

Thanks. How to know when the next release is available?

This is now fixed, thanks.

[muzik]

The new Identify is a massive improvement so far! From my testing so far, the RRO example above is identified in nine seconds, the p40894 pRNG oscillator is done in five, the p25200 combination oscillator containing about 40 disc tint periods takes four, and the p39366 in the non-isotropic rule that was used for pointing out color contrast is done in about two.

This one still takes a while to fully resolve once it detects the period, however LifeViewer actually figuring out that it's periodic is much faster - its changing and expanding bounding box gave the old Identify a lot of trouble. It now finishes detecting the period in just under three seconds where it previously (according to a cached copy of build 896) took 19:

Code: Select all

x = 7, y = 5, rule = B2in3aijqr4ikqz5r6n/S2aek3-ae4city5-ejqy6a7e
2bo$b3o$2obo$bobo$4bobo!

I can confirm that the [R]History case I posted about here is fixed as well. I've done some not-too-rigorous testing of the rule with higher period replicator shuttles and they seem to be correctly identified as oscillators as well. The only examples of oscillators that are misidentified as spaceships that I know of that remain are cases like the following, which I ultimately don't think are fixable in the first place without further refactoring which probably isn't worth it:

Code: Select all

x = 33, y = 4, rule = B2/SHistory
.F14.A14.F$F13.A17.F$14.A$.F14.A14.F!

Anyway, here's a small Identify-related feature request: would it be possible to add a third value to the Volatility row which displays the percentage of rotor cells (as opposed to total cells) that oscillate at the full period? For example, any oscillator with a prime period as well as any "volmatchstrict" composite-period oscillator such as Merzenich's p64 would return a value of 1, since all periodic cells oscillate at the full period, whereas for an oscillator such as a statorless p92, we'd get a lower value due to the presence of some period-23 and period-46 cells.

Code: Select all

x = 21, y = 21, rule = B3/S23
5b2o$5b2o3$5bo$4b3o12b2o$4bo3bo10b2o$6bobo$6b3o4$12b3o$12bobo$2o10bo3bo$2o12b
3o$15bo3$14b2o$14b2o!

Code: Select all

x = 38, y = 41, rule = B3/S23
22b3o$6bo13bo3bo$6bo4b2o6bo4bo$10bo2bo5bo3bo$9b2ob2o$6b2obobo7bo3bo$5b5o9bo4b
o$4b3o13bo3bo$bo2b2o2b2o12b3o$bo3bobo$obo4bo$bo$bo2$28b3o3b3o$27bo2bo3bo2bo$
27b2obo3bob2o6$3b2obo3bob2o$3bo2bo3bo2bo$4b3o3b3o6$b2o13b3o8b2o6b3o$b2o4b3o6b
o3bo6b2o5bo2bo$6b2ob2o5bo4bo10b2o2b2o$6bo2b2o6bo3bo11b3o$7b2o25bo$17bo3bo7b3o
$16bo4bo6b5o$16bo3bo6bo2bobo$16b3o9bo3bo$29b3o$29b2o!

EDIT: the period table for the first of these two patterns correctly has a rotor percentage of 100.00% in the last column, but the second only has 99.99%. This was not the case in build 896.

Code: Select all

x = 1, y = 1, rule = B1357/S02468:T129,129
o!

Code: Select all

x = 1, y = 1, rule = B02468/S1357:T129,129
o!

[muzik]

Note 2: Fast Identify has gone. I'll rebalance the menu at some stage.

Assuming it's gone forever, I'd recommend moving Last Identify from the General menu into its place, since I often find myself going into the Pattern menu looking for it before realising it's inside General.

[muzik]

For a break from Identify, here's some Generations stuff:

Firstly, a suggestion: if a dying state's color is changed, could a gradient be used leading up to that cell? For the following example, one of the state's colors is changed. While this currently only affects a single state, LifeViewer could instead have the existing defined colors fade into it: since the alive state is yellow, the early dying states would fade from yellow to white, and after reaching the customized dying state, they would fade from white to red before dying out completely.

Code: Select all

x = 33, y = 2, rule = /2/34
pIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$pIpHpGpFpEpDpCpBpAXWVUTSRQ
PONMLKJIHGFEDCBA!
[[ COLOR "alive" 255 255 0 COLOR "dying 16" 255 255 255 COLOR DYINGRAMP 255 0 0 ]]

This would make it more behaviourally consistent with changing the alive state's color, which does change the gradient:

Code: Select all

x = 33, y = 2, rule = /2/34
pIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$pIpHpGpFpEpDpCpBpAXWVUTSRQ
PONMLKJIHGFEDCBA!
[[ COLOR "alive" 255 255 255 COLOR DYINGRAMP 255 0 0 ]]

Secondly, 192-state Generations rules still don't work as expected on bounded grids. Upon hitting Play, the population jumps from 2 to 70, and when the pattern hits the boundary, the population drops to 68 instead of the pattern dying out, pausing the viewer and displaying a message.

Code: Select all

x = 2, y = 2, rule = /2/191:P16
2B$2A!
[[ SHOWGENSTATS ]]

Code: Select all

x = 2, y = 2, rule = /2/192:P16
2B$2A!
[[ SHOWGENSTATS ]]

Code: Select all

x = 2, y = 2, rule = /2/193:P16
2B$2A!
[[ SHOWGENSTATS ]]

Finally, could DEADRAMP and/or DEAD be made to not show in Help > Themes if the number of dying states is sufficiently high as to either disallow the existence of distinct newly-dead and long-since-dead states (for rules ending in /255) or the existence of distinct background and dead-but-was-once-alive states (for rules ending in /256)? Since a similar thing was done for 3-state Generations rules recently (since they have no distinct DYING and DYINGRAMP colors) there could be equivalent such treatment here.

Code: Select all

x = 2, y = 2, rule = /2/254
2B$2A!
[[ STARTFROM 260 ]]

Code: Select all

x = 2, y = 2, rule = /2/255
2B$2A!
[[ STARTFROM 260 ]]

Code: Select all

x = 2, y = 2, rule = /2/256
2B$2A!
[[ STARTFROM 260 ]]

[GUYTU6J]

On a catagolue page with glider synthesis, such as the blinker, identify results partly overlap with the bottom row of buttons that is shown by default. Comparing with that in a popup viewer (which the page also includes and has a larger height), I see that the identify results box is put at a fixed distance to top row of buttons. Can this be changed to avoid overlap?
---
Unrelated old issue, why is this History pattern with PASTE commands initially drawn without state-2 cells defined by RLE?

...

Code: Select all

x = 34, y = 34, rule = B3-jknr4ity5ijk6i8/S23-a4city6c7cHistory
13.B$12.3B$11.5B.2B$11.9B$11.10B$9.2B.10B$8.3BABA8B$7.3B3ABA8B$6.3BAB
A12B$5.3B2A16B$5.4B2ABA19B$2.3B.5B2A20B$.11BA21B$33B$.18BA10B$2.16BAB
A8B$3.14B.BA10B$2.14B3.10B$2.13BDB3.8B$3.11BDBDB3.6B$4.11BD3B5.B$5.
15B$7.13B$8.12B$9.12B$9.11B$10.10B$10.9B$10.8B$10.5B.B$10.4B$10.4B$
11.3B$12.B!
#C [[ PASTET EVERY 102 0 PASTEMODE COPY PASTE 5BAB$4BABA$3B.BAB$2B3.2B$BDB3.B$DBDB$BD3B! 14 14 ]]
#C [[ PASTET EVERY 102 51 PASTEMODE COPY PASTE 5BDB$4BDBD$3B.BDB$2B3.2B$BAB3.B$ABAB$BA3B! 14 14 ]]

...

[rowett]

I'd recommend moving Last Identify from the General menu into its place, since I often find myself going into the Pattern menu looking for it before realising it's inside General.

Done, thanks.