Pattern viewer for forum threads

[rowett]

Identify also seems to really struggle with this p19168. It plays out over four whole period cycles before detecting the pattern is periodic around 85k generations, and it then takes over two whole minutes (I didn't continue beyond that) to calculate data.

Identify will certainly struggle with patterns this big. The bounding box is 3278x3278 which is 10,745,284 (10 million) cells. The period is 19168 so Identify has to check 10 million cells that many times. It's not going to be quick.

On my machine it took 11.4 seconds to find the period and then 4 minutes 30 seconds for the rest of the statistics (excluding Strict Volatility).

Identify can now detect this in 43 seconds on my machine.

Code: Select all

x = 10, y = 7, rule = B2in3-ck4eyz5ny678/S3-jk4aikqrtz5ceky678
bo$6bo$2b6o$ob7o$2b8o$4b5o$7bo!

[muzik]

I just finished checking all of the ultra-high-period oscillators in the RRO thread and they all conclude in under a minute (most of them under 20 seconds). Great work!

----

Browsing through the Larger than Life thread has always brought with it a bunch of weird memory and slowdown issues for me across multiple platforms, and on iOS acts especially janky. I've managed to find reproduction steps for one new iOS-exclusive issue. Here's Dean Hickerson's slow ship post for testing purposes:

- Open the first code box and Identify the spaceship
- After it finishes, open the second code box and Identify that spaceship
- Once that second one is finished, open the third one

On iOS, when opening the third one, the opened viewer enters a glitched state: the dimensions of the viewer popup are smaller than normal, which sometimes causes buttons to be crushed into each other and overlap. In other cases, the contents of the viewer window are entirely transparent. The size issue and transparency issue may correcf themselves with scrolling. If the Identify table wasn't closed for the second spaceship, it will persist into the third (glitched) viewer popup. Also, the entire page will instantly scroll to the top for some reason.

Can you reproduce this issue on iPhone, and if so, is it fixable at all?

----

Side note: while testing this on PC, I noticed that I seem to get far higher performance with Identify on iOS now than on PC. This is probably due to my computer being close to ten years old at this point, but I'm still surprised.

[rowett]

Negative values are appearing in generation stats again.

Fixed, thanks.

[muzik]

Minor issue: for general-range patterns, some alive cells are immediately set to background cells when killed at the boundary rather than becoming historical dead cells.

Code: Select all

x = 5, y = 4, rule = R1,C2,S2-3,B3
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 SHOWGENSTATS ARROW -251 -4 -251 -0 24 ]]

In addition, two historical dead cell come into existence where there were never alive cells. This is probably just another result of the behavioural differences (it also happens with KILLGLIDERS) but I've never seen this for boundary killing in normal range-1 rules.

"Range-1" example for comparison (boundary killing works differently in this engine, but the bug isn't present)

Code: Select all

x = 5, y = 4, rule = B3/S23
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 SHOWGENSTATS ]]

Interestingly, in [R]Super, cells killed at the boundary become state-24 "hidden" cells rather than state-2 history cells:

Code: Select all

x = 5, y = 4, rule = B3/S23History
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 SHOWGENSTATS COLOR BACKGROUND 128 128 0 ]]

Code: Select all

x = 5, y = 4, rule = B3/S23Super
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 SHOWGENSTATS COLOR dead 128 128 0 ]]

I tried using COLOR BACKGROUND in the above [R]Super example to make the hidden cells clear, but it doesn't work.

Code: Select all

x = 5, y = 4, rule = B3/S23Super
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 SHOWGENSTATS COLOR BACKGROUND 128 128 0 ]]

[rowett]

Browsing through the Larger than Life thread has always brought with it a bunch of weird memory and slowdown issues for me across multiple platforms, and on iOS acts especially janky. I've managed to find reproduction steps for one new iOS-exclusive issue. Here's Dean Hickerson's slow ship post for testing purposes:

- Open the first code box and Identify the spaceship
- After it finishes, open the second code box and Identify that spaceship
- Once that second one is finished, open the third one

On iOS, when opening the third one, the opened viewer enters a glitched state: the dimensions of the viewer popup are smaller than normal, which sometimes causes buttons to be crushed into each other and overlap. In other cases, the contents of the viewer window are entirely transparent. The size issue and transparency issue may correcf themselves with scrolling. If the Identify table wasn't closed for the second spaceship, it will persist into the third (glitched) viewer popup. Also, the entire page will instantly scroll to the top for some reason.

Can you reproduce this issue on iPhone, and if so, is it fixable at all?

I couldn't reproduce it on my iPhone SE 2022. However I'm not surprised you're having problems since LtL patterns and Identify can both use a lot of RAM and typically tablets and mobile phones don't have much. If LifeViewer and/or the browser start running out of memory then you'll likely see the sort of weird things going on you mention above.

Side note: while testing this on PC, I noticed that I seem to get far higher performance with Identify on iOS now than on PC. This is probably due to my computer being close to ten years old at this point, but I'm still surprised.

My iPhone is also faster than my PC which is a surprise since my PC is only a couple of years old: AMD 3950X 16core/32thread CPU with 64Gb RAM.

On the iPhone Identify only took 28 seconds (vs 43 on the PC).

[muzik]

I've finally found an incredibly easy way to consistently reproduce the 30fps-throttling issue on iOS. Tapping the "Show in viewer" link works fine and you get a full 60fps - assuming that's the first thing you do. If you instead hold down the tap on that link (as if you were going to copy the link, open it in another tab, etc.), cancel out of that via a tap elsewhere, and then do a single tap to open up the viewer popup, the viewer can only go up to a maximum of 30 frames per second (it can exceed it for fraction-of-a-second bursts).

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ SHOWGENSTATS SHOWTIMING EXTENDEDTIMING ]]

Hopefully you can reproduce this as well, and hopefully it's fixable - this issue has been annoying me for years.

I can also point out that in this state, the "Time" parameter at the bottom left is inaccurate, since it counts up at half the speed due to the refresh rate being halved.

----

Side note: is there a reason why the x and y values for the pattern on this page are 9 and 5 while the pattern itself has a bounding box of 7x3?

[rowett]

I've finally found an incredibly easy way to consistently reproduce the 30fps-throttling issue on iOS.

Hopefully you can reproduce this as well, and hopefully it's fixable - this issue has been annoying me for years.

Yes I can reproduce it. I'm not sure it will be fixable since I have no control over the rate that the browser posts events to LifeViewer. I'll do some research.

I can also point out that in this state, the "Time" parameter at the bottom left is inaccurate, since it counts up at half the speed due to the refresh rate being halved.

Yes that's known.

Side note: is there a reason why the x and y values for the pattern on this page are 9 and 5 while the pattern itself has a bounding box of 7x3?

Yes that's some history. A long time ago I was testing Specified vs Actual pattern size.

[rowett]

My iPhone is also faster than my PC which is a surprise since my PC is only a couple of years old: AMD 3950X 16core/32thread CPU with 64Gb RAM.

On the iPhone Identify only took 28 seconds (vs 43 on the PC).

Using Chrome on the iPhone Identify was even faster... only 23 seconds. Plus none of the 30fps throttling happened.

[muzik]

Here's a bunch of completely random observations and requests:

KILLGLIDERS appears to work strangely when near the boundary of the grid. If the glider is heading in the general direction of the boundary, it isn't killed.

Code: Select all

#CXRLE Pos=-214,-0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ZOOM 4 MAXGRIDSIZE 9 KILLGLIDERS ]]

Code: Select all

#CXRLE Pos=-214,-0
x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ ZOOM 4 MAXGRIDSIZE 9 KILLGLIDERS ]]

Could the Graph size be made to only change to accommodate the currently displayed values, rather than both visible and hidden values? For example, when plotting quadratic-growth patterns, the Births and Deaths lines end up getting crushed into unreadability. I'd like to be able to see them by turning off Population.

Code: Select all

x = 1, y = 1, rule = B12345678/S012345678
o!
[[ AUTOFIT GRAPH T 0 "Turn off Population" ]]

Empty hexagonal bounded grids are not centered correctly, and are only centered right if at least one cell is present:

Code: Select all

x = 1 y = 1, rule = B/SH:T100
!
[[ GRID ZOOM 4 ]]

Code: Select all

x = 1 y = 1, rule = B/SH:T100
o!
[[ GRID ZOOM 4 ]]

For custom themes where dead cells are set to be no different from the background color, dead cells still display as raised when Layers are enabled. For Generations rules, this also affects built-in themes such as the Golly theme.

Code: Select all

x = 4, y = 2, rule = B2/S
o2bo$b2o!
[[ GRID STARTFROM 4 COLOR BACKGROUND White COLOR DEAD White COLOR DEADRAMP White LAYERS 10 ]]

Code: Select all

x = 4, y = 2, rule = G3/B2/S
o2bo$b2o!
[[ GRID STARTFROM 4 COLOR BACKGROUND White COLOR DEAD White COLOR DEADRAMP White LAYERS 10 ]]

There appears to be some sort of limit as to how close a pattern can be placed to the boundary via CXRLE. Is this intended?

Code: Select all

#CXRLE Pos=-191,0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ARROW -192 -200 -192 200 4 GRID MAXGRIDSIZE 9 ZOOM 4 ]]

Code: Select all

#CXRLE Pos=-192,0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ARROW -192 -200 -192 200 4 GRID MAXGRIDSIZE 9 ZOOM 4 ]]

Code: Select all

#CXRLE Pos=-193,0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ARROW -192 -200 -192 200 4 GRID MAXGRIDSIZE 9 ZOOM 4 ]]

Code: Select all

#CXRLE Pos=-194,0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ARROW -192 -200 -192 200 4 GRID MAXGRIDSIZE 9 ZOOM 4 ]]

Code: Select all

#CXRLE Pos=-250,0
x = 3, y = 3, rule = B3/S23
2bo$obo$b2o!
[[ ARROW -192 -200 -192 200 4 GRID MAXGRIDSIZE 9 ZOOM 4 ]]

This pattern loads up and works fine - the left and right edges are twisted like a Klein bottle would be, and they also apply a shift. However, if we use Save Pattern, the resulting pattern gives an error if we try to load it from the code box. Can this be fixed?

Code: Select all

x = 7, y = 3, rule = MAPAP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/wD/AP8A/w:K20,20-3
o3b3o$3o2bo$bo!

It's also worth noting that (at least on iOS) the above error also causes the popup viewer to shrink in the exact same way as it did for the LtL Identify memory issue I reported earlier.

Finally, when saving patterns in alternating rules on odd generations, the output pattern won't work properly since a configuration that would normally be processed by an odd generation is now being handled by an even generation. Could something be implemented to mitigate this, e.g. reversing the order of the two rules being alternated between, or setting CXRLE Gen to an odd value annd saving that with the pattern and making that affect which rule is applied?

Code: Select all

x = 4, y = 3, rule = B13/S012345678|B/S15
o2$o2bo!
[[ ZOOM 10 STEP 34 AUTOSTART STOP 681 T 680 "" T 681 "Now use Save Pattern" ]]

[rowett]

This pattern loads up and works fine - the left and right edges are twisted like a Klein bottle would be, and they also apply a shift. However, if we use Save Pattern, the resulting pattern gives an error if we try to load it from the code box.

Fixed, thanks.

[muzik]

Ever since the issues for alternating rules have been fixed, I've been wondering: could strict volatility calculation and period mapping be added for Margolus rules? Since most of the issues with it that I know of are now gone (odd-period cells are now recognised, period maps now display all active cells rather than only cells present on even generations, p2 cell handling) it seems like now is as good a time as any to implement it.

Is there any reason why it can't be (or hasn't been) added? I'd be interested to know why if so.

Here's an example pattern containing stator cells, cells that oscillate at half the period and cells that oscillate at the full period, for testing purposes. It also works in the Life-like rulespace, so what Identify outputs for Strict Volatility and the table it produces can be compared for both patterns to ensure they produce the same result.

Code: Select all

x = 3, y = 11, rule = M0,0,0,15,0,15,0,0,0,0,15,0,15,0,0,0
$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o!

Code: Select all

x = 3, y = 11, rule = B3/S5
$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o$b2o!

[muzik]

I've been considering for a while treating bounded grids as one entity. ... Interested on opinions on this topic.

This isn't inherently a LifeViewer related opinion, but if this is implemented, I think a moderator should go through the Larger than Life thread and delete all of the bounded grids from the patterns in the first months of that thread (up to the end of page 5; bounded grids in any posts after that should be kept, except for this quote post and this one, this one, and probably this post and the one below it, and maybe this too). Their presence is solely due to early builds of Golly requiring bounded grids for the then-experimental Larger than Life support, and the fact that they remain on those patterns today has three irritating side effects with LifeViewer's handling of them:

- patterns always begin completely zoomed out to accommodate the entire bounded grid, which is very unhelpful if the pattern only showcases a few small spaceships or oscillators
- some of the bounded grid definitions exceed 8192x8192, resulting in an error and making the patterns completely unrunnable in LifeViewer
- on my end at least, the performance of higher-range patterns just isn't as great with bounded grids, especially for pattern load times and Identify, and may in fact have been a major contributing factor to the memory/crash bug I reported earlier

If this Identify change is made, that would add a fourth reason as to why these patterns being on bounded grids isn't a good thing: spaceships (of which there are many in the early days of that thread) would be rendered completely unidentifiable.

I don't think that LifeViewer should change to accommodate these outdated pattern RLEs - rather, all of the old posts on that thread should be modified to showcase the patterns they intended to, and nothing more. I think that showing the entire bounded grid upon pattern load is the preferable behaviour which is disadvantageous only in very specific cases such as this.

That all aside, I'm completely up for this Identify bounded grid change. It'd solve the final remaining problem on this post, among other things.

----

A bug (and no, I don't mean the pattern type) I found while looking through that thread: LifeViewer thinks this pattern has no cells, and prevents Select All and Identify from being used on it. Deleting cells from this pattern can also be used to get a negative population. This appears to be tied to HISTORYSTATES being set to 1 for higher-range rules.

Code: Select all

x = 201, y = 203, rule = R100,C0,M1,S10350..15740,B9350..12360,NM
78b2o$75b9o$73b13o$72b17o$72b19o$74b18o$75b19o$77b19o$78b19o$79b19o$
62b3o15b19o$64b5o13b19o$68b5o4b4o4b17o$71b13o4b16o$74b12o5b15o$72b16o
7b14o$71b20o9b13o$69b25o11b12o$68b29o12b12o$67b32o14b13o$66b36o14b14o$
64b40o15b15o$63b43o16b15o$62b46o16b16o$61b49o16b17o$60b52o16b17o$59b
55o16b17o$58b58o16b17o$57b61o16b17o$56b64o16b17o$55b67o16b17o$54b74o
12b17o$53b80o9b17o$52b85o7b17o$51b89o6b17o$50b94o4b17o$48b98o4b17o$47b
102o2b17o$46b105o2b17o$45b108o2b17o$44b111ob18o$42b134o$41b136o$40b
139o$39b141o$38b143o$36b147o$35b149o$34b151o$33b153o$24bo7b155o$23b4o
4b157o$23b166o$22b32o8b128o$21b24o3b4o12b127o$20b24o5bo17b10o4b110o$
19b24o26b6o10b107o$19b23o28b3o14b106o$18b23o49b104o$17b23o52b102o$16b
23o54b102o$16b22o57b100o$15b22o60b99o$14b22o62b98o$14b22o63b98o$13b22o
66b96o$12b22o68b96o$12b21o71b94o$11b22o73b92o$10b22o76b91o$10b21o79b
89o$9b22o82b86o$8b22o85b85o$8b21o89b82o$7b22o91b80o$7b21o94b78o$6b22o
95b77o$6b21o98b76o$5b22o99b75o$5b21o102b73o$4b22o103b72o$4b22o104b71o$
3b22o106b70o$3b22o107b69o$2b23o108b68o$2b22o110b67o$2b22o111b66o$2b22o
111b66o$b22o113b65o$b22o113b65o$b22o114b64o$b22o114b64o$b22o115b63o$
22o116b63o$22o116b63o$22o117b62o$22o117b62o$22o117b62o$22o118b61o$22o
118b61o$b21o118b61o$b21o117b62o$b21o117b62o$b21o117b62o$b21o117b62o$b
21o116b63o$b21o116b63o$2b21o115b63o$2b21o114b64o$2b21o114b64o$2b21o
113b65o$2b21o113b65o$2b21o113b65o$3b21o111b66o$3b21o111b66o$3b21o110b
67o$4b20o109b68o$4b21o108b68o$4b21o107b69o$5b20o106b70o$5b21o104b71o$
6b20o103b72o$6b21o100b74o$7b20o99b74o$7b21o96b76o$8b20o94b78o$9b20o91b
80o$9b20o89b82o$10b20o86b84o$11b19o83b87o$11b20o80b88o$12b20o76b91o$
13b19o74b93o$14b19o71b94o$15b2o2b15o68b96o$20b15o9bo55b97o$21b15o6b5o
52b98o$21b15o2b10o49b99o$22b28o46b100o$23b29o13b3o26b101o$24b30o8b8o
22b103o$24b48o18b104o$25b48o14b106o$26b49o10b107o$27b51o2b112o$28b163o
$29b161o$30b159o$31b157o$32b155o$33b153o$34b151o$35b149o$36b146o$37b
144o$38b142o$39b139o$40b137o$41b134o$41b132o$42b129o$43b127o$44b124o$
45b121o$46b119o$47b116o$48b114o$49b111o$50b108o$51b106o$52b103o$53b
101o$54b98o$54b97o$55b94o$56b92o$57b59o3b27o$58b53o6b28o$59b48o8b28o$
61b43o9b28o$62b40o9b29o$63b37o9b29o$64b35o8b29o$65b32o8b29o$66b30o6b
30o$66b28o6b30o$63b2o4b23o5b31o$54bo5b2o9b20o2b32o$55b4o13b17ob33o$56b
o17b47o$76b42o$78bo2b33o$79b31o$77b30o$75b29o$73b29o$71b29o$69b29o$67b
29o$69b25o$71b21o$73b16o$75b11o!
[[ SHOWGENSTATS HISTORYSTATES 1 ]]

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ SHOWGENSTATS HISTORYSTATES 1 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
o!
[[ SHOWGENSTATS HISTORYSTATES 1 ]]

If we step the above bug (and this time I'm talking about the pattern) one generation ahead and try to identify it, it hits the border but we don't get a Life ended at message. Running it manually to that point without Identify gets us a Pause, but no Life ended at.

[rowett]

LifeViewer thinks this pattern has no cells

Fixed, thanks.

[muzik]

Identifying this appears to crash LifeViewer:

Code: Select all

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

Would it be possible to remove Bounding Box from Identify for hexagonal and triangular rules? Since we don't yet have a good concept of selection shape, this value is effectively meaningless. It can also change when the same pattern is rotated in ways that aren't possible in square grid rules.

Code: Select all

x = 11, y = 7, rule = B26/S2H
2$4b2o$3b2o$4bob2o$5b2o!

Code: Select all

x = 5, y = 4, rule = B26/S2H
obo$bobo$bobo$2b3o!

On the other hand, could direction be added for spaceships in hexagonal and triangular rules in Identify? Identify already gives all of the necessary information to calculate this. See here for demonstrations of each orthogonal/diagonal direction and what displacements they correspond to.

Identify doesn't output a density for this in Margolus.

Code: Select all

x = 3, y = 2, rule = B3/S23
b2o$b2o!

Code: Select all

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

Could multiple populations be readded for still lifes in Identify so that alternating rule p2 objects have both values tracked?

Code: Select all

x = 1, y = 1, rule = B0/S
o!

Some time-symmetric oscillators with distant fading junk still don't have their Mod properly calculated. (Due to another bug, LifeViewer now thinks this has an initial population of 0, so you'll have to manually add some extra dying junk elsewhere.)

Code: Select all

x = 15, y = 5, rule = R2,C3,S2-3,7,B4,8,N*
2.2A2$2A10.A2$2.2A9.2A!
[[ SHOWGENSTATS ]]

Could (2-state) higher-range rules also be optimised for Identify? Here's the p40894 pRNG in both rulespaces - the top is completely done in four seconds, whereas the bottom takes closer to eleven:

Code: Select all

x = 156, y = 75, rule = B3/S23
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!

Code: Select all

x = 156, y = 75, rule = R1,C2,S2-3,B3
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!

And here's some "duelling donuts" oscillators with lower periods and smaller bounding boxes than the above oscillator, which also take a bit longer to Identify than said oscillator in range-1:

Code: Select all

x = 35, y = 35, rule = R10,C2,S24-29,B72-133,NB
9bobo$6bobobobo$5bobobobobobo$4bobobobobobobo$3bobobobobobobobo$2bobobobobobobobobo$bobobobobobobobobo$2bobobobobobobobobo$bobobobobobobo2b4o$obobobobo3bob3obobo$bobobobo5bobobobo$obobobobo3bobobobobo$bobobobobobobobobobo$2bobobobobobobobobo4bobo$3bobobobobobobobobo2bobobo$2bobobo2b2obobobob2obobob3o$3bobob3obobobob2obobobobobo$4bobobobobobob2obobobo3bobo$5bob3obobob2obobobobobobobo$8bobobob2obobobobo3bobobo$9bobo4bobobobo2b2obobobo$15bobobobo3bobobobobo$14bobobobo7bobobobo$13bobobobo7bobobobo$14bobobo9bobobobo$13bobo4b2o5bobobobo$14b3obobo5bobobobobo$15bobobobobobobobobobo$16bobobobobobobobobo$17bobobobobobobobo$18bobobobobobobo$19bobobobobobo$20bobobobobo$21bobobobo$22bobobo!

Code: Select all

x = 41, y = 42, rule = R12,C0,S35-40,B102-189,NB
10bobobo$9bobobobo$6bobobobobobobo$5bobobobobobobobo$4bobobobobobobobo
bo$3bobobobobobobobobobo$2bobobobobobobobobobobo$bobobobobobobobobobob
o$2bobobobobobobobobobobo$bobobobobo5bobobob3o$obobobobo7bob3o$bobobob
o9b2o2bobo$obobobobo6bo4bobobo$bobobobo9bobobobo$obobobobo7bobobobobo$
bobobobobo2bo2bobobobobo$2bobobobob2o2bobobobobo4bobo$bobobobobobobobo
bobobob2obobobo$2bobobobobobobobobobob2obobobo3bo$3bobobobobobobobobob
2obobobob3obo$4bobobo3bobobobobo2bobobobobobobo$5bobobobobobobo2bobobo
bobo3bobobo$6bob3obobobob2obobobobobobobobobo$7bo3bobobob2obobobobobob
obobobobo$10bobobob2obobobobobobobobobobobo$11bobo4bobobobobo2b2obobob
obo$17bobobobobo2bo2bobobobobo$16bobobobobo7bobobobobo$17bobobobo9bobo
bobo$16bobobo4bo6bobobobobo$17bobo2b2o9bobobobo$20b3obo7bobobobobo$17b
3obobobo5bobobobobo$18bobobobobobobobobobobo$19bobobobobobobobobobobo$
18bobobobobobobobobobobo$19bobobobobobobobobobo$20bobobobobobobobobo$
21bobobobobobobobo$22bobobobobobobo$25bobobobo$26bobobo!

----

Thinking out loud here: I'm curious as to just how far we can push the limits of LifeViewer. Here's a simple p4194302 replicator shuttle - its period is outwith the limits of LifeViewer, but identifying it shows that it wouldn't struggle with it at all given how fast it reaches the limit:

Code: Select all

x = 54, y = 2, rule = B2ae/S
bo48bobo$o49bo2bo!

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

Code: Select all

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

[rowett]

KILLGLIDERS appears to work strangely when near the boundary of the grid. If the glider is heading in the general direction of the boundary, it isn't killed.

This is intentional. KILLGLIDERS ignores gliders that are close to, and heading for, the boundary.

Could the Graph size be made to only change to accommodate the currently displayed values, rather than both visible and hidden values? For example, when plotting quadratic-growth patterns, the Births and Deaths lines end up getting crushed into unreadability. I'd like to be able to see them by turning off Population.

Yes, done.

[rowett]

Identifying this appears to crash LifeViewer

It's not Identify, the pattern is too big. I've updated the pattern size checking.

Identify doesn't output a density for this in Margolus.

I've added Density display for Margolus rules.

Some time-symmetric oscillators with distant fading junk still don't have their Mod properly calculated.

Fixed, thanks.

Could (2-state) higher-range rules also be optimised for Identify? Here's the p40894 pRNG in both rulespaces - the top is completely done in four seconds, whereas the bottom takes closer to eleven

It's nothing to do with Identify. It's the pattern iterator. The native 2-state algo is much faster than the HROT algo.

Thinking out loud here: I'm curious as to just how far we can push the limits of LifeViewer. Here's a simple p4194302 replicator shuttle - its period is outwith the limits of LifeViewer, but identifying it shows that it wouldn't struggle with it at all given how fast it reaches the limit

It's a memory issue. The more generations searched the more memory LifeViewer needs.

[muzik]

Identifying this appears to crash LifeViewer

It's not Identify, the pattern is too big. I've updated the pattern size checking.

The extra dot was put there so that the spaceship would be placed at the expected position. I can still reproduce this issue if we manually move the spaceship to be sufficiently close to the bottom boundary. This can be done via creating a large selection rectangle whose top contains the spaceship and whose bottom is aligned to the bottom of the boundary, then flipping it vertically. If it's sufficiently close to the edge, Identify kills the viewer instead of the spaceship.

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 ]]

[rowett]

I can still reproduce this issue if we manually move the spaceship to be sufficiently close to the bottom boundary. This can be done via creating a large selection rectangle whose top contains the spaceship and whose bottom is aligned to the bottom of the boundary. If it's sufficiently close to the edge, Identify kills the viewer instead of the spaceship.

Understood. The issue is related to drawing or pasting cells to near to the boundary for a higher-range HROT pattern. It would crash by just playing the pattern. I'll fix at some stage.

[muzik]

KILLGLIDERS appears to work strangely when near the boundary of the grid. If the glider is heading in the general direction of the boundary, it isn't killed.

This is intentional. KILLGLIDERS ignores gliders that are close to, and heading for, the boundary.

Is this why the gliders stop being killed in the following pattern, or is that due to something else?

Code: Select all

x = 16, y = 16, rule = B38/S23
bob4o2b2o2bo$2b3ob3ob6o$2b4ob4o4bo$bo2bo4b3o2bo$2obob3o2b2o2bo$o8b2o2b
obo$3ob2ob4ob2o$2o2b3o5bo$2o7b2ob2o$ob5o3b6o$5bo3b6o$2b2ob2ob3ob3o$ob
2obo2b3obo$bob3ob2o2bo$3o2bob4obobo$b4o3b6o!
[[ KILLGLIDERS THEME Mono ZOOM -8 AUTOSTART STEP 64 ]]

Could the Graph

Yes, done.

A couple of other Graph thoughts:

Instead of the rightmost generation value of the graph starting in the hundreds, could it too be made to start off as a low value (preferably 1)? I find the values hard to read when only a low number of generations have elapsed.

Code: Select all

x = 10, y = 10, rule = R5,C0,M1,S34..53,B31..42,NM
3b4o$2b5o$b8o$b7o$9o$4o3b2o$4o4b2o$4o4bo$4o3b2o$3b5o!
[[ GRAPH ZOOM 8 ]]

Also, the "Generations" at the bottom of the graph will always track the amount of elapsed generations, rather than the generation specified by CXRLE or the generation of reversible patterns if playback direction changes during playback. Would it be possible to change the "Generation" text at the bottom of the graph to "Elapsed" to reflect this fact?

Code: Select all

#CXRLE Gen=-5000
x = 9, y = 10, rule = R5,C0,M1,S34..58,B34..45,NM
3b3o$2b6o$b7o$b8o$9o$4o2bobo$4o4bo$4o3b2o$b3o2b2o$3b4o!
[[ GRAPH ZOOM 4 ]]

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!
[[ GRAPH ]]

[muzik]

I've decided to try and get to the bottom of the blurry period map issue as I've since discovered more patterns which are affected by the issue. I've narrowed it down to LifeViewer popups which have a non-integer Scale value as seen in Help > Info (or at least non-1.00).

I've tested this on four devices. My home PC and mobile phone had the viewer scale set to 1.00, so I couldn't reproduce it there, however I could get it to happen on my laptop and iPad since in those cases the scale was variable. Also, since embedded viewers have their scale fixed at 1.00 I couldn't create a universal example. Here's a pattern for testing:

Code: Select all

x = 60, y = 27, rule = B2in3/S123a
2o5bo2bo15b2o$2o5bo2bo$bobo4b2o14bo4bo$2bo21bo$9b2o20bo$8bo2bo14bo4bo
$8bo2bo$28b2o$2o2$2o$3o14bo$b3obo10bo$2b2obo10bo$17bo2bo$18b2o$4bo$4b
obo$7bo$8bo16bob3obo$2o$8b2o$bo23bo5bo$2bo23bo3bo$3bobo21bobo$5bo52bo
$59bo!
[[ GRID THEME Day ]]

Check what type of period map this pattern initially produces: either one with a grid, or one with no grid. Note down the bounding box width produced by Identify. Move or redraw the small still life at the bottom right accordingly until you can find the values for width that marks the transition between a map with a grid and a map with no grid when surpassed. Assuming your popup viewer's scale is not 1.00, the widest possible period maps with grids should appear visibly blurry compared to maps which aren't as wide.

Here's the statistics I've collected from affected devices:

iPad:
Safari, landscape rotation (when browser tabs are shown):
- Size: 664x623
- Scale: 1.11
- Period map appears blurry when pattern bounding box width is 63 or 64 and height is 63 or lower

Safari, landscape rotation (without browser tabs):
- Size: 728x679
- Scale: 1.21
- Period map appears blurry when pattern bounding box width is 68, 69 or 70 and height is 69 or lower

Safari, portrait rotation:
- Size: 816x765
- Scale: 1.37
- Period map appears blurry when pattern bounding box width is between 74 and 79 inclusive and height is 78 or lower

Laptop:
Firefox, when maximised:
- Size: 688x646
- Scale: 1.15
- Period map appears blurry when pattern bounding box width is 65 or 66 and height is 65 or lower

Hopefully this is enough information to reproduce this issue. I think that for these blurry cases, the period map should be rendered without the grid, since the grid version being generated is evidently too big and is being scaled down in such a way that causes visual blur, which is unwanted. LifeViewer should ideally also switch between the grid and no-grid versions of the map if it detects that the size of the viewer has changed to push it beyond the threshold to avoid blurring in this case as well.

If anyone else is able to reproduce this issue, reply with the Size, Scale and bounding box sizes.

[muzik]

I'd like to see the above period map rendering issue resolved, but in the meantime here's some more random observations and potential issues:

Odd-numbered shifts are accepted for triangular bounded grids, which results in undefined behaviour since doing this places triangles of the same parity directly next to each other which shouldn't be possible. Only even-numbered values should be accepted for shifts.

Code: Select all

x = 3, y = 2, rule = B1/SL:T26,26
$obo!

Code: Select all

x = 3, y = 2, rule = B1/SL:T26+1,26
$obo!

Similarly, Klein bottles and cross-surfaces accept even widths across the twisted edge (which is actually the only kind of width they accept). This is also invalid for the same reason. The expected behaviour would be for LifeViewer to only accept odd widths for the twisted edge and even widths for non-twisted edges.

Code: Select all

x = 3, y = 2, rule = B1/SL:K26*,26
$obo!

LifeViewer doesn't display a "SHOW PATTERN ERROR" link here:

Code: Select all

x = 1, y = 1, rule = 
MAPARYXfhZofugWaH7oaIDogBZofuhogOiAaIDogIAAgAAWaH7oaIDogGiA6ICAAIAAaIDogIAAgACAAIAAAAAAAA
bo$o$3o!

There's also this invalid rulestring case from 2021 which should probably be accounted for and give a "SHOW PATTERN ERROR" link as well.

If we remove any of the [R]History or [R]Super even-state-number cells from a pattern consisting solely of them (drawing and clearing selections works) while that pattern is running, we get a "Life ended at" message even though there existed no life to end.

Code: Select all

x = 19, y = 5, rule = LifeHistory
3D.D3.3F.3D.3D$D3.D3.F3.D.D.D.D$D3.D3.3F.3D.2D$D3.D3.F3.D.D.D.D$3D.3D
.3F.D.D.D.D!
[[ AUTOSTART ]]

Code: Select all

x = 19, y = 5, rule = LifeHistory
3D.D3.3F.3D.3D$D3.D3.F3.D.D.D.D$D3.D3.3F.3D.2D$D3.D3.F3.D.D.D.D$3D.3D
.3F.D.D.D.D!
[[ AUTOSTART ]]

For patterns with script errors, pressing the Settings button will cause the darkened background to get even darker, as if a second is being layered on top of the first. Although, come to think of it, why do we even need to click Settings to access the Esc button - couldn't it be made to be always present when script errors are being displayed?

Code: Select all

x = 5, y = 3, rule = B3/S23
5o$o3bo$5o!
[[ COLOR BACKGROUND White COLOR gimmeanerror 256 256 256 ]]

When the cursor is outside of the LifeViewer window and the T menu is open, could the "cell state at cursor position" box at the bottom left say this? Since the background is usually black, it often looks like there's a giant gap between the Gen and Time statistics and the buttons below them if the cursor is outside of the viewer.

Code: Select all

x = 5, y = 3, rule = B3/S23
5o$o3bo$5o!
[[ COLOR BACKGROUND White SHOWGENSTATS ]]

When the viewer is currently being throttled, the "actual" generations per second value is displayed inside of the slider. Could the "actual" generations per second also be displayed in the slider when Go To Gen or Identify are in use, since it's often going to be a considerably different value from what the slider is set to?

For weighted hexagonal rules, the rule information in Help > Pattern is wrong: in the rulestring, one of the first zeros is missing and there's an extra lowercase h at the end. The neighbourhood information below that is similarly incorrect. If we save this pattern from inside the viewer and try to open the code box, we get errors again like with that shifted Klein case from yesterday.

Code: Select all

x = 7, y = 9, rule = R2,C2,S20-36,B13,21,33,43,NW0001000000010a0a0100000a000a0000010a0a010000000100H
2bo$2b2o$3bobo$2bo2b2o$5bo$o4b2o$bo$b2o$2bo!

And finally, if a pattern is modified via drawing, via modifying a selection or other means, the initial population value for Graph will not change to match the actual initial population.

Code: Select all

x = 20, y = 20, rule = B3/S23
20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$20o$
20o$20o$20o!

Thank you once more for all of the fixes so far!

[wirehead]

I actually have an idea that might be useful:

When Life Viewer is used on conwaylife.com, it could use the forum search feature to grab the list of threads in the OCA forum and look through them for rule names. The vast majority of them are named with the syntax "Name (Hensel string)" and LifeViewer could just look for that. Than Chris wouldn't have to constantly be adding new rule aliases for all the new named rules.

As to the implementation of getting the forum list of topics, I really don't know how and because of CORS issues it's not something I can prototype.

[rowett]

Is this why the gliders stop being killed in the following pattern, or is that due to something else?

No, that was due to a detection edge case that has now been fixed.

[rowett]

I've decided to try and get to the bottom of the blurry period map issue as I've since discovered more patterns which are affected by the issue.

The "blurry" map is an artifact of image scaling. If you want a non-blurry one just click the download button.

[rowett]

Odd-numbered shifts are accepted for triangular bounded grids, which results in undefined behaviour since doing this places triangles of the same parity directly next to each other which shouldn't be possible. Only even-numbered values should be accepted for shifts.

Fixed, thanks.

Similarly, Klein bottles and cross-surfaces accept even widths across the twisted edge (which is actually the only kind of width they accept). This is also invalid for the same reason. The expected behaviour would be for LifeViewer to only accept odd widths for the twisted edge and even widths for non-twisted edges.

I'm not going to fix this. Triangular and Hex patterns don't really work well with square bounded grids so I may just disable these Bounded Grid types.

LifeViewer doesn't display a "SHOW PATTERN ERROR" link here

Fixed, thanks.

For patterns with script errors, pressing the Settings button will cause the darkened background to get even darker, as if a second is being layered on top of the first. Although, come to think of it, why do we even need to click Settings to access the Esc button - couldn't it be made to be always present when script errors are being displayed?

Done, thanks.

For weighted hexagonal rules, the rule information in Help > Pattern is wrong

Fixed, thanks.

And finally, if a pattern is modified via drawing, via modifying a selection or other means, the initial population value for Graph will not change to match the actual initial population.

Fixed, thanks.