Pattern viewer for forum threads

[rowett]

When viewing the table of periods or the cell period maps, something appears to be eating a lot of performance for unknown reasons.

Fixed in build 1289, thanks.

Could the hash collision prevention also be added to oscar?

Yes. I'll put it on the list...

[muzik]

[*]Neighbour Count

• there will be Themes in the future

When will the neighbour count colours be made customizable so I can change how it looks (and propose colour schemes for themes)?

[muzik]

Currently running the 5-state shuttle to see if it can be correctly identified.

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

Code: Select all

x = 54, y = 2, rule = MarBlocks-5-rep
o49bobo$bo48bo2bo!

Code: Select all

x = 54, y = 2, rule = MarBlocks-5-rep
A3.B.C.C.C.A.D.A3.C.B3.C.C.A3.D.D.B.C3.C.B.C.C.A$.A2.B.C.C.C.A.D.A3.C
.B3.C.C.A3.D.D.B.C3.C.B.C.C2.A!

Screenshot_20250318_062922.png (68.83 KiB) Viewed 856 times

Screenshot_20250318_062940.png (103.99 KiB) Viewed 856 times

[muzik]

Spaceships no longer have a title when identified:

Code: Select all

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

Code: Select all

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

Are TitleBG, TitleFG, etc. supposed to appear in Help > Info > UI for embedded viewers, since they don't use any of these colours?

[rowett]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

Me too. At that many generations it's using 30 bits and the hash is only 32 bits so will likely need widening.

[rowett]

Spaceships no longer have a title when identified:

Fixed in build 1290, thanks.

Are TitleBG, TitleFG, etc. supposed to appear in Help > Info > UI for embedded viewers, since they don't use any of these colours?

No, fixed.

[muzik]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

Me too. At that many generations it's using 30 bits and the hash is only 32 bits so will likely need widening.

I assume this can be done dynamically as the number of required bits increases? Would there be any performance benefit to, say, starting out with 16 and increasing that to 32 if this is considered to be required?

Somewhat related: it may be interesting to have debug information about Identify displayed during the identification process if showtiming/extendedtiming is on but I don't know if that'd be the backlogged "Identify improvements" thing all over again.

[rowett]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

I've further improved the hash algorithm in build 1291. Identify is now up to nearly 2B generations and still going...

[muzik]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

I've further improved the hash algorithm in build 1291. Identify is now up to nearly 2B generations and still going...

For timescales such as this it may be worth reducing the bounding box as much as possible. Using plane boundaries may improve things (unless bounded-cells cost more to draw to the point where it slows things down more than the decreased bounding box size would increase speed):

Code: Select all

x = 48, y = 2, rule = MarBlocks-5-rep:P48,2
47.A$47.A!

Perhaps this would be twice as fast still:

Code: Select all

x = 48, y = 1, rule = Fredkin_mod5_vonNeumann:P48,1
47.A!
[[ COLOR 1 128 255 128 COLOR 2 128 128 255 COLOR 3 255 128 128 COLOR 4 255 255 128 ]]

[rowett]

Has the Identify period limit of 2^22 / 10^7 been intentionally removed?

Yes. Identify is now effectively unlimited.

All of this aside, things seem to perform smoothly until 100 million generations or so, after which things get choppy

Fixed in build 1291, thanks.

[muzik]

When generating an age gradient, could HSL or HSV be used so that we don't get weird dark phases in the middle, like at around T=30 here?

Code: Select all

x = 7, y = 7, rule = B3/S23
2o$o2b2o$5bo$bobobo$bo3b2o$2b3o$4bo!
[[ COLOR ALIVE Red COLOR ALIVERAMP Lime ]]

I also want to know is the Neighbour shader should work under Moore-neighbourhood rules if a Margolus rule is in use, or if some specific colouring system for Margolus should be used here instead.

Code: Select all

x = 21, y = 21, rule = M0,4,1,3,8,5,6,11,2,9,10,14,12,7,13,15:T20,20
$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o$b19o
$b19o$b19o$b19o$b19o$b19o!
[[ SHADER Neighbour ]]

Since we now have an upgraded version of Identify, can we come to a conclusion on the extant Identify PRs soon and decide whether they should be merged or rejected?

Still thinking of things to look out for in Pro...

[muzik]

When using the Neighbour shader, going to Help > Info > Cells correctly lists the shader used as "Neighbour Count", however it then incorrectly provides the Cell Age colours instead despite these not being used at all here. Can this be fixed so that the Neighbour Count colors are listed here instead?

Code: Select all

x = 9, y = 17, rule = B36-in7e/S23
4bo$4bo$4bo2$3o3b3o2$4bo$4bo$4bo2$3b3o2$bo5bo$bo5bo$bo5bo2$3b3o!
[[ SHADER Neighbour AUTOSTART ZOOM 16 GPS 12 TRACK 0 -7/34 ]]

Use Save Pattern on this - it will correctly save an empty pattern, but the x and y values saved will not change. If the pattern is then reopened and saved a second time, the x and y values will be correctly set to 1, which should happen the first time around.

Code: Select all

x = 10, y = 10, rule = B/S
2o6b2o$2o6b2o7$2o6b2o$2o6b2o!
[[ STARTFROM 1 ]]

Also, in this pattern, they are saved as 2 the second time instead, when they should instead be 1 (empty space's evolution never matters if you only use M0 or M15):

Code: Select all

x = 10, y = 10, rule = M0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
2o6b2o$2o6b2o7$2o6b2o$2o6b2o!
[[ STARTFROM 1 ]]

When a pattern's period is recognised, and the period is lower than a given value (e.g. 1000), can the "Oscillator/Spaceship period" notice and delay be skipped? The delay this message produces is often greater than the actual time needed to calculate everything (which often comes out to less than 0.1 seconds), so having it be completely absent for sufficiently low periods seems like the better option, as low-period objects seldom require large amounts of time for statistic computation.

Code: Select all

x = 5, y = 4, rule = B3/S23-ijn4a
bo2bo$o$o3bo$4o!

Indeed, 0.0 will often be displayed as the total time needed for identification of many simple patterns. Could more precision be displayed in such a case, like was recently done for Go To Gen when it takes a lot of time?

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ AUTOIDENTIFY ]]

Very surprised I never found the following exploit before now. (Can we get "ability to draw outside of bounded grid" in LifeViewer Ultra, by any chance?)

Code: Select all

x = 2, y = 2, rule = B/S:T20
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE o! 0 0 ]]

I've always wanted to know what these permanently-dead cells out of bounds represent, by the way; normal cell birth can never turn these on, and they appear to be much the same across all bounded grid types.

Code: Select all

x = 1, y = 1, rule = B1234/S01234V:T10,10
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE o! 0 0 STARTFROM 128 ZOOM 8 MAXGRIDSIZE 9 ]]

The behaviour is different in the general-range algorithm, where births never happen, and cells never age. This makes me wonder: could we improve performance in the range-1 algorithm by not ticking any cells outside of bounded grid boundaries, for either evolution or ageing?

Code: Select all

x = 1, y = 1, rule = R1,C2,S0-4,B1-4,NN:T10,10
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE o! 0 0 STARTFROM 128 ZOOM 8 MAXGRIDSIZE 9 ]]

The second of these is corrected to K10,10*+1, but the first is considered invalid. Since there's only one valid place to put the * twist indicator, I'd have expected that this would be corrected and loaded as K10*+1,10 instead. Can this be made to happen for cases like these? I run into this every so often when running patterns on shifted Klein bottles and it does get slightly irritating.

Code: Select all

x = 1, y = 1, rule = B1234/S01234V:K10+1,10
o!

Code: Select all

x = 1, y = 1, rule = B1234/S01234V:K10,10+1
o!

Something strange happens here, if we open the first pattern, then open the second pattern, then change the rule to something like "LifeRLB0:T20", the pattern will then be rejected for no reason and set to VIEWONLY.

Code: Select all

#C [[ AUTOFIT ]]
x = 50, y = 50, rule = AntiLife-RuleLoader:T50
50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o
$50o$50o$50o$50o$50o$50o$24o2b24o$24o2b24o$50o$50o$50o$50o$50o$50o$50o
$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o$50o!
@RULE AntiLife-RuleLoader
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,0,1
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,1,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,0,1,1,1,1,1
0,0,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

Code: Select all

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

[rowett]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

I've further improved the hash algorithm in build 1291. Identify is now up to nearly 2B generations and still going...

Now 5.3B...

[b-engine]

Open this:

Code: Select all

x = 1, y = 1, rule = B1234/S0123V:T10,10
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE o! 0 0 STARTFROM 128 ZOOM 8 MAXGRIDSIZE 9 ]]

Change the rule to B3/S23:T10,10, and you'll see a single dot out of bounds:

screenshot.png (7.67 KiB) Viewed 730 times

[muzik]

Since we no longer have an upper limit for periods: in what cases is "Nothing Identified" supposed to appear? Using Identify on this causes it to appear, though this relies on a bug. I don't know why it happens, since T doesn't get very high.

Code: Select all

x = 1, y = 1, rule = B123/S0123LE:T10,10
!
[[ PASTEDELTA -1 0 PASTET EVERY 2 1 PASTE o! 0 0 ZOOM 8 MAXGRIDSIZE 9 AUTOSTART STOP 19 STEP 19 ]]

Saving this then loading it creates gaps on the top and left (remember to rewind to T=0 after loading):

Code: Select all

x = 2, y = 2, rule = B123/S0123LE:T10,10
$bo!
[[ STARTFROM 10 ]]

Selection mismatch bugs still happen for cases such as the following. Try selecting the entire grid and random-filling or inverting:

Code: Select all

#CXRLE Pos=192,192
x = 20, y = 20, rule = B3/S23:T20,20
o!

This is quite unpleasantly jumpy on 144fps (it works smoothly if we set the refresh rate to 60):

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ TRACK 2 2 PASTEDELTA 2 2 PASTET EVERY 1 0 PASTE 5bo$5bo$5bo$5bo$5bo$6o! ]]

For the following: do cells not fade with history because they're outside the bounding box of all (zero) alive cells, and are therefore not considered eligible for further ticking by the history fading algorithm?

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 X -255 PASTE o$o$o$o$o$o! -253 -6 AUTOSTART STOP 256 LOOP 257 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ PASTEMODE XOR PASTET EVERY 1 PASTEDELTA 1 0 PASTE o! 0 0 PASTE o! 0 0 AUTOSTART STOP 256 ]]

Identifying this will say everything died at T=1, but if we then advance another generation manually and identify again, we get "Identifying..." even though nothing ends up being produced. In neither case do we get a result saying everything oscillates with period 2.

Code: Select all

x = 10, y = 10, rule = horriblestrobe:T10
10o$10o$10o$10o$10o$10o$10o$10o$10o$10o!
@RULE horriblestrobe
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,0,1
1,1,1,1,1,1,1,1,1,0

The cell background colour, used in the outer boundary of the period map and frequency map of this oscillator, is not listed anywhere in Help > Info > Identify:

Code: Select all

x = 7, y = 5, rule = B2in3/S123a
bo$o4bo$bo3bo$bo4bo$5bo!
[[ AUTOIDENTIFY ]]

Can the popup's default position be offset from the right of the window slightly, so I don't keep accidentally scrolling up when trying to close the thing?

overlapscroll.png (26.51 KiB) Viewed 710 times

I've further improved the hash algorithm in build 1291. Identify is now up to nearly 2B generations and still going...

Now 5.3B...

Before this accident happens: can a prompt be displayed when trying to close a tab or browser window in which Identify is happening?

[confocaloid]

Since we no longer have an upper limit for periods: in what cases is "Nothing Identified" supposed to appear? [...]

It may be a good idea to assume "nothing identified" as soon as some nonzero cells are deleted due to hitting the edge. That means the actual pattern would evolve differently on the (infinite) square tiling, and how exactly it would evolve cannot be determined by trying to evolve the damaged version further.

It may be a good idea to assume "nothing identified" as soon as there is some trickery with LifeViewer scripts that contradicts the prescribed rules of the CA. After a PASTET of some sort, it would be reasonable to expect "nothing identified", it cannot be a working oscillator, it cannot be a working spaceship, it's some "non-CA trickery".

It may be a good idea to assume "nothing identified" for probabilistic variations. If the same pattern can evolve differently when you run it twice in a row, there's nothing to identify.

[muzik]

It may be a good idea to assume "nothing identified"

As in the following? I can't think of an example for the third that wouldn't also count under PASTE and such, as non-deterministic rules can't use Identify in the first place.

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

I don't think blocking Identify for every instance of pasting is a good idea, though, since there are valid uses for it in theoretical partial completions that can be used to demonstrate expected functionality, such as this block-and-glider sequence hassler:

Code: Select all

x = 19, y = 18, rule = B3/S23
11$14b3o$13b2o3bo$10b2ob3o2bo$10b2o3bo2bo$10bo2bo2b2o$8bo2bo2b2o$12b4o
!
[[
PASTET EVERY 152 38 PASTE o! 0 8
PASTET EVERY 152 76 PASTE o! 8 0
PASTET EVERY 152 114 PASTE o! 16 8
PASTET EVERY 152 PASTE o! 8 16
]]

As for the first listed scenario, this specific example appears to have been fixed since I last checked - I don't know if there are any other objects that can be used to reproduce this.

Code: Select all

x = 124, y = 9, rule = B3aceiy4ekqrty5cijn6ck78/S2c3-y4cejkqt5i6cei7c8
b2o$2o$42bo$34b3o4b3o70b3o5bo$34b3o3b5o69b3o4b3o$34b3o4b3o70b3o5bo$42b
o$2o$b2o!
[[ MAXGRIDSIZE 9 AUTOIDENTIFY ]]

[confocaloid]

[...] I don't think blocking Identify for every instance of pasting is a good idea, though, since there are valid uses for it in theoretical partial completions that can be used to demonstrate expected functionality, such as this block-and-glider sequence hassler: [...]

In such cases, I expect there would be often annoying differences of different kinds between what happens in the "theoretical partial completion" and what happens in an actual completion. The spark would be different, there would be massive sparkers added affecting the output of Identify, there could be a different arrangement of hassled objects that is considered to be a variant/completion of the same idea, and so on, and so forth.

You could manage to find an "alien completion" for some CGoL partial. If it works according to some CA rules then it can make sense to "Identify" it. Again, it wouldn't work in CGoL, and another completion that would work in CGoL would result in a different "Identify" output.

All things considered, I would prefer blocking Identify as soon as there is some automatic pasting or similar "scripting trickery". Either it follows the rules (and therefore exists as a CA reaction in a known way), or it doesn't follow the rules.

[muzik]

After 650 million generations, it claims this is a period 336,128 oscillator, of which I'm also skeptical.

I've further improved the hash algorithm in build 1291. Identify is now up to nearly 2B generations and still going...

Now 5.3B...

Is there a way I can dedicate more computer resources to LifeViewer (presumably an offline downloaded version) as to hopefully increase Identify's speed and obtain a result faster?

If we Save Pattern, the bounded grid on the first pattern is converted to the canonical format K20,20*, but the second is left as is.

Code: Select all

x = 5, y = 4, rule = B3/S23:k20
bo2bo$o$o3bo$4o!

Code: Select all

x = 5, y = 4, rule = Life-RuleLoader:k20
bo2bo$o$o3bo$4o!

It may be worth converting these two to the same thing when saving patterns, as they're functionally identical:

Code: Select all

x = 5, y = 4, rule = B3/S23:T20,20-1
bo2bo$o$o3bo$4o!

Code: Select all

x = 5, y = 4, rule = B3/S23:T20,20+19
bo2bo$o$o3bo$4o!

For halfway shifts, negatives would be converted to positives:

Code: Select all

x = 5, y = 4, rule = B3/S23:T20,20-10
bo2bo$o$o3bo$4o!

Code: Select all

x = 5, y = 4, rule = B3/S23:T20,20+10
bo2bo$o$o3bo$4o!

As far as I can see: the speed at which snow falls very much appears to be tied to browser refresh rate and doesn't change if you change LifeViewer's refresh rate setting. Should the speed of snow be made constant across all refresh rates, or not?

Found another difference in Pro: if we run this with WASM Engine off, the trail of history cells flattens out very quickly, but if we run it with WASM Engine on, they take a long time to collapse (as though HISTORYSTATES was 63 / unspecified). In both cases, there should only be one history state, at the lowest level (rather than the 3 in Standard and 63 in Pro).

Code: Select all

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

Reiterating some other recent reports:

Code: Select all

#C changing the theme will not adjust TRACKLOOP length, causing visual grid jumping
x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ AUTOSTART THEME Margolus GRID TRACKLOOP 4 -1/4 1/4 GPS 5 ]]

Code: Select all

#C Basic shader is not used, despite BACKGROUND = DEAD = DEADRAMP and AGESTATES 0
x = 1, y = 1, rule = W4
o!
[[ COLOR DEAD Black COLOR DEADRAMP Black AGESTATES 0 LAYERS 10 STARTFROM 64 X 32 Y 32 ZOOM 4 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

#C AUTOFIT will focus on living cells during playback, but zoom out to fit history cells when paused
x = 3, y = 4, rule = /2/3
BA$.BA$.BA$BA!
[[ AUTOFIT AUTOSTART STOP 100 ]]

Code: Select all

#C Identify with Kill Gliders will cause history cells to be added to the bounding box
x = 153, y = 21, rule = LifeHistory
120.2A5.2A$B119.2A5.2A2$124.2A$124.2A5$142.2A.2A$141.A5.A$141.A6.A2.2A
$141.3A3.A3.2A$146.A!
[[ KILLGLIDERS AUTOIDENTIFY ]]

Code: Select all

#C [R]History states are ignored when fitting a hexagonal pattern
x = 20, y = 17, rule = B2/S34HHistory
11.F$4.8D$4.9D$4.10D$4.11D$4.12D$4A13D$4A14D$4A15DF$.4A14D$2.4A13D$7.
12D$8.11D$9.10D$10.9D$11.8D$19.F!

Code: Select all

#C Select All works as expected, but Shrink Selection proceeds to exclude two cells
x = 3, y = 4, rule = R1,C3,S,B2
BA$.BA$.BA$BA!
[[ MAXGRIDSIZE 9 STARTFROM 253 X 255 PASTET 253 PASTE o! 250 -2 ]]

[muzik]

Found another difference in Pro: if we run this with WASM Engine off, the trail of history cells flattens out very quickly, but if we run it with WASM Engine on, they take a long time to collapse (as though HISTORYSTATES was 63 / unspecified). In both cases, there should only be one history state, at the lowest level (rather than the 3 in Standard and 63 in Pro).

Code: Select all

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

This seems to happen even if we set HISTORYSTATES to 0. LifeViewer Standard still works correctly and has no such trail.

Code: Select all

x = 4, y = 4, rule = B367/S23
bobo$o2bo$b3o$2bo!
[[ STARTFROM 32 HISTORYSTATES 0 LAYERS 10 GRID ZOOM 16 ]]

Code: Select all

x = 4, y = 4, rule = R1,C2,S2-3,B3,6-7
bobo$o2bo$b3o$2bo!
[[ STARTFROM 32 HISTORYSTATES 0 LAYERS 10 GRID ZOOM 16 ]]

After this gets fully identified (which takes a while), the framerate will be very low, even when playback isn't happening. Going back to T=0 will fix this, even if we view Last Identify, but I still don't think the framerate should be as low if nothing is happening and there nothing expensive to draw.

Code: Select all

x = 1, y = 1, rule = R500,C2,S,B1,NM
o!
[[ ZOOM -16 MAXGRIDSIZE 14 SHADER Basic THEME Mono AUTOIDENTIFY ]]

IMG_7394.jpeg (361.75 KiB) Viewed 642 times

[rowett]

Selection mismatch bugs still happen for cases such as the following.

Fixed, thanks.

Before this accident happens: can a prompt be displayed when trying to close a tab or browser window in which Identify is happening?

No, but I've been considering copying a checkpoint to the clipboard every so often.

Now 12.4B...

Is there a way I can dedicate more computer resources to LifeViewer (presumably an offline downloaded version) as to hopefully increase Identify's speed and obtain a result faster?

No.

If we Save Pattern, the bounded grid on the first pattern is converted to the canonical format K20,20*, but the second is left as is.

Fixed, thanks.

It may be worth converting these two to the same thing when saving patterns, as they're functionally identical

No. Other than making things canonical it's unexpected to have them changed.

[rowett]

Very surprised I never found the following exploit before now. (Can we get "ability to draw outside of bounded grid" in LifeViewer Ultra, by any chance?)

Fixed. (No, it's way too expensive).

[muzik]

Identifying the first pattern will block identification of the second pattern:

Code: Select all

#CXRLE Pos=-238,-238
x = 4, y = 4, rule = B2a3i/S
2b2o2$o$o!
[[ MAXGRIDSIZE 9 ZOOM 8 ]]

Code: Select all

x = 12, y = 12, rule = B2/S:S20
o10bo$bo2bo2bo2bo2$5b2o7$bo8bo$o10bo!

[rowett]

Identifying the first pattern will block identification of the second pattern:

Fixed, thanks.

[muzik]

Now 12.4B...

According to this post we could be here for a while: the upper bound for the period is 238 trillion (though it's more likely to be a factor of this).

If we're dealing with timescales such as this, could the T counter be made to display such values accordingly (up to 1 quadrillion)?

Code: Select all

#CXRLE Gen=999999999900
x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ AUTOSTART SHOWGENSTATS TRACK -1/4 1/4 LABEL 1 -3 32 "#I" LABELTRACK -1/4 1/4 ]]

Could we also improve Identify's performance if we can somehow promise that a pattern will never escape a given bounding box (e.g. by encasing the thing we're identifying in a bounded grid)?

If we Save Pattern, the bounded grid on the first pattern is converted to the canonical format K20,20*, but the second is left as is.

Fixed, thanks.

This still appears to happen in build 1297.

Here's a new test case for something mentioned previously: the FPS will still be low after identification completes.

Code: Select all

x = 1, y = 1, rule = R500,C2,S,B1:P13383
o!
[[ MAXGRIDSIZE 14 SHOWTIMING EXTENDEDTIMING HISTORYSTATES 0 AGESTATES 0 AUTOIDENTIFY ]]

For some reason, loading this in LifeViewer Pro will display an out of memory error, even though no playback happens:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B:P12000
b!
[[ MAXGRIDSIZE 14 ]]