Pattern viewer for forum threads

[muzik]

Identify used on the following spaceship has it hit the border, but no "Life ended at" message is displayed and the "Identifying..." text persists. Also, for some reason, all of the historical dead cells end up being wiped after the pattern dies, both in normal playback and when using Identify.

Additionally, after doing the above, if we close the viewer, open it again and zoom all the way out of this pattern and play it, the UI sometimes ends up disappearing and then the viewer crashes. If we close the crashed viewer window and then open another one, it begins advanced a generation or so (I've seen this behaviour with many other crashes).

A third thing to note: if we continue playing this pattern after all cells die, it seems strangely laggy. I suspect that this is due to the few historical dead cells that do exist being processed while in or near the boundary kill zone, causing them to be repeatedly checked for killing.

Code: Select all

x = 1495, y = 1992, rule = R498,C3,M1,S8649..8649,B499..499,NM
498.499A498$498.499B$A497.499B497.A$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.
499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$498.499B$
498.499B$498.499B$498.499B$498.499B$498.499B2$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.
497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B
.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$
497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.B.497B.B$497.
B.497B.B$A496.B.497B.B496.A$497.B499.B249$.A1491.A83$2.A1489.A83$5.A
1483.A77$82.A1329.A3$165.A1163.A$248.A997.A$497.2A497.2A!
[[ THEME Red SHOWTIMING EXTENDEDTIMING ]]

Also, in this example from earlier, there is a gap that can be seen below this oscillator at T=1: there exists a cell which remains in the background color despite the fact that cells above it and below it become historical dead cells.

Code: Select all

x = 101, y = 1, rule = R50,C2,S100,B101
101o!
[[ MAXGRIDSIZE 9 ]]

----

I've also been experiencing frequent crashes/viewer bugs much like the "slow ship Identify" issue I reported earlier (as mentioned before, the removal of many bounded grids from the Larger than Life thread made this no longer a problem). Are there any in-viewer statistics or tools I can use to monitor memory usage to identify potential memory leaks, areas for optimization and other such things so that I can figure out reliable reproduction steps for certain issues as well as experiment with viewer performance and handling under different environments as to procure information which may be useful for resolving such issues?

For example, upon loading the page, opening the first of the three following patterns, Identifying it, then opening the second of the three and Identifying it as well will cause opening of the third pattern to do the "jumping to the top of the page with a buggy shrunken viewer window" thing. I've been able to reproduce this on my iPad, laptop and phone, so there's a good chance it'll happen on other devices, but I can't guarantee it will for every possible one out there, but if I can track what exactly is causing it I might be able to trigger it in some other environments so you have a usable test case.

Code: Select all

x = 9, y = 13, rule = LifeHistory
2.2A$2.A2.A$3.3A2$.7A$A7.A$A.A3.A.A$.2A.F.2A2$.2A3.2A$.A5.A$3.A.A$2.
2A.2A!

Code: Select all

x = 8, y = 11, rule = LifeHistory
3.2A$3.2A2$.6A$A6.A$2A.F.A.A$3.D.2A$3.D$3.4A$2.A3.A$2.2A!

Code: Select all

x = 11, y = 11, rule = LifeHistory
3.2A$3.A2.A$4.3A2$2.7A$.A7.A$.A.A3.A.A$2.2A.F.2A2$4A3.4A$A2.A3.A2.A!

----

Further testing of boundary killing with Generations patterns for range-1 and general-range has turned up some interesting differences. The following patterns are the same pattern in the same rule in two different rulespaces. Along with the generation everything dies at being different (probably not worth "fixing") and all of the historical dead cells being wiped, the "dying" cells are also wiped for general-range rules, and we get a negative amount of alive cells for the general-range pattern as well. Identify on the bottom pattern gets us much the same issue as the first pattern in this post.

Code: Select all

x = 11, y = 2, rule = /2/16
4.GFEDCBA$4.GFEDCBA!
[[ SHOWGENSTATS MAXGRIDSIZE 9 STARTFROM 248 X 240 ZOOM 16 ]]

Code: Select all

x = 11, y = 2, rule = R1,C16,S,B2
4.GFEDCBA$4.GFEDCBA!
[[ SHOWGENSTATS MAXGRIDSIZE 9 STARTFROM 248 X 240 ZOOM 16 ]]

If we start from an earlier generation and Identify the pattern, the general-range spaceship has a very interesting maximum population and heat. The bounding boxes also differ.

Code: Select all

x = 11, y = 2, rule = /2/16
4.GFEDCBA$4.GFEDCBA!
[[ SHOWGENSTATS MAXGRIDSIZE 9 STARTFROM 245 X 240 ZOOM 16 ]]

Code: Select all

x = 11, y = 2, rule = R1,C16,S,B2
4.GFEDCBA$4.GFEDCBA!
[[ SHOWGENSTATS MAXGRIDSIZE 9 STARTFROM 245 X 240 ZOOM 16 ]]

Similarly strange bounding box sizes can be seen when patterns hit plane boundaries and die like in the following pattern when identified.

Code: Select all

x = 0, y = 60, rule = PCA_1:P16,64
9o!
[[ STARTFROM 58 ]]

[rowett]

Identify used on the following spaceship has it hit the border, but no "Life ended at" message is displayed and the "Identifying..." text persists.

It’s likely that this and similar reports are caused by patterns dying after period detection in the analysis phase. This will be fixed by the refactor when you’ll also be able to cancel analysis.

Regarding bounding box issues there is a backlog item awaiting implementation to make them consistent across rule families (including HistoryFit and State1Fit, thought the latter will probably become AliveFit to accommodate [R]Super and [R]History).

However none of this will happen this week since I’ll be away.

[muzik]

The only other way I know of to get Identify to spit out false results for spaceships and the like is via using paste commands to add in cells once it's sure it has a spaceship. Since paste commands aren't supported for Identify this probably won't be fixed, but I've decided it's probably worth making a note of anyway for completion's sake (as well as another demonstration of why PASTE in Identify won't be supported).

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ RLE hugecube 9o$9o$9o$9o$9o$9o$9o$9o$9o! PASTET 13 PASTE hugecube 120 120 ]]

A bug I found while testing the above: if we advance the pattern by 4 generations before identifying it, and while it's "Identifying..." we click "SHOW IN VIEWER" again, the viewer enters a glitched state (the popup eats a lemon and the pattern is apparently empty).

I've also been able to reproduce the bug in the previous post (where the two LifeHistory patterns being identified causes the third pattern to break) on all the devices I use most often across many different web browsers, so I believe that it's universal. Are you able to reproduce it?

----

Is there something on the backlog regarding color customization? I've made reports over the past weeks about script commands not changing certain state colors in the none rule and [R]Super, the existence of inconsistencies and unexpected results for certain elements, as well as some invalid elements not returning errors when customized. Impolite it may be to reiterate these so soon, but I'm just curious as to if there's some underlying issue with changing colors with a fix underway or a planned refactoring of how color customization is handled, or if fixing these just isn't a high priority at all.

Anyway, enjoy your week away!

[muzik]

As of the release of the super secret build 944 Identify no longer seems to be able to detect oscillators, and instead just ends up breaking everything. This is probably known already.

Code: Select all

x = 2, y = 2, rule = Seeds
o$bo!

Code: Select all

x = 4, y = 1, rule = LifeHistory
3AF!

One thing I've been curious about for a while: how are [R]History marked states handled since they appear taller in Layers? This would imply that more than 256 states are in use, since you'd need 64 states for states 3 and 5 and another 64 for state 4. It'd also imply that fading could be easily supported for these marked states, but we all know that can't happen. So how does it work?

Code: Select all

x = 22, y = 11, rule = LifeHistory
8.A$8.A.A10.E$8.2A11.E$21.E$21.E$6D15.E$6D15.E$6D15.E$6D15.E$6D15.E$
6D15.E!
[[ LAYERS 10 DEPTH 0.3 ]]

[muzik]

I've been doing some relatively minor testing over the past couple of days for any residual bugs. Aside from those in the above posts, there's nothing particularly major, so I'll probably wait until you've returned to report these (unless you'd prefer it if I did so sooner). After those are out of the way, I've been considering taking a temporary hiatus from testing: I feel as though I've been far too persistent and obsessive with reports as they've been effectively nonstop since late December. I'd prefer to spend a bit more time to catch up on studies (nobody need worry, I'm not disastrously far behind but there's improvements to be made), and also fear that my constant reports have been delaying the development of some backlog features I'd like to see as well. So, at least for the next while, I'll post here only if I find a particularly nasty bug, or have accumulated a reasonable size of smaller issues.

----

There are a few things I'd like to ask before the break, though, alongside the [R]History Layers functionality and color customization report questions in the above two posts:

1: Is there a way for a webpage to always use an up-to-date version of LifeViewer? I've been experiencing the hexagonal/triangular grid page freezing bug more and more often and it's beginning to annoy me a lot. I'd like to create a simple test page containing some patterns which I can send to others as to deduce what exact devices, operating systems, browsers, versions and so on are affected by this issue so that it can hopefully be fixed.

2: Over the past few months, there have been some bugs and inconsistencies that I've reported that haven't received a response so far. It's probably quite rude of me to ask, but I would like to know why each one hasn't been responded to, since the reason could vary from "unfixable" to "on the backlog" to "working as intended" to "I didn't see it/forgot about it" to "not a priority". Knowing what's intended and what's not is valuable information and helps me a lot when figuring out what to test for in LifeViewer. Could I reiterate these potentially-overlooked potentially-issues at some point so I can know what ones are issues and what ones aren't?

3: Will build 944 and build 945 be added to the list of prior LifeViewer versions on the site, and/or noted on the changelog?

4: A low-priority request, but there are still some posts which link to the original site at lazyslug.no-ip.biz. These links don't work anymore (in one of the more annoying ways: the loading times out instead of going to a 404 page, so I often just think that the internet is being slow when I click on one). Would it be possible to edit some of these posts so that they point to the new domain and don't do this irritating timing-out nonsense? Here's an incomplete list (some should be left as is since they explicitly discuss the difference between the two URLs).

5: Why don't we get "Build x is now live on the Forums and LifeWiki" posts anymore? The last one of those was made back in 2020 for build 558 and there hasn't been one since.

----

As usual: thank you for your time!

[muzik]

I am not sure why, but Identify appears to take far, far longer for [R]History patterns than [R]Standard or [R]Super:

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 = B3/S23History
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 = B3/S23Super
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!

All three of these should take about the same amount of time. The results are as follows:
[R]Standard: 1.9s for period detection, 3.0s overall
[R]History: 10.3s for period detection (!), 11.4s overall
[R]Super: 4.8s for period detection, 7.2s overall

----

Would it also be possible to output the elapsed Identify time for cases where nothing ends up being identified (max number of periods elapsed, all cells die, or Identify is cancelled)?

[rowett]

I'd prefer to spend a bit more time to catch up on studies, and also fear that my constant reports have been delaying the development of some backlog features I'd like to see as well. So, at least for the next while, I'll post here only if I find a particularly nasty bug, or have accumulated a reasonable size of smaller issues.

You should certainly consider testing LifeViewer a low priority task. From a development perspective it's the same: I get to it when real life allows.

1: Is there a way for a webpage to always use an up-to-date version of LifeViewer?

Simplest way would be to run a scheduled job to copy the latest version from here.

2: Over the past few months, there have been some bugs and inconsistencies that I've reported that haven't received a response so far.

If I've not specifically addressed them it's because I haven't had time yet (see real life, above). I prioritize functionality/crashes first, then ongoing development. Large items go on the backlog. Small items either get fixed as I go or stay here on the forum until I've got nothing better to do (which hasn't happened yet). Example 1: standardizing bounding box behaviour across the rule families is a larger item so it's on the backlog. When fixed it will provide consistency and improved performance. Example 2: anything related to the none rule is low priority. If it's really quick to fix I may do it when editing other stuff, otherwise it will sit here until I get back to it.

3: Will build 944 and build 945 be added to the list of prior LifeViewer versions on the site, and/or noted on the changelog?

They are in the changelog. The prior versions don't exist since they were created as hotfixes outside the standard build environment.

4: A low-priority request, but there are still some posts which link to the original site at lazyslug.no-ip.biz.

Fixed those that looked relevant, thanks.

5: Why don't we get "Build x is now live on the Forums and LifeWiki" posts anymore? The last one of those was made back in 2020 for build 558 and there hasn't been one since.

Time mostly. Plus in the "good old days" there used to be less builds with more functionality.

[rowett]

Identify used on the following spaceship has it hit the border, but no "Life ended at" message is displayed and the "Identifying..." text persists. Also, for some reason, all of the historical dead cells end up being wiped after the pattern dies, both in normal playback and when using Identify.

Fixed, thanks.

I've also been experiencing frequent crashes/viewer bugs much like the "slow ship Identify" issue I reported earlier (as mentioned before, the removal of many bounded grids from the Larger than Life thread made this no longer a problem). Are there any in-viewer statistics or tools I can use to monitor memory usage to identify potential memory leaks, areas for optimization and other such things so that I can figure out reliable reproduction steps for certain issues as well as experiment with viewer performance and handling under different environments as to procure information which may be useful for resolving such issues?

Best thing to do is to check the browser console. Not sure that's possible on Mobile, but on the desktop it shows clearly if there has been a crash.

For example, upon loading the page, opening the first of the three following patterns, Identifying it, then opening the second of the three and Identifying it as well will cause opening of the third pattern to do the "jumping to the top of the page with a buggy shrunken viewer window" thing. I've been able to reproduce this on my iPad, laptop and phone, so there's a good chance it'll happen on other devices, but I can't guarantee it will for every possible one out there, but if I can track what exactly is causing it I might be able to trigger it in some other environments so you have a usable test case.

Fixed, thanks.

Further testing of boundary killing with Generations patterns for range-1 and general-range has turned up some interesting differences. The following patterns are the same pattern in the same rule in two different rulespaces. Along with the generation everything dies at being different (probably not worth "fixing") and all of the historical dead cells being wiped, the "dying" cells are also wiped for general-range rules, and we get a negative amount of alive cells for the general-range pattern as well. Identify on the bottom pattern gets us much the same issue as the first pattern in this post.

Fixed, thanks. Note the two rules behave slightly differently since they use different algos.

If we start from an earlier generation and Identify the pattern, the general-range spaceship has a very interesting maximum population and heat. The bounding boxes also differ.

Fixed, thanks.

Similarly strange bounding box sizes can be seen when patterns hit plane boundaries and die like in the following pattern when identified.

Fixed, thanks.

[muzik]

Welcome back!

I've accumulated a handful of [R]History-related issues, which will hopefully be reported later today. Here's a minor one: for Niemiec cells, RLEs beginning with an "x" don't appear to be recognised correctly:

Code: Select all

x = 1, y = 1, rule = B3/S23
x!

Code: Select all

x = 1, y = 1, rule = B3/S23
o!

Code: Select all

x = 1, y = 1, rule = B3/S23
xo!

Code: Select all

x = 1, y = 1, rule = B3/S23
ox!

There's also the previously-reported case where saving patterns with Niemiec cells and then opening the code box again renders them unreadable by the 2-state algorithm. I don't know what the correct way to handle these situations should be.

[muzik]

Here's the remaining issues I've found so far with [R]History:

----

Pasting over existing deathforcer cells doesn't properly remove them and they still have effects as if they were still there. I'm not sure if this is related to the issue where pasting in RLEs containing [R]History/[R]Super states doesn't actually paste in those states (which a few others have reported before).

Code: Select all

x = 1, y = 1, rule = LifeHistory
F!
[[ GPS 3 RLE blank b! RLE blink 2o$bo! PASTET 1 PASTE blink 1 0 PASTE blank 0 0 ]]

This can also get us negative values for births (which can never happen otherwise since for this to happen requires a living cell and deathforcer to occupy the same space):

Code: Select all

x = 7, y = 7, rule = B/S012345678History
F!
[[ GPS 3 RLE bigblock 7A$7A$7A$7A$7A$7A$7A! PASTET 1 PASTE bigblock -3 -3 ]]

----

[R]History marked states appear to spread to grid boundaries when using Klein bottle, cross-surface and sphere bounded grids. This also allows for the boundaries of the grid to be selected using Select All.

Code: Select all

x = 10, y = 10, rule = LifeHistory:P10
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:T10
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:K10,10*
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:K10*,10
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:C10
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:S10
C8.E9$E8.E!

Code: Select all

x = 10, y = 10, rule = LifeHistory:S10*
C8.E9$E8.E!

----

In addition, deathforcer cells don't work across grid boundaries when using Klein bottle, cross-surface and sphere bounded grids. Is this at all related to the old issue where deathforcer cells didn't kill adjacent cells on triangular grids/killed cells that were too far away on hexagonal grids/killed the wrong cells when using the Hex Tripod neighbourhood? I'm curious as to whether fixing this bounded grid issue might also allow for an easy fix for those and make [R]History usable with said grids/neighbourhoods again. If we change the rule used for any of the incorrectly-behaving bounded grids to [R]Super, we can see the expected behaviour.

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:P10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:T10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:K10,10*
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:K10*,10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:C10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:S10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:S10*
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

----

State 6 cells also don't work as expected in B0 rules. They're meant to kill all of the cells currently adjacent to them in normal rules. For B0 rules, we invert the roles of dead cells and alive cells, so for example in AntiLife all alive cells are represented by dead cells and all dead cells are represented by alive cells. Here's a custom rule which is AntiLife with a deathforcer cell, which results in a period-871 oscillator:

Code: Select all

x = 75, y = 75, rule = AntiLifewDF:T75
75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A
$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$
75A$37AB37A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A
$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$75A$
75A$75A$75A$75A$75A$75A!
#C [[ MAXGRIDSIZE 9 ]]
@RULE AntiLifewDF
@TABLE
n_states:3
neighborhood:Moore
symmetries:permute
var a={0,1,2}
var a1=a
var a2=a
var a3=a
var a4=a
var a5=a
var a6=a
var a7=a
var d={0,2}
var d1=d
var d2=d
var d3=d
var d4=d
var d5=d
var d6=d
var d7=d
0,d,d1,d2,d3,d4,d5,d6,d7,1
0,d,d1,d2,d3,d4,d5,d6,1,1
0,d,d1,d2,d3,d4,d5,1,1,1
0,d,d1,d2,d3,d4,1,1,1,1
0,d,d1,d2,d3,1,1,1,1,1
0,d,1,1,1,1,1,1,1,1
0,1,1,1,1,1,1,1,1,1
1,0,0,0,1,1,1,1,1,0
1,2,a,a1,a2,a3,a4,a5,a6,0
@COLORS
0 0 0 0
1 0 255 255
2 96 96 96

It'd be expected that the following would evolve into a period-871 oscillator as well, however this does not happen. The correct behaviour can be seen in CAViewer.

Code: Select all

x = 1, y = 1, rule = B0123478/S01234678History
F!

Code: Select all

x = 1, y = 1, rule = B0123478/S01234678Super
F!

----

Interestingly, if we load up the above ruletable, and then one of the patterns below it, we get an error saying that B0 ruletables aren't supported. If we go back to the "deathforcer across boundary" patterns, state 6 just stops killing alive cells for some reason. A crash happens if we try to identify the patterns in this state.

----

This is pretty much it for [R]History aside from the above post with the Niemiec pattern not being recognised (and Niemiec cells not being saved properly), the other post from earlier today mentioning that Identify's period detection is considerably slower than even [R]Super, the case in the other thread where deathforcer cells weren't counted as part of the boundary for KILLGLIDERS resulting in incorrect pattern behaviour, as well as old issues like KILLGLIDERS overwriting marked states and the "Life ended at" message being played when modifying a pattern that has never contained any live cells during playback.

[confocaloid]

(Likely not a bug)
A SUPPRESS-related question. Is this feature designed to work with two or more uses of the keyword in a single viewerconfig, as in the examples below? As far as I understand, each new occurrence of the keyword SUPPRESS allows for anything that was specified before that keyword-occurrence to be overwritten at most once between that keyword-occurrence and the next keyword-occurrence (if any) -- is this correct / safe to assume that it will handle multiple levels?

Code: Select all

#C [[ THEME 6 ZOOM 16 SUPPRESS THEME LifeHistory ZOOM 8 SUPPRESS THEME Fire ZOOM 24 ]]
x = 3, y = 3, rule = B3/S23
bo$o$3o!

Code: Select all

#C [[ THEME 6 ZOOM 16 SUPPRESS ]]
#C [[ THEME LifeHistory ZOOM 8 SUPPRESS ]]
#C [[ THEME Fire ZOOM 24 ]]
x = 3, y = 3, rule = B3/S23
bo$o$3o!

[rowett]

for Niemiec cells, RLEs beginning with an "x" don't appear to be recognised correctly

Fixed, thanks.

[rowett]

Pasting over existing deathforcer cells doesn't properly remove them and they still have effects as if they were still there

Fixed, thanks.

[R]History marked states appear to spread to grid boundaries when using Klein bottle, cross-surface and sphere bounded grids

Fixed, thanks.

In addition, deathforcer cells don't work across grid boundaries when using Klein bottle, cross-surface and sphere bounded grids.

Fixed, thanks.

State 6 cells also don't work as expected in B0 rules. They're meant to kill all of the cells currently adjacent to them in normal rules. For B0 rules, we invert the roles of dead cells and alive cells.

They work as I expected in B0 rules. I'm not sure your last sentence is universally true. For AntiLife it would make sense to have a variant of State 6 that behaved in the inverse manner.

Interestingly, if we load up the above ruletable, and then one of the patterns below it, we get an error saying that B0 ruletables aren't supported.

Fixed, thanks.

[rowett]

A SUPPRESS-related question. Is this feature designed to work with two or more uses of the keyword in a single viewerconfig, as in the examples below? As far as I understand, each new occurrence of the keyword SUPPRESS allows for anything that was specified before that keyword-occurrence to be overwritten at most once between that keyword-occurrence and the next keyword-occurrence (if any) -- is this correct / safe to assume that it will handle multiple levels?

Yes, your understanding is correct.

[muzik]

How about some ruletable issues?

One thing to note: errors in invalid rule tables aren't reported for repository rule tables, but are for inline rule tables. I can provide an explicit example later if desired.

Unbounded B0 rules don't always appear to be rejected upon first load:

Code: Select all

x = 6, y = 3, rule = LifeRLB0
.3A$3A.2A$.3A!
[[ STEP 2 NOTHROTTLE ]]

Patterns crossing grid boundaries don't appear to have their population calculated correctly. For the following two patterns, the population should be a constant 26.

Code: Select all

x = 6, y = 14, rule = B3/S23:T20
3bo$bo3bo$o$o4bo$5o6$b2o$2ob3o$b5o$2b3o!
[[ SHOWGENSTATS ]]

Code: Select all

x = 6, y = 14, rule = Life-RuleTree:T20
3bo$bo3bo$o$o4bo$5o6$b2o$2ob3o$b5o$2b3o!
[[ SHOWGENSTATS ]]

There's also the fact that some patterns can be assigned bounding boxes in Identify which are impossible, since they'd be taller or wider than what the bounded grid allows, which I assume is the same core issue.

Code: Select all

x = 4, y = 4, rule = B3/S23:T0,5
o2bo$o2bo$b2o$b2o!

Code: Select all

x = 4, y = 4, rule = Life-RuleTree:T0,5
o2bo$o2bo$b2o$b2o!

The following patterns demonstrate another issue: despite being functionally identical, the second is a spaceship with a mod a quarter of its period, which should not be possible. The first is identified as an oscillator. Since these two patterns funcation identically it'd be expected they'd also be identified identically.

Code: Select all

x = 2, y = 3, rule = B2ac/S:T0,10
bo2$2o!
#C [[ GRID ]]

Code: Select all

x = 2, y = 3, rule = RuleB2AC:T0,10
bo2$2o!
#C [[ GRID ]]
@RULE RuleB2AC
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect
1,0,0,0,0,0,0,0,0,0
1,1,0,0,0,0,0,0,0,0
1,1,1,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,0,0,0
1,1,1,1,1,1,1,1,0,0
1,1,1,1,1,1,1,1,1,0
0,1,1,0,0,0,0,0,0,1
0,0,1,0,1,0,0,0,0,1

We can set the number of states in a rule table to a non-integer value. This changes how the state selector looks considerably, and we also get no "New Pattern" message.

Code: Select all

x = 1, y = 1, rule = 1state
!
#C [[ GRID ]]
@RULE 1state
@TABLE
n_states:2.000000000000005
neighborhood:Moore
symmetries:permute

Sometimes, patterns containing states outwith the maximum state number are not rejected. In this example, the state-2 cell is invisible, but we're centered on it and it can be detected via Select All or by mousing over it. Rotating it reverts it to state 1. If we save the pattern while state 2 is present, "undefined" appears in the RLE.

Code: Select all

x = 1, y = 1, rule = NotEnoughStates
B!
#C [[ GRID ]]
@RULE NotEnoughStates
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute

Comments can sometimes invalidate icon decoding. Example taken from here, so I'm assuming that it should accept it as valid.

Code: Select all

x = 9, y = 5, rule = sphere
$bo3b3o$b3o2bo$2bo!
@RULE sphere

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

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

@COLORS

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

@ICONS

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

Code: Select all

x = 9, y = 5, rule = sphere2
$bo3b3o$b3o2bo$2bo!
@RULE sphere2

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

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

@COLORS

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

@ICONS

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

If a pattern is given with one name with an inline rule table with another name, that rule table will be used instead:

Code: Select all

x = 1, y = 1, rule = TheRequestedName
A!
#C [[ SHOWGENSTATS ]]
@RULE TheActualName
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute

Is it intended that ruletable patterns aren't killed like other rulespaces' patterns are when they hit the grid boundary?

Code: Select all

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

Code: Select all

x = 5, y = 4, rule = Life-RuleTree
bo$o$o3bo$4o!
[[ MAXGRIDSIZE 9 STARTFROM 502 ZOOM 24 X -250 ]]

And finally, increasing the amount of layers for some rules will cause the grid to be occluded by the background:

Code: Select all

x = 2, y = 20, rule = MarBlocks5-OT-2x2-minimal
2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C$2C!
[[ GRID ]]

[muzik]

A couple of things about Identify:

What exactly is "Temperature", and should it ever be able to output values exceeding 1? I've seen it give bigger values as outputs before (can't remember the specific cases where it happened), but it seemed wrong.

Minor visual gripe: seven-figure values can escape the background box which is made to contain them in the period map section.

Code: Select all

x = 53, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
53o!
[[ COLOR UIBACKGROUND DeepSkyBlue ]]

Code: Select all

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

It might be a good idea to have the width of said box adjust to the length of the highest period instead, so that it doesn't have a bunch of unused space:

Code: Select all

x = 2, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
2o!
[[ COLOR UIBACKGROUND DeepSkyBlue ]]

This is reported as Rot90CCW, which it should not be, as that's only for objects with a mod a quarter of their period. A valid description of this pattern would be Flip⟋.

Code: Select all

#CXRLE Pos=-6,-6
x = 12, y = 12, rule = B2/S:S20
o10bo$bo2bo2bo2bo2$5b2o7$bo8bo$o10bo!
[[ GRID ]]

This pattern, despite behaving identically in both rules, is incorrectly stated to be of volatility 1 in the Margolus rule. Four stator cells are present, so it should not be.

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!

It's not an alternating rule issue, since this also has a volatility below 1:

Code: Select all

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

[rowett]

Unbounded B0 rules don't always appear to be rejected upon first load

Fixed, thanks.

Patterns crossing grid boundaries don't appear to have their population calculated correctly. For the following two patterns, the population should be a constant 26.

Fixed, thanks.

We can set the number of states in a rule table to a non-integer value. This changes how the state selector looks considerably, and we also get no "New Pattern" message.

Fixed, thanks.

[rowett]

What exactly is "Temperature", and should it ever be able to output values exceeding 1?

Temperature

[muzik]

Here's some bounded grid stuff:

Firstly, thank you for the proper B0 rule table support! This should make working with said rules a lot easier.

Would it be possible to re-enable B0 Generations rules on bounded grids? They were runnable via the general-range algorithm up until B0 2-state emulation was implemented, and now they don't work anymore. It'd make sense for them to work on bounded grids now that ruletables can as well.

Code: Select all

x = 19, y = 15, rule = R1,C3,S5,8,B0-8,NM:T300
8.6A$6.4A4.2A$5.A4.2A4.A$4.A7.A4.A$3.A8.A4.A$2.A8.2A4.A$.2A6.2A.A5.A$
A.A5.A3.A5.A$2A5.A4.A5.A$2A5.A3.2A5.A$2A4.5A7.A$2A15.A$2A14.A$A.A11.
2A$3.11A!

LifeViewer rejects the following bounded grid definitions, but it shouldn't: the grid is unbounded in both directions, so it should just act as though no boundaries have been defined in the first place. Golly accepts the following four such cases.

Code: Select all

x = 3, y = 5, rule = B3/S23:P0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:P0,0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:T0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:T0,0
3o$bo$bo$bo$3o!

Golly rejects the following cases since Klein bottles with one unbounded dimension aren't supported there. I think LifeViewer should treat all of the following the same as the above as well: since both grid boundaries are set to be infinitely far away, this is the same as having no boundary at all, so the boundary definition can be removed.

Code: Select all

x = 3, y = 5, rule = B3/S23:K0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:K0*
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:K0,0*
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:K0*,0
3o$bo$bo$bo$3o!

LifeViewer treats cross-surfaces and spheres with zero dimension very interestingly. Again, the expected behaviour here would be for the pattern to still be supported and for the boundary to not exist.

Code: Select all

x = 3, y = 5, rule = B3/S23:C0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:C0,0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:S0
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 5, rule = B3/S23:S0*
3o$bo$bo$bo$3o!

Code: Select all

x = 3, y = 7, rule = B3/S23:C0
7$3o$obo$3o!

For the following pattern, Identify reports a bounding box size which is far too big to even fit in the bounded grid:

Code: Select all

x = 1, y = 1, rule = MargSingRot:S2
o!

When mousing over the cells used to mark the edge of the bounded grid, "boundary" is displayed, but "bounded" is the expected result since the color of those cells are defined via "COLOR BOUNDED" rather than "COLOR BOUNDARY".

[rowett]

Sometimes, patterns containing states outwith the maximum state number are not rejected.

Fixed, thanks.

Comments can sometimes invalidate icon decoding

Fixed, thanks.

Is it intended that ruletable patterns aren't killed like other rulespaces' patterns are when they hit the grid boundary?

Fixed, thanks.

[rowett]

Minor visual gripe: seven-figure values can escape the background box which is made to contain them in the period map section.

Fixed, thanks.

[rowett]

Would it be possible to re-enable B0 Generations rules on bounded grids?

B0 Generations support has never existed.

LifeViewer rejects the following bounded grid definitions, but it shouldn't: the grid is unbounded in both directions, so it should just act as though no boundaries have been defined in the first place.

Fixed, thanks.

Golly rejects the following cases since Klein bottles with one unbounded dimension aren't supported there. I think LifeViewer should treat all of the following the same as the above as well: since both grid boundaries are set to be infinitely far away, this is the same as having no boundary at all, so the boundary definition can be removed.

Done, thanks.

When mousing over the cells used to mark the edge of the bounded grid, "boundary" is displayed, but "bounded" is the expected result since the color of those cells are defined via "COLOR BOUNDED" rather than "COLOR BOUNDARY".

Fixed, thanks.

[muzik]

Would it be possible to re-enable B0 Generations rules on bounded grids?

B0 Generations support has never existed.

Not for the range-1 algorithm, but I distinctly remember it existing for HROT rules (before emulation existed). It stopped being possible to run these once 2-state emulation support was added back in August or so. This post of mine from early 2020 states that they existed: viewtopic.php?f=3&t=1622&p=87043#p87043

----

Paste commands for the 0th generation don't appear to work for the HROT algorithm. The following two patterns should look and act the same, but the second is wrong. If we play it, it also unaccountably pauses at T=1.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ PASTE 12o$12o$12o$12o$12o$12o$12o$12o$12o$12o$12o! 0 0 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ PASTE 12o$12o$12o$12o$12o$12o$12o$12o$12o$12o$12o! 0 0 ]]

If we go to this page and replace the contents of the text box with a single dot and then run it, the pattern is empty but there's no "Empty Pattern" message.

Can a count of state-6 cells be displayed in Help > Info > Identify? The value in Help > Info > Pattern only counts state-6 cells which come from the RLE itself and won't count any that were drawn in after the fact, or any that are removed manually or via paste commands. Having them listed in the cell period table would also be useful.

Code: Select all

x = 77, y = 80, rule = B3/S023Super
77F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F
$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.
F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F
75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.
F$F75.F$F75.F$F8.3A64.F$F10.A64.F$F9.A65.F$F75.F$F75.F$F75.F$F75.F$F75.
F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F
75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$F75.F$77F!

[rowett]

B0 Generations support has never existed.

Not for the range-1 algorithm, but I distinctly remember it existing for HROT rules (before emulation existed).

Again, support has never existed. Perhaps you were thinking about history states?

Paste commands for the 0th generation don't appear to work for the HROT algorithm.

Fixed, thanks.

[muzik]

B0 Generations support has never existed.

Not for the range-1 algorithm, but I distinctly remember it existing for HROT rules (before emulation existed).

Again, support has never existed. Perhaps you were thinking about history states?

I'll have to load up some old versions of LifeViewer sometime soon, since I definitely remember that the HROT algorithm was able to run B0 generations rules on bounded grids before. Again, they were run as-is, not emulated. I'll report back once I can confirm if it really did happen back then or not.