Pattern viewer for forum threads

[unname4798]

And also rotate the result by 90.

[b-engine]

And also rotate the result by 90.

That would be completely unnecessary work for something worse. What did you expect?

[unname4798]

90° rotation at the end aligns the correct result with the wrong result.

[b-engine]

Obviously this is very stretched, but the solution is simple: when displaying it in LifeViewer, you'd just squish it inwards by a factor of 2, like is done to vertically stretch triangular-grid period maps, using a scaling method that doesn't introduce blur. The results, at least to my understanding, should look far better at scales like this.

Maybe not 2, but a slightly lower factor.

Compare the hexagonal map:

Code: Select all

x = 37, y = 45, rule = B/S0123HT
7bo$7b2o$bo4b5o4bo$4ob8ob4o$19o$20o$b19o$b20o$2b19o$3b18o$3b19o$3b20o
$4b19o$5b18o$5b19o$5b20o$b29o$32o$33o$34o$b33o$b34o$2b33o$2b34o$3b33o
$3b34o$4b33o$5b32o$7b29o$12b20o$13b19o$14b18o$14b19o$14b20o$15b19o$16b
18o$16b19o$16b20o$17b19o$17b20o$18b19o$19b4ob8ob4o$21bo4b5o4bo$28b2o$
29bo!

And the map if it's squished by factor of 2:

Code: Select all

x = 68, y = 90, rule = B/S01234V
33b2o$33b2o$32b4o$32b4o$19b2o8b10o8b2o$19b2o8b10o8b2o$16b8o2b16o2b8o$
16b8o2b16o2b8o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$14b40o$14b40o
$15b38o$15b38o$16b36o$16b36o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o
$16b36o$16b36o$15b38o$15b38o$14b40o$14b40o$5b58o$5b58o$2b64o$2b64o$b66o
$b66o$68o$68o$b66o$b66o$68o$68o$b66o$b66o$68o$68o$b66o$b66o$68o$68o$b
66o$b66o$2b64o$2b64o$5b58o$5b58o$14b40o$14b40o$15b38o$15b38o$16b36o$16b
36o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$16b36o$16b36o$15b38o$15b
38o$14b40o$14b40o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$16b8o2b16o
2b8o$16b8o2b16o2b8o$19b2o8b10o8b2o$19b2o8b10o8b2o$32b4o$32b4o$33b2o$33b
2o!

The square one is slightly "skinny". A slightly lower factor would make it "fatter" at x-axis, which would resemble the hexagonal one more.

90° rotation at the end aligns the correct result with the wrong result.

What do you mean the correct result and wrong result??

[muzik]

Obviously this is very stretched, but the solution is simple: when displaying it in LifeViewer, you'd just squish it inwards by a factor of 2, like is done to vertically stretch triangular-grid period maps, using a scaling method that doesn't introduce blur. The results, at least to my understanding, should look far better at scales like this.

Maybe not 2, but a slightly lower factor.
The square one is slightly "skinny". A slightly lower factor would make it "fatter" at x-axis, which would resemble the hexagonal one more.

This may be true, but aren't square cells on the hexagonal grid (both in the viewer proper and in displayed period maps) already vertically squished to a degree that fixes this? Compare:

Code: Select all

# actual hexagonal grid
x = 37, y = 45, rule = B/S0123HT
7bo$7b2o$bo4b5o4bo$4ob8ob4o$19o$20o$b19o$b20o$2b19o$3b18o$3b19o$3b20o
$4b19o$5b18o$5b19o$5b20o$b29o$32o$33o$34o$b33o$b34o$2b33o$2b34o$3b33o
$3b34o$4b33o$5b32o$7b29o$12b20o$13b19o$14b18o$14b19o$14b20o$15b19o$16b
18o$16b19o$16b20o$17b19o$17b20o$18b19o$19b4ob8ob4o$21bo4b5o4bo$28b2o$
29bo!
[[ SQUARECELLS ]]

Code: Select all

# your 2×2 block example
x = 68, y = 90, rule = B/S01234V
33b2o$33b2o$32b4o$32b4o$19b2o8b10o8b2o$19b2o8b10o8b2o$16b8o2b16o2b8o$
16b8o2b16o2b8o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$14b40o$14b40o
$15b38o$15b38o$16b36o$16b36o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o
$16b36o$16b36o$15b38o$15b38o$14b40o$14b40o$5b58o$5b58o$2b64o$2b64o$b66o
$b66o$68o$68o$b66o$b66o$68o$68o$b66o$b66o$68o$68o$b66o$b66o$68o$68o$b
66o$b66o$2b64o$2b64o$5b58o$5b58o$14b40o$14b40o$15b38o$15b38o$16b36o$16b
36o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$16b36o$16b36o$15b38o$15b
38o$14b40o$14b40o$15b38o$15b38o$14b40o$14b40o$15b38o$15b38o$16b8o2b16o
2b8o$16b8o2b16o2b8o$19b2o8b10o8b2o$19b2o8b10o8b2o$32b4o$32b4o$33b2o$33b
2o!

A smaller oscillator with a map that shows the actual grid - observe how the cells are distorted from perfect squares to compensate:

Code: Select all

x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!
[[ GRID SQUARECELLS AUTOIDENTIFY ]]

[muzik]

When saving patterns on a bounded grid, can the relative position of that pattern to the edges be retained? If we step this forward one generation, save it, then reload, it, the overall behaviour is different to if we hadn't saved and reloaded it.

Code: Select all

x = 25, y = 25, rule = B3/S23:S25*
22bo2$24bo4$11bo$11bobo$11b2o14$o2$2bo!

There is some incorrect symmetry recognition going on in [R]History, seemingly specific to Pro - this isn't recognised as FlipY when it should be. [R]Super and [R]Investigator work fine. All cases function as expected in LifeViewer Standard. (Side note, why does Investigator take one more generation to recognise periodicity?)

Code: Select all

x = 3, y = 2, rule = LifeHistory
2AF$A.F!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 3, y = 2, rule = LifeSuper
2AF$A.F!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 3, y = 2, rule = LifeInvestigator
2AC$A.C!
[[ AUTOIDENTIFY ]]

Another LifeViewer Pro oddity I noticed: the leftmost column and topmost row of the grid behave strangely. Note how, on Standard, this pasted block appears directly touching both boundaries. In Pro (and this does visually change if we toggle WASM Engine), it appears one cell away from the left border, and it also appears as a pre-beehive as the top row seems duplicated such that there are six visible cells, even though the counter still says four. Mousing over the top row or left column displays [boundary] instead of dead or alive, further implying these are supposed to render as out of bounds cells.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ GRID MAXGRIDSIZE 9 SHOWGENSTATS X -256 Y -256 PASTE 2o$2o -256 -256 ]]

Is pattern identification supposed to be blocked if paste commands are only used for placing objects at generation 0, rather than modifying patterns during playback?

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTE 3o! 0 0 AUTOIDENTIFY ]]

Depending on where the viewer is displayed, there can be a slight excess to a considerable empty volume below the frequency key:

Code: Select all

x = 86, y = 84, rule = B3/S23
29bo$28b3o$27bobobo$26b2o2b2o$28bo$26b3o$26bo10$38bo$36bobo$37b2o7$84bo$31b3o
21b3o25bobo$30bo2bo49bobo$30bo2bo25bo24bo$52b3o4bo12b2o2bo$29b2o22bo5bo11b3o
2b2o$29bo21b2o9b2o8b2o2b3o$50bo11b2o8b2o2b2o$49b2o$49b2obo$49bob2o$50bo3b3o$
53bo2bo$52bobo$51bo2bo$52b2o3$32b2o$31bo2bo$31bobo$29bo2bo$29b3o3bo$33b2obo$
33bob2o$35b2o$8b2o2b2o8b2o11bo$7b3o2b2o8b2o9b2o21bo$8b2o2b3o11bo5bo22b2o$9bo
2b2o12bo4b3o$bo24bo25bo2bo$obo49bo2bo$obo25b3o21b3o$bo7$47b2o$47bobo$47bo10$
59bo$57b3o$57bo$54b2o2b2o$54bobobo$55b3o$56bo!
[[ AUTOIDENTIFY COLOR UIBACKGROUND Blue ]]

popupkey.png (47.13 KiB) Viewed 1220 times

embedkey.png (67.2 KiB) Viewed 1220 times

If we now reject values for startfrom with excessive overflowing values, should the same be done for other cases that trigger overflows, or are these sufficiently far out of any reasonable input that they can be ignored, especially since no undefined behaviour occurs?

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B0,2,4,6,8
2o$2o!
[[ AUTOFIT AUTOSTART MAXGRIDSIZE 4294967310 HISTORYSTATES 4294967359 AGESTATES 4294967359 ]]

Possible crash bug: scribble around this bug as much as you can, then press play. Furthermore, if you close the popup then reopen it, it advances an extra generation and the bug dies. Pro does not appear to be affected.

Code: Select all

x = 138, y = 124, rule = R100,C0,M1,S5612..9776,B5612..7585,NN
34b17o38b14o$30b31o16b30o$28b81o$26b85o$25b88o$23b92o$22b94o$20b97o$
19b100o$18b102o$17b104o$16b106o$15b108o$14b110o$13b112o$12b114o$11b
116o$11b116o$10b118o$9b120o$9b120o$8b122o$7b124o$7b124o$6b126o$6b126o$
5b128o$5b128o$4b130o$4b130o$3b132o$3b132o$2b133o$2b134o$2b134o$b135o$b
136o$b136o$b136o$137o$137o$137o$66o6b66o$61o16b61o$58o22b58o$55o28b55o
$53o32b53o$52o34b52o$50o38b49o$50o38b49o$49o40b48o$49o40b48o$b47o42b
47o$b47o42b47o$b47o42b46o$b46o44b45o$2b45o44b45o$2b45o44b44o$2b45o44b
44o$3b44o45b43o$3b43o46b42o$3b43o46b42o$4b42o46b42o$4b42o46b41o$4b42o
46b41o$5b41o46b41o$5b41o46b40o$5b41o46b40o$6b40o46b40o$6b40o46b39o$7b
39o46b39o$7b39o46b39o$7b39o46b38o$8b38o46b38o$8b38o46b38o$9b37o46b37o$
9b37o46b37o$9b37o46b36o$10b36o46b36o$10b36o46b36o$10b36o46b35o$11b35o
46b35o$11b35o47b34o$11b35o47b34o$12b34o47b33o$12b34o46b34o$12b34o46b
34o$13b34o45b33o$13b34o45b33o$13b34o46b32o$13b34o46b32o$13b34o46b32o$
14b33o46b31o$14b33o46b31o$14b33o45b32o$14b33o45b32o$15b32o46b30o$15b
32o46b30o$15b32o46b30o$16b31o46b29o$16b31o46b29o$16b31o46b29o$17b30o
46b28o$17b30o46b28o$18b29o46b27o$18b29o44b29o$19b32o36b33o$19b37o25b
38o$20b99o$20b98o$21b96o$21b96o$22b94o$23b92o$24b90o$26b86o$28b82o$31b
76o$34b70o$37b64o$41b55o$46b45o$52b34o$58b22o!
[[ MAXGRIDSIZE 10 STARTFROM 26 ZOOM 2 Y -256 ]]

STARTFROM's message does not go away instantly if used on empty patterns.

Code: Select all

x = 1, y = 1, rule = B/S0
!
[[ STARTFROM 1 ]]

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ STARTFROM 1 ]]

[muzik]

Saving a pattern with Life32:

life32-save-dialog.png (28.12 KiB) Viewed 1185 times

will result in a pattern where comments are placed after the end of the RLE:

Code: Select all

x = 53, y = 50, rule = S23/B3
14bo12boo$9boobbobo10bobbo$9boobboboo8booboo$14b3o9bobo6bo5bo$16boo4b
oo3bo6bobo4bo$22bobbo8bobbo$26bo8boo$22boobbo21b3o$22boobo21bo3bo$22b
ooboo14bo4bo5bo$23boboo13b3o9bo$24boo5boo6booboo3boo3bo$31boo7b3o6boo$
41bo3$46bo$41boobboboo$16bobboo12boo6bobobboo$15bo17boo6boboobo$15bo
26boo$15boo3bobboo$17b4o$20bo$20bo21bo$24bo8boo6bobo$24bo7bobbo5bobo$
24boobbo3bobbo6bo$7bobo23boo$7bobo35boo$25bobbo11bobooboo$7bobo6boo7bo
13booboo$bb3obo3bo6bo20boo4bobo$bo5bobo6boo19b3o4boo$obboobobo7bo21boo
5boboo$bob4o39boo$6bo20boo$4bobboo18bo$4boo3bo28bo$9bo26booboo$6b3o27b
obboo$36bo6bo$38bo$38bobboobboo$37bo9bo$37booboo4bo$40bo$13bo$11boo$
12boo!
This is an example pattern saved with Life32.

These comments are not displayed in the Help > Comments menu. Would adding support for this format be possible, or is this a one-off nonstandard/dated format that should be avoided?

[Resu]

Code: Select all

x = 49, y = 108, rule = Arrow
25.Q2.2Q$24.Q.Q.Q.Q$18.G5.Q.Q.2Q$7.B3.B13.Q2.Q.Q2$17.F2$3.B7.B$18.E4$
18.K5.Q2.Q2.Q2.3Q$24.2Q.Q.Q.Q2.Q$24.Q.2Q.Q.Q2.Q$3.B3.B7.B8.Q2.Q2.Q3.Q
2$17.F4$16.G.K5.Q2.Q2.Q2.2Q$9.B3.B10.2Q.Q.Q.Q.Q.Q$24.Q.2Q.Q.Q.2Q$15.F
8.Q2.Q2.Q2.Q.Q2$5.B7.B3.F$16.E2$24.Q.Q.Q2.Q2.Q2.2Q$24.Q.Q.2Q.Q.Q.Q.Q.
Q$18.G6.Q2.Q.2Q.Q.Q.2Q$9.B3.B10.Q.Q.Q2.Q2.Q2.Q.Q2$15.J2$5.B7.B$18.E2$
24.Q.Q2.Q2.2Q$18.G.K3.Q.Q.Q.Q.Q.Q$9.B3.B6.C4.Q2.Q.Q.2Q$24.Q.Q2.Q2.Q.Q
$15.J2.B2$5.B7.B5.F$18.E3$20.K$17.G6.2Q4.2Q$14.B9.Q.Q2.Q$24.2Q4.Q$16.
J7.Q.Q.2Q2$19.F2$2.B$17.E3$20.K$17.G6.3Q$B13.B10.Q$25.Q$16.J8.Q2$19.F
4$24.3Q.Q2.Q.2Q2.Q2.Q2.Q2.3Q$24.Q.Q.2Q.Q.Q.Q.2Q.Q.Q.Q2.Q$18.G5.3Q.Q.
2Q.Q.Q.Q.2Q.Q.Q2.Q$9.B3.B10.Q.Q.Q2.Q.2Q2.Q2.Q2.Q3.Q$19.Q$17.F2$5.B7.B
$19.E$24.3Q.Q2.Q.2Q$24.Q.Q.2Q.Q.Q.Q$24.3Q.Q.2Q.Q.Q$24.Q.Q.Q2.Q.2Q$16.
G$7.B3.B5.F2$13.J5.Q$13.J5.Q2$3.B7.B6.C$16.E.I$24.Q2.Q.3Q.Q2.Q.2Q$24.
2Q.Q.Q.Q.2Q.Q.Q.Q$24.Q.2Q.3Q.Q.2Q.Q.Q$24.Q2.Q.Q.Q.Q2.Q.2Q2$16.J$16.G$
7.B3.B2$13.J5.Q$13.J5.Q2$3.B7.B$16.E2$18.I!

Why is the rule set to B3-jkn4a/S1e2-a3ijnry4n?

[muzik]

Why is the rule set to B3-jkn4a/S1e2-a3ijnry4n?

This rule came later and ended up being considerably more popular: viewtopic.php?t=3395

[rowett]

Is snow simulation tied to refresh rate?

Fixed in build 1319, thanks.

Three of the bounded grid edges are covered by history cells, but the top one is not, even though with this pattern you'd expect all of them to be treated the same.

Fixed.

There is some incorrect symmetry recognition going on in [R]History, seemingly specific to Pro - this isn't recognised as FlipY when it should be.

Fixed.

Another LifeViewer Pro oddity I noticed: the leftmost column and topmost row of the grid behave strangely.

Fixed.

[muzik]

Possible crash bug:

Can confirm that this is a crash bug, since changes to the browser window will cause the contents of the viewer popup to become completely transparent (on iPad) / entirely black (on desktop browsers I've tried with).

There are videos in the #tools channel on the Discord server: https://discord.com/channels/3579222555 ... 7616260308

Is it at all possible for LifeViewer to detect if it has crashed, and display an error screen of some description to communicate this more clearly? Furthermore, could the extra generation step be stopped from bleeding into other popup viewer sessions somehow?

[rowett]

Is it at all possible for LifeViewer to detect if it has crashed, and display an error screen of some description to communicate this more clearly?

I've added experimental crash detection into LifeViewer. Once a crash has been detected you'll need to refresh the browser to reset LifeViewer.

[muzik]

Crash detection definitely works (the background still disappears when changing window size and such but user interface elements now remain).

On the topic of error handling: when creating custom icons, the fact that getting one icon wrong results in the entire set of icons being invalidated makes things extremely inconvenient when making icon sets. Compare these two - the second pattern has a line of eight in the second icon's definition rather than the expected line of seven:

Code: Select all

x = 6, y = 2, rule = IconDemo1
2A2.2B$2A2.2B!
[[ ICONS ]]
@RULE IconDemo1
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 96 96 96
1 255 0 0
2 255 0 0
@ICONS
XPM
"7 14 2 1"
"A c #FFFFFF"
". c #000000"
"AA.A.AA"
"AA.A.AA"
"..AAA.."
"AAA.AAA"
"..AAA.."
"AA.A.AA"
"AA.A.AA"
"..A.A.."
"..A.A.."
"AA...AA"
"...A..."
"AA...AA"
"..A.A.."
"..A.A.."

Code: Select all

x = 6, y = 2, rule = IconDemo2
2A2.2B$2A2.2B!
[[ ICONS ]]
@RULE IconDemo2
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 96 96 96
1 255 0 0
2 255 0 0
@ICONS
XPM
"7 14 2 1"
"A c #FFFFFF"
". c #000000"
"AA.A.AA"
"AA.A.AA"
"..AAA.."
"AAA.AAA"
"..AAA.."
"AA.A.AA"
"AA.A.AA"
"..A.A.."
"..A.A.."
"AA...AA"
"...AA..."
"AA...AA"
"..A.A.."
"..A.A.."

Instead of unloading everything, would it be possible to only unload the icon(s) that couldn't be parsed, potentially replacing them with a placeholder "error" icon, perhaps like the one shown here (preferably it would be 2^n pixels to an edge rather than (2^n)-1, i.e. the size of a full cell), to make it more clear which icon is actually broken so that I can know at an instant which one to be looking at?

Code: Select all

x = 6, y = 2, rule = IconDemo3
2A2.2B$2A2.2B!
[[ ICONS ]]
@RULE IconDemo3
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 96 96 96
1 255 0 0
2 255 0 0
@ICONS
XPM
"7 14 4 1"
"A c #FF0000"
"B c #FF00FF"
"G c #000100"
". c #000000"
"AA.A.AA"
"AA.A.AA"
"..AAA.."
"AAA.AAA"
"..AAA.."
"AA.A.AA"
"AA.A.AA"
"GGGGBBB"
"GGGGBBB"
"GGGGBBB"
"GGGGBBB"
"BBBBGGG"
"BBBBGGG"
"BBBBGGG"

Besides that suggestion: I've noticed that when zooming out beyond 16.0 on the third example above, the transparent areas on the left icon become black. This doesn't happen for the first example. Is this a bug?

[muzik]

Here's a possibly interesting benchmarking oscillator:

Code: Select all

x = 7, y = 6, rule = M0,4,1,10,8,3,9,11,2,6,12,14,5,7,13,15
3bo$o3bo$5b2o$bo$4bo$3bo!
[[ SHADER Basic THEME Mono AUTOIDENTIFY SHOWGENSTATS SHOWTIMING EXTENDEDTIMING ZOOM 4 ]]

In Pro, this takes 11.3 seconds for period recognition and 43.5 seconds to compute statistics, for a total of 54.7 seconds to complete identification. In the standard engine, it takes 14.4 seconds for period recognition and 15.3 seconds for statistics for a total of 29.7 seconds (strict volatility and maps are not computed). No idea if statistics calculation can be improved at all since this is just a very high period oscillator with a relatively large bounding box, with both presumably adding up; the aforementioned optimization for reversible rules would presumably only affect the period recognition range of the process.

On the topic of LifeViewer Pro and the new crash detection: when LifeViewer runs out of memory, would it make sense to show an error screen in that case as well, rather than refreshing the entire browser tab (possibly causing data loss in the process)? Obviously future changes to the memory allocator would make this less of an issue, but I'd rather have this fallback over having pattern data wiped out by a rogue forced F5 in the meantime and if there are any future blips.

An amusing detail: for a Generations pattern, if we set HISTORYSTATES to 0, the shader listed in Help > Info > Cells will still be "Cell Age". Only if we also set AGESTATES to 0 (despite AGESTATES meaning nothing in this rulespace) will it then say "Basic". I don't know if this line should even exist for non-2-state rulespaces given that shaders fundamentally aren't supported.

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!
[[ HISTORYSTATES 0 ]]

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!
[[ AGESTATES 0 ]]

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!
[[ HISTORYSTATES 0 AGESTATES 0 ]]

Applying certain themes also gets us "Basic" rather than "Cell Age":

Code: Select all

x = 24, y = 25, rule = R6,C5,M1,S59..62,B12..17,NN
5$16.D$8.D$9.D6.2D$6.D12.D$5.C3DB6.B3D$5.2C12DC$5.2CB8D2B2C$6.2C4A7CB
$5.2B11C2B$5.6B2C4.2BA$5.2AB.9B2A$6.2A2.2A4B4A$7.12A$10.3A!
[[ THEME Mono ]]

On the topic of counterintuitive help entries: hexagonal and triangular grids do not support major grid lines, but there's still "Major Color" and "Interval" lines in Help > Info > Gridlines:

Code: Select all

x = 17, y = 7, rule = B2/S34LO
12bobobo$7bo7bo$10bobo2$4bobo3bo$bo$4bo!

Code: Select all

x = 7, y = 8, rule = B2/S34H
2bo$4bo$2bo3bo$2bo$3bo$o2bo$bo$3bo!

For bounded grids, can Settings > Playback > AutoFit History be grayed out? It serves no purpose; under normal functionality, history cells can never exist outwith the grid boundaries.

Code: Select all

x = 5, y = 4, rule = B3/S23:T32,32+3
bo2bo$o$o3bo$4o!

[muzik]

For an embed height of 480, Help buttons end up touching the text at the top and intersecting the buttons at the bottom:

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ HEIGHT 480 GRID LABEL 0.5 -1.5 32 "HERE'S SOME TEXT" ]]

For 479, they get clustered at the top, when they could easily be vertically centered or spread out instead:

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ HEIGHT 479 GRID LABEL 0.5 -1.5 32 "HERE'S SOME TEXT" ]]

Since Settings looks fine for a height of 480, I wonder if the button could be un-disabled for some values below 480.

In this pattern, there are many dead cells which are visible in rectangular cells view or when zoomed out, but are completely invisible as hexagons, which is incorrect.

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM 4 STARTFROM 255 X 64 THEME Book ]]

This pattern will crash LifeViewer if allowed to run to somewhere roughly under 900 generations:

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!
[[ MAXGRIDSIZE 9 KILLGLIDERS ZOOM -1 ]]

This is an extremely minor thing to point out, but the second pattern on this page does not "fail" anymore: https://lazyslug.com/lifeview/plugin/wolfram.html

[muzik]

In this pattern, KILLGLIDERS quickly gives up on actually killing any of the many escaping gliders.

Code: Select all

x = 269, y = 44, rule = B2i3-cky4e5c6n7c/S2-n3-ce4cy5jkr6ik
176bo$175bobo$178bo$176bo2$2o65b2o83b2o21b2o65b2o$b2o65b2o83b2o88b2o$b
o66bo84bo89bo24bo$266b3o$267bo$177b2o$177bobo$179bo$177bo$171b2o2b2o$
172b2o$172b3o$175bo$174bo8bo$175b2o2b3obo$177bo$173bob2o5bo$173b2obobo
b2o$165bo9bo$164b3o$165bo2$157b3o$156b2o2bo$156b5o80bo$157bo82b3o$90bo
66bo4bo77bo24bo$89b2o66bo4bo101b2o$90b2o67b2o104b2o$152b2o$151bo2bo3bo
$151bob2o3bobo$152b2o2bo3b3ob3o$156b4ob2ob3o$155bo9bo$156b2o7bo$157bo
7bo$165b2obo$168b2o!
[[ AUTOSTART KILLGLIDERS STEP 64 ZOOM 1 ]]

Seems like every time we fix an erroneous kill case, a new escaping gliders not being killed case occurs (or returns), or vice versa. I genuinely wonder if it'd be worth putting together a set of unit tests somewhere comprised of historical problem patterns. Here's a list of several:
viewtopic.php?t=7038 (several posts)
viewtopic.php?p=216849#p216849
viewtopic.php?p=209570#p209570
viewtopic.php?p=204870#p204870
viewtopic.php?p=178568#p178568
viewtopic.php?p=177789#p177789
viewtopic.php?p=159195#p159195
viewtopic.php?p=158116#p158116

There may be something wrong with either the CoordCA neighbourhood calculation for big ranges or the recognition of long CoordCA strings as valid neighbourhoods. If, for this, you Select All, then Copy Nhood:

Code: Select all

x = 99, y = 99, rule = B3/S23
o48$48b3o$48bobo$48b3o48$98bo!

you get this:

Code: Select all

800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000018000000000000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

...but actually specifying it as a neighbourhood doesn't work:

Code: Select all

x = 99, y = 99, rule = R1,C2,S2-3,B3,N@800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000018000000000000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
o48$48b3o$48bobo$48b3o48$98bo!

Another crash bug: open the first of these two patterns, then the second one while the first one is running. (Why do we get translocated to the very top of the page?)

Code: Select all

x = 10, y = 10, rule = R6,C2,S25-26,31,34,36-38,46-80,95-96,98,101-105,110-111,B47-52,56,63-71
3b5o$2b7o$b9o$4o3b3o$4o3b3o$4o3b3o$b9o$b8o$3b5o$4b3o!
[[ AUTOFIT HISTORYFIT STEP 64 AUTOSTART ]]

Code: Select all

x = 5, y = 5, rule = R1,C2,S2-3,6-9,11-15,B5,10-11,14-15,NW410104041H
3bo$ob3o$3o$bobo$b3o!
[[ AUTOFIT HISTORYFIT ]]

Are there any plans to improve crash recognition? The button behaviour is buggy, some things stick on screen, and I'd prefer being able to open further popups without refreshing the page after closing the broken popup.

@ICONS performance still seems poor on mobile Safari. I have a video on Discord of this as well - ~50fps without versus ~25fps with: https://discord.com/channels/3579222555 ... 9522120907

I assume it is intended that errors do not appear when embedded viewers have customized values for the four popup-exclusive color definitions?

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ COLOR CLOSEBACKGROUND Green ]]

[rowett]

There may be something wrong with either the CoordCA neighbourhood calculation for big ranges or the recognition of long CoordCA strings as valid neighbourhoods.

Neither. You need to specify the correct range in the rule string: R49.

Code: Select all

x = 99, y = 99, rule = R49,C2,S2-3,B3,N@800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000018000000000000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
o48$48b3o$48bobo$48b3o48$98bo!

Another crash bug: open the first of these two patterns, then the second one while the first one is running.

Fixed in build 1321, thanks!

Are there any plans to improve crash recognition? The button behaviour is buggy, some things stick on screen, and I'd prefer being able to open further popups without refreshing the page after closing the broken popup.

No, I intend to fix the crashes.

LifeViewer is in an unknown state following a crash so I can't guarantee that futher popups will work until a browser refresh.

I assume it is intended that errors do not appear when embedded viewers have customized values for the four popup-exclusive color definitions?

Yes.

[rowett]

Here's a possibly interesting benchmarking oscillator

Are you saying it was faster to Identify in Standard?

when LifeViewer runs out of memory, would it make sense to show an error screen in that case as well, rather than refreshing the entire browser tab (possibly causing data loss in the process)?

Depends on what ran out of memory. If the browser ran out of memory (typically on mobile devices) then it refreshes automatically and LifeViewer isn't notified.

[muzik]

Here's a possibly interesting benchmarking oscillator

Are you saying it was faster to Identify in Standard?

It is, but that's due to further statistics not being computed in Standard due to memory constraints.

Are there any good ways to speed up the statistics phase or reduce its memory impact? For one, this oscillator has 90-degree temporal rotation symmetry, so I wonder (assuming such an optimization hasn't already been implemented) if it'd be a good idea to only compute per-cell volatility for a quarter of the pattern, since the other three quarters will necessarily be duplicates of this region with a rotation around the center. This way, we obtain the same map, and can figure out the overall volatility, without having to compute this for every cell, since (I assume) we find out an oscillator's symmetry before volatility-related calculations begin.

[muzik]

Are there any plans to improve crash recognition? The button behaviour is buggy, some things stick on screen, and I'd prefer being able to open further popups without refreshing the page after closing the broken popup.

No, I intend to fix the crashes.

LifeViewer is in an unknown state following a crash so I can't guarantee that futher popups will work until a browser refresh.

What I should have clarified is that we could get rid of the buttons/sliders in the crashed phase so that none of the graphical weirdness or unexpected lack of functionality occurs. It might also be worth stating in the error message that a refresh is required for continued functionality.

There may be something wrong with either the CoordCA neighbourhood calculation for big ranges or the recognition of long CoordCA strings as valid neighbourhoods.

Neither. You need to specify the correct range in the rule string: R49.

Code: Select all

x = 99, y = 99, rule = R49,C2,S2-3,B3,N@800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000018000000000000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
o48$48b3o$48bobo$48b3o48$98bo!

If a CoordCA definition is incorrect for the specified range, could the error be made to say this first before validating birth/survival counts are in range?

Also, opening this and then the pattern below it will move to the top of the window and cause a mismatched state where the prior rule is retained but with the grid specified by the second rule; attempting playback triggers a crash.

Code: Select all

x = 99, y = 99, rule = R49,C2,S2-3,B3,N@800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000018000000000000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
o48$48b3o$48bobo$48b3o48$98bo!
[[ SHOWGENSTATS ]]

Code: Select all

x = 5, y = 5, rule = R1,C2,S2-3,6-9,11-15,B5,10-11,14-15,NW410104041H
3bo$ob3o$3o$bobo$b3o!
[[ AUTOFIT HISTORYFIT GRID ]]

The bottom pattern here has an error due to a command which no longer exists: https://lazyslug.com/lifeview/plugin/hexmap.html

In this pattern, KILLGLIDERS quickly gives up on actually killing any of the many escaping gliders.

The following is a minimal case:

Code: Select all

x = 116, y = 132, rule = B2i3-cky4e5c6n7c/S2-n3-ce4cy5jkr6ik
114b2o$113b2o$115bo41$67b2o$66b2o$68bo19$4bo$3b2o$3bobo63$b2o$2o$2bo!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

[muzik]

Another crash bug: open the first of these two patterns, then the second one while the first one is running. (Why do we get translocated to the very top of the page?)

Code: Select all

x = 10, y = 10, rule = R6,C2,S25-26,31,34,36-38,46-80,95-96,98,101-105,110-111,B47-52,56,63-71
3b5o$2b7o$b9o$4o3b3o$4o3b3o$4o3b3o$b9o$b8o$3b5o$4b3o!
[[ AUTOFIT HISTORYFIT STEP 64 AUTOSTART ]]

Code: Select all

x = 5, y = 5, rule = R1,C2,S2-3,6-9,11-15,B5,10-11,14-15,NW410104041H
3bo$ob3o$3o$bobo$b3o!
[[ AUTOFIT HISTORYFIT ]]

This crash still appears to happen after build 1321 although it isn't a 100% certainty like it used to be: try rapidly clicking the show in viewer links back and forth. I may need to get this on multiple devices to see if it isn't a browser issue.

Another bug that only sometimes happens: using the draw tool to scrawl a bunch of randomness over this, and then using Select All, sometimes places the selection rectangle in the wrong place. Try this about twenty times or so, perhaps changing the window size each time; there's roughly a 5% chance or so that it happens.

Code: Select all

x = 154, y = 158, rule = R83,C0,M1,S7466..12736,B7466..9881,NM
59b36o$54b47o$51b53o$49b57o$47b61o$45b64o$44b67o$42b70o$41b72o$40b75o$
39b77o$38b79o$37b81o$36b83o$35b84o$34b86o$34b87o$33b89o$32b90o$31b92o$
31b93o$30b95o$29b96o$29b97o$28b98o$28b99o$27b101o$26b102o$26b103o$25b
104o$25b105o$25b105o$24b106o$24b107o$23b108o$23b109o$22b110o$22b111o$
21b112o$21b113o$21b113o$20b115o$20b115o$19b117o$19b117o$18b118o$18b
119o$17b120o$17b121o$17b121o$16b122o$16b123o$16b123o$15b124o$15b125o$
15b125o$14b126o$14b127o$14b127o$13b128o$13b129o$13b129o$12b131o$12b
131o$11b133o$11b133o$10b135o$9b58o21b58o$8b56o26b56o$8b54o30b55o$7b54o
33b54o$6b53o36b53o$6b52o39b52o$5b52o41b52o$5b51o43b51o$4b51o45b51o$3b
51o47b50o$3b50o49b50o$3b49o50b50o$2b50o51b50o$2b49o53b49o$b50o53b49o$b
49o55b49o$b49o55b49o$b48o56b49o$49o56b49o$49o56b49o$49o56b49o$49o56b
49o$49o56b49o$49o56b49o$49o56b49o$49o56b49o$49o56b49o$49o56b49o$b48o
56b49o$b48o57b48o$b48o57b47o$2b47o57b47o$2b47o57b46o$3b46o57b46o$3b46o
57b45o$4b45o57b45o$5b44o57b44o$5b44o57b44o$6b43o57b43o$7b41o58b42o$7b
41o58b42o$8b40o58b41o$9b39o58b40o$10b38o58b39o$10b38o58b39o$11b37o58b
38o$12b36o58b37o$13b35o58b36o$14b34o58b35o$15b33o58b34o$16b32o58b33o$
17b31o58b32o$18b30o58b31o$19b29o58b30o$20b28o58b29o$21b27o58b28o$22b
26o58b27o$23b25o58b26o$23b25o58b25o$24b24o58b24o$25b23o58b24o$26b23o
56b24o$26b24o54b24o$27b25o51b24o$28b25o48b26o$29b26o45b26o$30b27o41b
27o$31b27o38b28o$32b29o33b29o$32b31o28b31o$33b34o21b33o$34b86o$35b84o$
37b81o$38b79o$39b77o$40b75o$41b72o$43b69o$44b67o$46b63o$47b61o$49b57o$
50b54o$52b50o$54b46o$56b42o$59b37o$61b32o$65b25o$69b16o!
[[ ZOOM -20 ]]

IMG_1094.jpeg (419.8 KiB) Viewed 917 times

There is a visual mismatch in these if you toggle Use Rectangles or zoom out - history cells are drawn in rectangular view that are not visible at all (besides one) in triangular or hexagonal view.

Code: Select all

x = 1, y = 1, rule = B/SL
!
[[ PASTEMODE XOR AUTOSTART GPS 16 ZOOM 4
PASTET EVERY 4 0 PASTEDELTA 2 0 PASTE o! 0 0 PASTE o! 0 0
PASTET EVERY 4 1 PASTEDELTA 2 0 PASTE o! 0 1 PASTE o! 0 1
PASTET EVERY 4 2 PASTEDELTA 2 0 PASTE o! 1 1 PASTE o! 1 1
PASTET EVERY 4 3 PASTEDELTA 2 0 PASTE o! 1 0 PASTE o! 1 0
]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ PASTEMODE XOR AUTOSTART GPS 16 ZOOM 4
PASTET EVERY 4 0 PASTEDELTA 2 0 PASTE o! 0 0 PASTE o! 0 0
PASTET EVERY 4 1 PASTEDELTA 2 0 PASTE o! 0 1 PASTE o! 0 1
PASTET EVERY 4 2 PASTEDELTA 2 0 PASTE o! 1 1 PASTE o! 1 1
PASTET EVERY 4 3 PASTEDELTA 2 0 PASTE o! 1 0 PASTE o! 1 0
]]

[muzik]

The hotkey mentioned on this page does not cause an image to appear on the page itself as it says it will: https://lazyslug.com/lifeview/plugin/warp.html

Embedded viewers with a height of 480 will have the Back and CUSTOM buttons intersecting other user interface buttons in the theme selection menu:

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ HEIGHT 480 ]]

A suggestion: could the 1x playback speed button be made a part of the slider, specifically acting as the dead zone, such that we can get a slider that's a bit more wide than currently?

Code: Select all

x = 33, y = 9, rule = B3/S23
33o$o12bo5bo12bo$o12bo5bo12bo$o12bo5bo12bo$o12bo5bo12bo$o12bo5bo12bo$
o12bo5bo12bo$o12bo5bo12bo$33o!
[[ ZOOM 16 LABEL 16 4 8 "1x" LABEL 6.5 4 8 "60gps" ]]

If HISTORYFIT and KILLGLIDERS are both active, things will work fine until a glider gets killed, after which HISTORYFIT is disregarded and we only take currently alive cells into consideration.

Code: Select all

x = 8, y = 2, rule = B3/S23
3o3b2o$bo5bo!
[[ AUTOSTART AUTOFIT HISTORYFIT KILLGLIDERS PASTET 200 PASTE 9bo$9bobo$9b2o14$2o$2o! 40 40 ]]

Same pattern in the general range algorithm, where something a bit different happens: after the PASTE command, we then ignore all preceding history and focus on what was pasted (but the zoom doesn't change after the glider is killed):

Code: Select all

x = 8, y = 2, rule = R1,C2,S2-3,B3
3o3b2o$bo5bo!
[[ AUTOSTART AUTOFIT HISTORYFIT KILLGLIDERS PASTET 200 PASTE 9bo$9bobo$9b2o14$2o$2o! 40 40 ]]

Here's another range-1/general-range comparison - range-1 works correctly whereas general-range starts ignoring things after the first paste:

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 AUTOSTART AUTOFIT HISTORYFIT PASTET 576 PASTE 6o! 20 20 ]]

Code: Select all

x = 5, y = 4, rule = R1,C2,S2-3,B3
bo2bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 AUTOSTART AUTOFIT HISTORYFIT PASTET 576 PASTE 6o! 20 20 ]]

Neither of these two patterns can be played at all (possible missing MAXGRIDSIZE 14?):
https://lazyslug.com/lifeview/plugin/happy.html
https://lazyslug.com/lifeview/plugin/veryhappy.html

In Help > Comments, while normal comments are wrapped, name and originator fields are not and will go offscreen.

Code: Select all

#N Of course, in real life, no pattern would be given a ridiculously long name such as this, but it's important to make sure all potential problem cases are covered, is that not correct?
#O Adolph Blaine Charles David Earl Frederick Gerald Hubert Irvin John Kenneth Lloyd Martin Nero Oliver Paul Quincy Randolph Sherman Thomas Uncas Victor William Xerxes Yancy Zeus Wolfeschlegel­steinhausen­bergerdorff­welche­vor­altern­waren­gewissenhaft­schafers­wessen­schafe­waren­wohl­gepflege­und­sorgfaltigkeit­beschutzen­vor­angreifen­durch­ihr­raubgierig­feinde­welche­vor­altern­zwolfhundert­tausend­jahres­voran­die­erscheinen­von­der­erste­erdemensch­der­raumschiff­genacht­mit­tungstein­und­sieben­iridium­elektrisch­motors­gebrauch­licht­als­sein­ursprung­von­kraft­gestart­sein­lange­fahrt­hinzwischen­sternartig­raum­auf­der­suchen­nachbarschaft­der­stern­welche­gehabt­bewohnbar­planeten­kreise­drehen­sich­und­wohin­der­neue­rasse­von­verstandig­menschlichkeit­konnte­fortpflanzen­und­sich­erfreuen­an­lebenslanglich­freude­und­ruhe­mit­nicht­ein­furcht­vor­angreifen­vor­anderer­intelligent­geschopfs­von­hinzwischen­sternartig­raum Sr.
#C Here is an example of a very long comment, all of which is placed on a single line; comment lines such as this are wrapped automatically as one may expect, which is in contrast to what is seen for the above two cases.
x = 3, y = 2, rule = B2ce/S1c3n
obo$2o!

Since there's no page that uses it anymore, should lv-plugin-no-opt.js be moved into the "/previous" directory?

Most buttons for viewing Identify results are completely inaccessible in the following state. Pressing E twice also shows that the period key background is much larger than it needs to be to contain only one element.

Code: Select all

x = 40, y = 22, rule = B2n3aeijy4ci5cr6n/S2aek3-acek4eiknr5ir6eik7e
38bo$38b2o$39bo5$31b2o$31b2o5$31b3o$31b3o2$28b3o$2o2bo23bo2bo$o27b2o2b
2o$2obo26bo2bo$b3o26b3o$2bo!
[[ AUTOIDENTIFY COLOR UIBACKGROUND Blue WIDTH 480 HEIGHT 240 ]]

[muzik]

Hash collisions still appear to occur in Identify for some multistate patterns - here's one that gets identified as period-29319 after around 24.5 million generations:

Code: Select all

x = 9, y = 7, rule = SlowSpeeds
B8A$B8A$B8A$B8A$B8A$B8A$B8A!

Code: Select all

# 24 millionth generation for convenience
x = 9, y = 7, rule = SlowSpeeds
B8A$AC7A$C8A$6AB2A$7ACA$6AB2A$6AB2A!

This is identified as period-154 after 109 million or so generations:

Code: Select all

x = 10, y = 7, rule = SlowSpeeds
B9A$B9A$B9A$B9A$B9A$B9A$B9A!
[[ NOSTEPBACK ]]

Unsure what is the cause of this, but specifically when using Identify in LifeViewer Pro on iPad, playback will sometimes freeze for around half a second at a time.

Could be a number of things. Probably garbage collection. Try again with [[ NOSTEPBACK ]] and [[ NOGRAPH ]] and see if you still get the pauses.

[[ NOSTEPBACK ]] may have made these less of a problem in this context but it hasn't gone away entirely.

[muzik]

Commands show up in the Help > Comments of the first pattern on this page: https://lazyslug.com/lifeview/plugin/rlesnippet.html

There are also errors at the bottom of this page.

Cutting and pasting the top cell onto the bottom cell and pressing Play will cause the top cell to flicker in and out of existence even though it should no longer exist in that position:

Code: Select all

x = 1, y = 6, rule = PCA_4
A5$B!

In Help > Info > Identify, off deathforcer cells are listed as period negative one with an undefined count and NaN percentage rather than by their actual name and omitting these last two values as one would expect. There is also no square for Back even though there should be.

Code: Select all

x = 3, y = 3, rule = LifeHistory
2.F$A$2A!
[[ AUTOIDENTIFY ]]

There is a limit on how close to the edge of the grid a pattern can be placed via CXRLE which is enforced for the X-axis, but not the Y-axis. Observe:

Code: Select all

#CXRLE Pos=-239,-239
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 GRID ]]

Code: Select all

#CXRLE Pos=-240,-239
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 GRID ]]

Code: Select all

#CXRLE Pos=-239,-240
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 GRID ]]

Here it is at the positive-positive quadrant:

Code: Select all

#CXRLE Pos=239,239
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X 255 Y 255 GRID ]]

Code: Select all

#CXRLE Pos=240,239
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X 255 Y 255 GRID ]]

Code: Select all

#CXRLE Pos=239,240
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X 255 Y 255 GRID ]]

Cell placed off the board (note the lack of "New pattern"):

Code: Select all

#CXRLE Pos=-239,-257
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 GRID ]]

KILLGLIDERS ignores these:

Code: Select all

x = 6, y = 7, rule = B3/S23
2bo$obo$b2o2$5bo$3bobo$4b2o!
[[ KILLGLIDERS ]]

There are errors on this page: https://lazyslug.com/lifeview/plugin/jvncheat.html

Identify fails to work on this small spaceship:

Code: Select all

x = 1, y = 1, rule = M0,4,1,0,1,0,0,0,8,0,0,0,0,0,0,0
o!
[[ AUTOIDENTIFY ]]

In this pattern, only the four cells from (-1,-1) to (0,0) can be edited:

Code: Select all

x = 1, y = 1, rule = R127,C2,S,B
!
[[ GRID ZOOM 64 MAXGRIDSIZE 9 ]]

I understand it's incredibly rude of me to reiterate this once again, but as it's now been six months, can the pull requests I've submitted be checked? In particular, this one only changes three lines, and this one only adds ten.

[muzik]

Performance benchmark with a glider crossing the diagonal of a torus (but always at a distance from the edges).

Code: Select all

#CXRLE Pos=-3500,-3500
x = 3, y = 3, rule = B3/S23:T8000,8000
2bo$obo$b2o!
[[ SHOWTIMING EXTENDEDTIMING STARTFROM 28000b ]]

Code: Select all

#CXRLE Pos=-3500,-3500
x = 3, y = 3, rule = R1,C2,S2-3,B3:T8000,8000
2bo$obo$b2o!
[[ SHOWTIMING EXTENDEDTIMING STARTFROM 28000b ]]

Results:

Code: Select all

range-1 algorithm, standard engine:
36.7s / 762.2gps
35.2s / 796.1gps
35.1s / 797.4gps
35.3s / 792.2gps
33.9s / 825.3gps

general-range algorithm, standard engine:
23.1s / 1213.8gps
24.4s / 1149.7gps
27.5s / 1018.8gps
25.8s / 1085.5gps
25.0s / 1118.6gps

range-1 algorithm, WASM engine:
20.7s / 1350.8gps
20.5s / 1366.4gps
20.4s / 1372.5gps
20.2s / 1383.4gps
20.8s / 1348.7gps

general-range algorithm, WASM engine:
4.4s / 6392.7gps
5.1s / 5515.1gps
4.8s / 5821.2gps
4.9s / 5683.0gps
4.5s / 6283.7gps

The general-range algorithm beats the range-1 algorithm by a very significant margin regardless of engine. I'm not sure if the latter could be optimized somehow to match or exceed it for cases such as these.

On this page, the Fireworks, Fireworks 2 and second Puffer (which is a Star Wars pattern - is it misnamed?) patterns have what appear to be technical hash-prefixed data displayed in Comments, and the actual comments (#D) have the D displayed in comments as well, which doesn't happen with #C in most patterns. This is inconsistent, but is it intended?: https://lazyslug.com/lifeview/plugin/generations.html

In popup viewers, the positions of major grid lines appear to shift considerably if the size of the popup changes. Here's a video of that I posted in discord: https://discord.com/channels/3579222555 ... 3235177522

This will presumably vary based on browser, but if we open this, then use the change rule dialog to add a bounded grid e.g. P3, the popup may appear in a glitched state for a split second with overlapping buttons:

Code: Select all

x = 1, y = 1, rule = LifeRLB0
o!

IMG_1237.jpeg (634.81 KiB) Viewed 758 times

If the display is tilted, mousing over a cell will show the wrong coordinates in the bottom-left cell coordinate indicator, as though the display was not actually in a tilted state:

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ GRID TILT 1 ]]

Much like the aforementioned KILLGLIDERS case, pasting in a way that removes cells can cause HISTORYFIT to be disregarded. This only seems to happen when the bounding box would change. Compare the following - the first works correctly but the second exhibits the unwanted buggy behaviour:

Code: Select all

x = 125, y = 9, rule = B3/S23
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -27 1 ]]

Code: Select all

x = 125, y = 9, rule = B3/S23
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -21 1 ]]

Comparison with the general-range algorithm, in which case both of them actually function correctly this time:

Code: Select all

x = 125, y = 9, rule = R1,C2,S2-3,B3
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -27 1 ]]

Code: Select all

x = 125, y = 9, rule = R1,C2,S2-3,B3
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -21 1 ]]