Pattern viewer for forum threads

[muzik]

This seems to imply that there's one more alive history state than dead history state: turning on State Number shows that we need to have 65 alive states before we see duplicates at the top, but only 64 dead states for the same effect.

Code: Select all

x = 1, y = 1, rule = W4
o!
[[ STARTFROM 64 ]]

Code: Select all

x = 1, y = 1, rule = W132|W4
o!
[[ STARTFROM 64 ]]

Saving this on an odd generation will cause it to not work correctly once loaded again. This can be fixed by moving it. For example, if saved at T=11, it will not work unless moved one cell upwards. Can extra space be added to Margolus patterns when saved on an odd generation to retain functionality?

Code: Select all

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

Turning on Kill Gliders will break this pattern:

Code: Select all

x = 187, y = 206, rule = B3/S23
141b2o$141bo$159b2o$128b2o29bo$128bo$173b2o$173bo3$139b2o3b2o$142bo$
139bo5bo10b2o3b2o$95b2o43b2ob2o12b5o$95bo31b3o11bobo14b3o$126bo3bo11bo
16bo$82b2o41bo5bo10bo27b2obob2o$82bo42bo5bo$128bo41bo5bo$126bo3bo$127b
3o41b2ob2o$128bo44bo$82bo55bobo19bo$82bo13bo41b2o21b2o$81bobo11b3o27b
3o11bo3b3o14b2o$80b2ob2o9b5o26b3o14bo3bo$79bo5bo7b2o3b2o24bo3bo12bo5bo
$82bo11b5o33bobo6b2obob2o$79b2o3b2o8bo3bo24b2o3b2o3b2o39b3o$95bobo35bo
20b2o3b2o12bo3bo$96bo59b3o$155bo3bo12bo5bo$156bobo13b2o3b2o$98bo58bo$
96b2ob2o45b2o$146bo$95bo5bo45b3o4b2o$149bo5bo$95b2obob2o24b2o24b3o$77b
2obob2o42bo9b4o12bo$77bo5bo47b2o7bo33b2o$78bo3bo48bo3b2o3bo24b2o7bo6bo
$79b3o53bo3bo15bo6bobo2bob2o8b3o$153b2o6b2o2bo4bo7bo$154b2o10bo11b2o$
142b2o23bo$100b2o40bo19bo$100bo28b2o9bobo17b3o13bo$97bo3b3o27bo8b2o17b
o14b2ob2o$59b2o34bobo5bo17b2o9bo26b2o$59bo20b2o14b2o23bo10bo40bo5bo$
80bo8b2o41bo$46b2o37b2o2b2o2b2o36bo41b2obob2o$46bo38bobo2bo2bo35b2o5bo
$86b3o47bobo$60bo26b2o47b2o40bo$60bo114bo2bo$59bobo116bo$58b2ob2o83bo
27b2o$57bo5bo82bobo5b2o3b2o13bo$43bo5bo10bo85b2o8b3o15bobo$43bo5bo7b2o
3b2o30bo60bo3bo15b2o$44bo3bo45b2o60bobo$45b3o34b2o11b2o27b2o31bo$81b3o
3bo7b3o7b2o17bo50b2o3b2o$78bob2o4b4o5b2o8bo53b2o14bo5bo$71b2o5bo2bo4bo
4bo2b2o63bo$71bo6bob2o5bo3bo2bo65b3o13bo3bo$81b3o3b2obo71bo14b3o$82b2o
23b2o$106bo2bo$109bo$59b2obob2o43bo15bo10b2o$59bo5bo40b2obo13b2o11bobo
15bo$60bo3bo42bo16b2o10bo17b2o$61b3o$24b2o129bo$24bo16b2o3b2o33bo25b2o
45bobo$55bo24bobo24bo19bo25bo2bo$11b2o29bo3bo9bo11b2o9bo3b2o8bo9bo21bo
bo24bo2bo12bo$11bo31b3o8b3o11bo10bo3b2o5b4o10b2o20b2o39b2o3b2o3b2o$43b
3o33bo3b2o4b4o10b2o50bo11bobo$64b2o14bobo6bo2bo47bo13b2o17bo3bo$64bo
16bo7b4o45b3o33b3o$65b3o22b4o7b2o34bo36b3o$22b2o3b2o38bo25bo7bobo6bo
26b2o$25bo18b2o57bo5bo$22bo5bo15bo9bo48b2o4b3o50b2o9bo$23b2ob2o21b3ob
2o2b2o57bo41b2o2b2o2b2o4b3o$10b3o11bobo22b4o4bo58bobo39bobo2bo2bo4bo3b
o$9bo3bo11bo27b2o61b2o41b3o11bo$8bo5bo10bo134b2o8bo5bo$8bo5bo155bo5bo$
11bo58bo100bo3bo$9bo3bo57bo100b3o$10b3o56b3o61b5o$11bo120bob3obo$21bob
o35bobo71bo3bo$21b2o36bo3bo70b3o$8b3o11bo3b3o14bo19bo71bo$8b3o14bo3bo
11b4o14bo4bo4b2o50b2o$7bo3bo12bo5bo9bobob2o17bo5bo51bo60b2o$24b2obob2o
4b2o2bo2bob3o12bo3bo31bo70b2o7b2o5bo$6b2o3b2o3b2o17bo4bobob2o13bobo31b
2o40b2o23bo5bobo6bo$16bo24b4o49b2o11bo10bobo14bo24b3o3bo9b3o$43bo28bo
33bo10bo2bo42bo14bo$71b2o33b3o7b2o44b2o$114b2o3bo8b2o$72bo43b2o10bo$
23bo5b2o40bobo43bo2bo$24b2o3bo31bobo6bo2bo44bobo61b3o$23b2o5b3o29b2o5b
o2bo38bo69bo3bo$32bo29bo47b3o67bo5bo$9b2o21bobo8b2o27bo36b5o66b2obob2o
$9bo8b2o13b2o7b3o26b2o89b2obob2o$14b2obo2bob2o15bob2o12bo24bo$14bo4bo
2bo16bo2bo12b2o22bo82bo5bo$18bo20bob2o13b2o21b3o$17bo24b3o11b3o27bo17b
o58b2ob2o$43b2o11b2o28bobo13b3o60bo$55b2o8b2o19b2o13bo7b5o$55bo9bobo
33b2o7b3o$67bo43bo55bo$67b2o97bobo$165bo3bo8b2o3b2o$76bobo14bobo69b5o
11bo$77b2o14b2o4bo64b2o3b2o7bo5bo$77bo16bo3b3o64b5o9b2ob2o$28bo69b3o
65b3o11bobo$28b4o135bo13bo$12bo16b4o63b2o3b2o78bo$11bobo5b2o8bo2bo5b2o
56bo4bo$9b2o3bo14b4o5bo26bo$4b2o3b2o3bo4bobob2o3b4o31b2o$4bo4b2o3bo5b
2o3bo2bo35b2o11bo$11bobo10bo51bo103b2o$12bo8bo2bo15b2o34b3o6b2o93bo$
40bobo42bo$41b3o123b2o$42b2o9bo45b2o66bo$25b3o3bo7b2o13b2o43bo$27bo4bo
6b3o11b2o$2o24bo3b3o$bo$bobo8b2o26b2o$2b2o8bo5bo21bo9bo$9b2o6b5ob2o24b
o$8b3o5bo2b2o4bo23b3o$9b2o5b2o8bo29bo$12b2o4bo7bo29bobo$12bo13bo29b2o$
25bo8b2o26bo$23b2o9bobo23b2o$36bo24b2o14bo$36b2o37b3o$74bo$74b2o$32bo$
32bobo$32b2o4$69b2o3b2o$47bo21bobobobo$46bo23b5o$46b3o22b3o$53bo18bo$
53bobo$53b2o2$58b2o$58bo2$72b2o$72bo4$22b2o$22bo$32bo$30b2o$31b2o11$
17bo$16bo$16b3o$23bo$23bobo$23b2o6$12b2o$12bo!

Advancing this one generation, using Select All and rotating it 90 degrees will leave a cell behind, which should not happen.

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -253 0 STOP 1 ]]

Using Select All on this and trying to move the selected contents to the left will give a "no room" error, which is unexpected since there's still a gap that can be drawn in or rotated into.

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ MAXGRIDSIZE 9 GRID X -255 PASTE o$o$o! -255 0 ]]

In the second pattern, Help > Info > Cells will have a line for "Dead", even though the first doesn't, which does not seem consistent.

Code: Select all

x = 4, y = 4, rule = /2/2
2o$o$3bo$2b2o!
[[ THEME Inverse ]]

Code: Select all

x = 4, y = 4, rule = /2/3
2o$o$3bo$2b2o!
[[ THEME Inverse ]]

This neither changes any colors nor produces an error:

Code: Select all

x = 2, y = 2, rule = B3/S23Super
2o$2o!
[[ COLOR dead 255 255 255 ]]

Code: Select all

x = 2, y = 2, rule = B3/S23Investigator
2o$2o!
[[ COLOR dead 255 255 255 ]]

For [R]Standard and [R]History it changes the color of dead history cells. I don't know if an error should be produced in [R]Super and/or [R]Investigator. While background cells are called "dead" in all of these rules, it shouldn't control their color since this would introduce undesirable inconsistencies.

[muzik]

Can Extended Life patterns be converted to [R]Investigator when loaded so that they can be run natively and with better support? Since this format was widely used before [R]Investigator was created, it seems logical to convert it forward. It would work as follows:

- extendedlife --> B3/S23Investigator
- state 0 --> state 0
- state 1 --> state 1
- state 2 --> state 9
- state 3 --> state 3
- state 4 --> state 14
- state 5 --> state 5
- state 6 --> state 4

Code: Select all

x = 51, y = 7, rule = B3/S23Investigator
43.E$29.2A11.3A$A29.A10.A3.A4.D$A.A6.I19.C5.N4.EA3.AE3.D$2A39.A3.A4.D
$42.3A$43.E!

Code: Select all

x = 51, y = 7, rule = extendedlife
43.E$29.2A11.3A$A29.A10.A3.A4.F$A.A6.B19.C5.D4.EA3.AE3.F$2A39.A3.A4.F
$42.3A$43.E!

Patterns don't appear to get killed at the edges of the grid in the PCA algorithm:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,4,8,5,6,7,2,9,10,11,12,13,3,14,15
!
[[ MAXGRIDSIZE 9 Y 250 PASTE o! 0 240 ZOOM 16 ]]

Both of these specify a bounded grid, but one of these claims no such thing happened.

Code: Select all

x = 3, y = 1, rule = B3/S23:T10000
3o!
[[ COLOR BOUNDED Blue ]]

Code: Select all

x = 3, y = 1, rule = B3/S23:K10*,10+1
3o!
[[ COLOR BOUNDED Blue ]]

For the first pattern, if we start drawing on the right of the screen then drag it to the left, cells will still be drawn as far to the left as they can be. However, for the second pattern, once the cursor enters the gray area, no more cells will be drawn until the cursor re enters the black area.

Code: Select all

x = 1, y = 1, rule = B3/S23:P480
!
[[ MAXGRIDSIZE 9 X -250 ZOOM 16 ]]

Code: Select all

x = 1, y = 1, rule = B3/S23
!
[[ MAXGRIDSIZE 9 X -250 ZOOM 16 ]]

[confocaloid]

Can Extended Life patterns be converted to [R]Investigator when loaded [...]

I believe it is better to leave them interpreted through RuleLoader in the usual way (as the name of an external .rule file to be loaded). There is no need for a generic algorithm in this case. Any old patterns can be simply converted if/when needed, instead of bloating software implementation(s) with conversion code (that will have to be maintained).

Crossposting earlier relevant discussion of the same question:

There's a handful of older rule tables which exist to implement cell states which StateInvestigator would later include, and I think it would be useful for these to be converted to the [R]Extended standard for consistency and any possible performance improvements.

I'd prefer it if the patterns were updated rather than pollute LifeViewer with lots of old rule conversion code.
[...]

[rowett]

Can Extended Life patterns be converted to [R]Investigator when loaded so that they can be run natively and with better support?

No.

Patterns don't appear to get killed at the edges of the grid in the PCA algorithm

Fixed in the next release, thanks.

Both of these specify a bounded grid, but one of these claims no such thing happened.

Not true. The first says Bounded grid too big and the second says Invalid bounded grid definition.

For the first pattern, if we start drawing on the right of the screen then drag it to the left, cells will still be drawn as far to the left as they can be. However, for the second pattern, once the cursor enters the gray area, no more cells will be drawn until the cursor re enters the black area.

True. This is intended.

[muzik]

Select All on this works as expected, but then using Shrink Selection will exclude two cells from it for some reason.

Code: Select all

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

How are layers expected to work across 2-state rulespaces with no history? These look different:

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ LAYERS 10 COLOR ALIVE Red SHADER Basic ]]

Code: Select all

x = 5, y = 4, rule = Life-RuleLoader
bo2bo$o$o3bo$4o!
[[ LAYERS 10 ]]

Also compare:

Code: Select all

x = 5, y = 4, rule = B3/S23Investigator
bo2bo$o$o3bo$4o!
[[ LAYERS 10 COLOR on Red ]]

Layers also look a bit silly when using Select. Could the same treatment as for Tilt be used to turn them off in editing mode?

Interesting benchmarking pattern - the period is identified almost immediately, but it takes quite a while to evaluate everything due to the huge bounding box. Could optimizations be made here if there's somehow a way to detect large areas that never turn on? This could be beneficial for identifying large pentadecathlon shuttles, that p1549994 diagonal LtL oscillator, among other things.

Code: Select all

x = 8191, y = 8189, rule = B3/S23
3o8189$8185b3o!
[[ MAXGRIDSIZE 14 THEME Inverse AUTOIDENTIFY SHOWTIMING EXTENDEDTIMING ]]

[muzik]

A new benchmark, this time iterating these functionally identical patterns to 1000000b:

Code: Select all

x = 32, y = 32, rule = B2/SHistory
32F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F
$F30.F$F30.F$F30.F$F13.A16.F$F14.2A14.F$F30.F$F30.F$F30.F$F30.F$F30.F
$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$32F!

Code: Select all

x = 32, y = 32, rule = B2/SSuper
32F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F
$F30.F$F30.F$F30.F$F13.A16.F$F14.2A14.F$F30.F$F30.F$F30.F$F30.F$F30.F
$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$F30.F$32F!

Code: Select all

x = 32, y = 32, rule = B2/SInvestigator
32C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C
$C30.C$C30.C$C30.C$C13.A16.C$C14.2A14.C$C30.C$C30.C$C30.C$C30.C$C30.C
$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$C30.C$32C!

iPad Safari results:

WASM off:
[R]History: 6.1s / 163666gps
[R]Super: 17.0s / 58948gps
[R]Investigator: 24.5s / 40861gps

WASM on:
[R]History: 4.6s / 216919gps
[R]Super: 13.7s / 72896gps
[R]Investigator: 15.5s / 64670gps

In Pro, [R]Super deathforcers appear to be killing all of these cell states by turning them to state 0 rather than the corresponding expected even state. Turning off WASM Engine mostly fixes this. However, even outside of Pro, state 7 appears to become state 0 instead of state 8, which should not happen.

Code: Select all

x = 17, y = 1, rule = B2/SSuper
AF.CF.EF.GF.IF.KF!

PCA patterns killed at the edges of grids do not leave history trail cells, show too many deaths, and can cause negative alive counts:

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,4,8,5,6,7,2,9,10,11,12,13,3,14,15
!
[[ MAXGRIDSIZE 9 Y 250 PASTE o! 0 240 ZOOM 16 AUTOSTART SHOWGENSTATS ]]

This pattern now has a gap on the top row and left column, which did not happen prior to build 1267:

Code: Select all

x = 12, y = 12, rule = B/S012345678:T10
$3bob5o$2bo2bob2o$2b2obo2b3o$b2ob6o$2bo$b6obo$b6o2b2o$2b3o4b2o$bobobo
$b2obob2o2bo!

Also, is there a way to force LifeViewer to run patterns that would otherwise be invalid?

No. That would be a LifeViewer Pro feature

[s]So is it finally time?[/s]

[rowett]

A new benchmark, this time iterating these functionally identical patterns to 1000000b

Interesting.
The performance difference between Standard and Pro will be larger for wider patterns.

In Pro, [R]Super deathforcers appear to be killing all of these cell states by turning them to state 0 rather than the corresponding expected even state.

This appears to be an issue with the compiler optimizer. Not sure how to fix it yet.
EDIT: now fixed, but worrying...

However, even outside of Pro, state 7 appears to become state 0 instead of state 8, which should not happen.

It should happen. Consult the original LifeSuper rule table:

Code: Select all

state 7:  marked ON causing no-trail births
...
var v={7,8,13,14,15,16,17,18,19,20,21,22,23,24,25}     # all no-trail
...
v,6,i,j,k,l,m,n,o,0  # no-trail and labels leave no history

PCA patterns killed at the edges of grids do not leave history trail cells, show too many deaths, and can cause negative alive counts

Fixed, thanks.

This pattern now has a gap on the top row and left column, which did not happen prior to build 1267:

Yes it's now correct and in line with Golly.

Also, is there a way to force LifeViewer to run patterns that would otherwise be invalid?

No. That would be a LifeViewer Pro feature

[s]So is it finally time?[/s]

You missed a key part of the quote...

[Antonin Duda]

(Difficult to implement) Suggestion:
Could Pattern/Identify be able to Identify linear growth patterns?
(What type of linear growth it is, how much does it grow, etc.)
I know it can identify still lifes, oscillators, and spaceships, but could that be extended to guns, puffers, rakes, wickstretchers, wavestretchers, growing spaceships etc.?

[muzik]

However, even outside of Pro, state 7 appears to become state 0 instead of state 8, which should not happen.

It should happen. Consult the original LifeSuper rule table:

Code: Select all

state 7:  marked ON causing no-trail births
...
var v={7,8,13,14,15,16,17,18,19,20,21,22,23,24,25}     # all no-trail
...
v,6,i,j,k,l,m,n,o,0  # no-trail and labels leave no history

Is it too late to be making changes to how [R]Super works in Golly and LifeViewer? Cases like this go against what I'd expect, extrapolating from [R]History behaviour: state 6 should kill living cells, and should not affect marked states since they aren't living and are important for annotation.

This pattern now has a gap on the top row and left column, which did not happen prior to build 1267:

Yes it's now correct and in line with Golly.

Interesting. Seems there's a new behavioural disparity:

Code: Select all

x = 10, y = 10, rule = B012345678:T10,10
2bob5o$bo2bob2o$b2obo2b3o$2ob6o$bo$6obo$6o2b2o$b3o4b2o$obobo$2obob2o2b
o!

Code: Select all

x = 10, y = 10, rule = M0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15:T10,10
2bob5o$bo2bob2o$b2obo2b3o$2ob6o$bo$6obo$6o2b2o$b3o4b2o$obobo$2obob2o2b
o!

The RLE matches, but in the second case, everything is shifted down and to the right, deleting the right column and bottom row in the process. Previously everything would remain in the same position and the top row and left column would be deleted. It's still impossible to start drawing from the top row and left column.

[rowett]

Is it too late to be making changes to how [R]Super works in Golly and LifeViewer? Cases like this go against what I'd expect, extrapolating from [R]History behaviour: state 6 should kill living cells, and should not affect marked states since they aren't living and are important for annotation.

Not my call - I didn't design LifeSuper. I just made [R]Super match the LifeSuper rules.

The RLE matches, but in the second case, everything is shifted down and to the right

That's an existing bug with Margolus rules that's not fixed yet.

[rowett]

Could Pattern/Identify be able to Identify linear growth patterns?
I know it can identify still lifes, oscillators, and spaceships, but could that be extended to guns, puffers, rakes, wickstretchers, wavestretchers, growing spaceships etc.?

Thanks for the suggestion.
If it happens it won't be any time soon. There are several large projects on the LifeViewer backlog at the moment.

[muzik]

Note the two cells farthest to the right - they seems to be drawn in a way that causes them to leak off the grid slightly. I think there's a grid line that isn't being drawn here when it should be.

Code: Select all

x = 14, y = 10, rule = B3/S23
bo6b2o$bo6b2obo$obo9bo$bo7bo$bo8bob2o$bo10b2o$bo$obo$bo$bo!
[[ STARTFROM 78 ZOOM 32 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 GRID THEME Inverse ]]

I think script errors should be shown when trying to customize GRIDMAJOR in hexagonal or triangular rules - it's a color that doesn't apply to the rulespace, just like how trying to customize a cell type that isn't present in this specific rule will display an error since that cell type doesn't apply to this rulespace.

Code: Select all

x = 2, y = 2, rule = B/S0123HT
o$2o!
[[ COLOR GRIDMAJOR Blue COLOR MARK1 Blue ]]

Code: Select all

x = 3, y = 2, rule = B/S0123LV
bo$3o!
[[ COLOR GRIDMAJOR Blue COLOR MARK1 Blue ]]

Can more specific errors for invalid bounded grid definitions be added to make it more clear what the issue is with each?

Code: Select all

x = 3, y = 3, rule = B3/S23:K10*,10+1
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:P10*,10
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:P10,10+1
o$obo$2o!

Code: Select all

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

Code: Select all

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

Code: Select all

x = 3, y = 3, rule = B3/S23:T10+5,0
o$obo$2o!

This is rejected by LifeViewer, but accepted by Golly (becoming T10,10+7):

Code: Select all

x = 2, y = 2, rule = B3/S23:T10,10+2147483647
2o$2o!

Why does the first loop last 20 generations but the second loop last 40 generations?

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ COLOR BACKGROUND 0 0 0 COLOR ALIVE 255 255 0 COLOR GRID 64 0 0 COLOR GRIDMAJOR 99 3 1 GRIDMAJOR 5 SHADER Basic GRID TRACKLOOP 4 -1/4 1/4 GPS 5 ]]

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ THEME MCell GRID TRACKLOOP 4 -1/4 1/4 GPS 5 ]]

Can triangular bounded grids be made one cell thicker on the left and right edges so that they look more continuous? I don't like the way they currently look. They currently look like this:

Code: Select all

x = 1, y = 1, rule = B/S0123LV:T20,20
!

when I think this would look better:

Code: Select all

x = 24, y = 23, rule = B/S0123LV
$24o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$
2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b2o$2o20b
2o$2o20b2o$2o20b2o$2o20b2o$24o!
[[ COLOR ALIVE 128 128 128 ]]

Changing the colors for [R]History cells will define a custom Theme, and changing to any other Theme will change the cell colors away from those custom colors. Can the [R]History cell colors be shown in Help > Themes for each Theme?

Code: Select all

x = 8, y = 5, rule = LifeHistory
2A.2B.2C$2A.2B.2C2$2D.2E.2F$2D.2E.2F!
[[ COLOR MARK1 Blue COLOR MARK2 Pink COLOR MARKOFF Yellow COLOR KILL Magenta ]]

[rowett]

Layers also look a bit silly when using Select. Could the same treatment as for Tilt be used to turn them off in editing mode?

Yes, done.

Note the two cells farthest to the right - they seems to be drawn in a way that causes them to leak off the grid slightly.

Fixed, thanks.

Can more specific errors for invalid bounded grid definitions be added to make it more clear what the issue is with each?

No.

This is rejected by LifeViewer, but accepted by Golly (becoming T10,10+7):

I'm happy with LifeViewer's choice.

Why does the first loop last 20 generations but the second loop last 40 generations?

Fixed, thanks.

Can triangular bounded grids be made one cell thicker on the left and right edges so that they look more continuous?

Yes, done.

[muzik]

Here's another Identify test case for potential optimization. Results on iPad safari, build 1265:

WASM off: 30.5s / 46.3s, no strict volatility
WASM on: 4.5s / 8.9s

Code: Select all

x = 1190, y = 1163, rule = B3/S23
12b2o$2bo4bo7bo$2ob4ob2o2bobo$2bo4bo5bo1157$1182bo4bo$1180b2ob4ob2o$
1182bo4bo!

PCA boundary kills are bugged: the life ended message displays a generation late, and on the generation where everything actually dies, we still have negative values. If we reverse the playback direction and then start playing again, we get stopped, and playing once again will cause cells to rematerialise after we pass the 0 mark.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,4,8,5,6,7,2,9,10,11,12,13,3,14,15
!
[[ MAXGRIDSIZE 9 Y 250 PASTE o! 0 240 ZOOM 16 STOP 14 SHOWGENSTATS ]]

Why does a living cell appear at generation 253 here?

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

Here's a simpler test case for a previously reported bug: history cells aren't ticked at the left or top edges in higher-range rules.

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

Code: Select all

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

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 Y -255 PASTE 6o! -6 -253 AUTOSTART LOOP 500 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 Y 255 PASTE 6o! -6 252 AUTOSTART LOOP 500 ]]

Also, why does this produce an error if we can easily just drag the viewer to this position and beyond?

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B3
!
[[ MAXGRIDSIZE 9 X -266 PASTE o$o$o$o$o$o! -253 -6 ]]

I've minimized this previous bug as well: if state 2 exists in a pattern at the outer edges of the bounding box, it will increase the identified bounding box if KILLGLIDERS affects the pattern's evolution, but will not if KILLGLIDERS doesn't affect how it works.

Code: Select all

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

Code: Select all

x = 153, y = 29, rule = LifeHistory
128.2A$129.A$129.A.A$130.2A5$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.A4$141.2A$141.A.A$143.A
$143.2A!
[[ KILLGLIDERS ]]

Since [R]History will now reject HISTORYSTATES 0: is it also still intended for themes without History to not show history cells in [R]History rules, or should this behaviour be changed for these themes?

Thank you again for the many recent fixes!

[rowett]

Here's another Identify test case for potential optimization. Results on iPad safari

Based on those results there's nothing to optimize. Pro is already very fast.

PCA boundary kills are bugged: the life ended message displays a generation late, and on the generation where everything actually dies, we still have negative values.

Fixed in build 1270, thanks.

If we reverse the playback direction and then start playing again, we get stopped, and playing once again will cause cells to rematerialise after we pass the 0 mark.

This is expected. Reversing the playback direction is not the same as Undo. It takes the current pattern and runs it through the reverse algo. The cell reappearing is because PASTE gets triggered again at T=0.

Thank you again for the many recent fixes!

Thanks for finding the issues!
I'm only going to focus on major issues at the moment since I don't want to delay the bigger LifeViewer projects.

[LuveelVoom]

Do you think we could get [[MAXGRIDSIZE 15]] or even 16 with the new performance update?

[rowett]

Do you think we could get [[MAXGRIDSIZE 15]] or even 16 with the new performance update?

No.

The browser limits the amout of memory available to Javascript. In the current versions of Chrome and Edge the maximum is around 4Gb, but depends a bit on the device and system memory.

If your device has more system memory than this it doesn't make much difference since it's a browser enforced limitation. If your device has around this amount of system memory or less then it's likely to run slowly on larger patterns or not run at all.

Every time you increase [[ MAXGRIDSIZE ]] by 1 you quadruple the memory requirement.

For Life-like rules the memory needed looks roughly like this (depending on the pattern size, display size, etc.):

• MAXGRIDSIZE 13 (8192x8192) = 320Mb
• MAXGRIDSIZE 14 (16384x16834) = 1.25Gb
• MAXGRIDSIZE 15 (32768x32768) = 5b
• MAXGRIDSIZE 16 (65536x65536) = 20Gb

For HROT/LtL rules the memory requirement is higher:

• MAXGRIDSIZE 13 (8192x81929 = 512Mb
• MAXGRIDSIZE 14 (16384x16834) = 2Gb
• MAXGRIDSIZE 15 (32768x32768) = 8Gb
• MAXGRIDSIZE 16 (65536x65536) = 32Gb

LifeViewer Pro introduces the use of WebAssembly, which accelerates many of LifeViewer's functions. Whilst WebAssembly has its own heap (up to 2Gb by default due to 32bit addressing) this memory is not extra. The 4Gb limit is the total memory available to both Javascript and WebAssembly by the browser.

Finally, the default LifeViewer size of 512x256 cells uses about 2.5Mb.

[confocaloid]

Do you think we could get [[MAXGRIDSIZE 15]] or even 16 with the new performance update?

Ultimately, I think Golly will "win" over LifeViewer for the purpose of studying/editing large patterns. Some cases where LifeViewer "wins", or at least can "win" depending on what one is doing, are when the pattern is not too large (below 500-by-500 if you ask me, but that depends on what the pattern is, is it an oscillator or a spaceship or a rake or a breeder or a stamp collection?), or (currently) when the underlying tiling isn't the square tiling (although there is hexgrid.lua for Golly which is useful), or in general where some feature is supported in LifeViewer but not in Golly.
Of course, depending on what someone is trying to do with patterns, some other software tool may well "win" over both Golly and LifeViewer.

I personally would prefer if the defaults stayed the same (and anything beyond the defaults had to be requested explicitly). I'm currently using "Safe Mode" ( viewtopic.php?p=203730#p203730 ).

Of course this isn't in any way meant to belittle all the performance-related efforts and improvements.

[muzik]

Here's another Identify test case for potential optimization. Results on iPad safari

Based on those results there's nothing to optimize. Pro is already very fast.

I think there may be further improvements to be made, since there are large areas at the bottom-left and top-right that remain completely unvisited at all times, but are nonetheless counted in the bounding box and therefore use up more time. These would be ignored if there was also a way to exclude cells that aren't in the 45-degree-rotated bounding rectangle and such, but I don't know if a) it's cheap to calculate and wouldn't itself increase times considerably and b) if it would ultimately be worth it when there are other ways to bloat the bounding box with permanently-dead cells.

Here's a bigger, slower example that could be used for optimization if considered worth investigating at some point:

Code: Select all

x = 3290, y = 3263, rule = B3/S23
12b2o$2bo4bo7bo$2ob4ob2o2bobo$2bo4bo5bo3257$3282bo4bo$3280b2ob4ob2o$
3282bo4bo!

Do you think we could get [[MAXGRIDSIZE 15]] or even 16 with the new performance update?

Ultimately, I think Golly will "win" over LifeViewer for the purpose of studying/editing large patterns.

This is generally how I view it. Golly is intended as more of a heavy-duty tool for editing large patterns, using technical scripts, building a pattern library, running HashLife stuff, and so on. LifeViewer is much more convenient for simple editing and playback (to the point where it's barely just a "viewer" anymore) for most of the common rulespaces if you have access to a modern web browser.

Since Golly's pattern collection is continuing to grow, I'm considering revisiting this idea again, since all but some of the bigger and more technical patterns, as well as the more exotic rulespaces such as 3D CA, could easily be presented and accessed through a web page, perhaps even the conwaylife.com home page.

[rowett]

Since Golly's pattern collection is continuing to grow, I'm considering revisiting this idea again, since all but some of the bigger and more technical patterns, as well as the more exotic rulespaces such as 3D CA, could easily be presented and accessed through a web page, perhaps even the conwaylife.com home page.

LifeViewer can run the majority of Golly's built-in pattern collection.

From Golly you can easily test a pattern by running Scripts>Lua>showinviewer.lua (on my Golly instance I have this bound to hotkey Alt-V). That script will launch a browser with LifeViewer and the current pattern loaded.

You'll need to first download and install the latest build of LifeViewer which you can do by running Scripts>Lua>update-viewer.lua and following the instructions.

[muzik]

Do you think we could get [[MAXGRIDSIZE 15]] or even 16 with the new performance update?

Unrelated to the new higher-performance engine, but there are (or at least were) planes to have grid size be configurable per-axis, such that one dimension could be increased if another was to be decreased.

In a future build it will be possible to set MAXGRIDSIZE separately for width and height. The minimum width will stay at 9 (512 pixels) but the minimum height will reduce to 8 (256 pixels).

I can see this being particularly useful for Catagolue incremental syntheses, for example. They take up a large amount of horizontal space, but not much vertical space. Some are big enough that they exceed the maximum dimensions using MAXGRIDSIZE 14:
https://catagolue.hatsya.com/object/xq4 ... q131/b3s23

Since the pattern is only 117 cells high, the width could be decreased to 8 as is stated in the quote, permitting a much wider grid that could account for a much wider pattern such as this. (I don't know why the lower limits would be different for the X axis and Y axis, though.)

[muzik]

Some more performance tests with Seeds on a sphere, 1000000b (1m), build 1270, this time on Firefox:

Code: Select all

x = 3, y = 2, rule = B2/S:S30
o$b2o!

Code: Select all

x = 3, y = 2, rule = B2/SHistory:S30
o$b2o!

Code: Select all

x = 3, y = 2, rule = B2/SSuper:S30
o$b2o!

Code: Select all

x = 3, y = 2, rule = B2/SInvestigator:S30
o$b2o!

Test results:

WASM Engine off:
[R]Standard: 5.4s / 185322gps
[R]History: 5.9s / 169118gps
[R]Super: 19.9s / 52446gps
[R]Investigator: 18.8s / 53273gps

WASM Engine on:
[R]Standard: 3.5s / 287026gps
[R]History: 4.0s / 248323gps
[R]Super: 17.1s / 58356gps
[R]Investigator: 25.1s / 39843gps

When saving a pattern on a bounded grid, should it remember its position? It currently doesn't, which can affect how it evolves on Plane bounded grids and possibly others.

I'm only going to focus on major issues at the moment since I don't want to delay the bigger LifeViewer projects.

I assume the main things being focused on are LifeViewer Pro, the cell shader system, pinch-to-zoom touchscreen support, fixing selections on bounded grids, and fixing that Step Back/Advance bug?

[rowett]

I assume the main things being focused on are LifeViewer Pro, the cell shader system, pinch-to-zoom touchscreen support, fixing selections on bounded grids, and fixing that Step Back/Advance bug?

I published an updated fix for the Step Back/Advance bug in build 1267.

I believe selections should now work on Bounded Grids except for Margolus rule patterns.

From a testing priority perspective: LifeViewer Pro discrepancies is number 1.

[muzik]

I believe selections should now work on Bounded Grids except for Margolus rule patterns.

There are definitely still issues outside of Margolus from what I can see. For example, the following patterns:

Code: Select all

x = 20, y = 20, rule = B34e5i678/S3-i4-c678:K20,20*
obobobobobobobobobo$obobobobobobobobobo$obobobobobobobobobo$obobobobo
bobobobobo$obobobobobobobobobo$obobobobobobobobobo$obobobobobobobobob
o$obobobobobobobobobo$obobobobobobobobobo$obobobob2o2bobobobo$obobobo
bobobobobobo$obobobobobobobobobo$obobobobobobobobobo$obobobobobobobob
obo$obobobobobobobobobo$obobobobobobobobobo$obobobobobobobobobo$obobo
bobobobobobobo$obobobobobobobobobo$obobobobobobobobobo!

Code: Select all

x = 5, y = 4, rule = B3/S23:T60,60
24o!

Select All will visually work. However, random-filling, inverting, flipping, etc. will still be offset, and rotation may be blocked. If we manually select the entire bounded grid and shrink things, the position of the resulting shrunk selection will also be offset.

[muzik]

Since the Golly theme was changed to fit Golly's coloring of Generations and Larger than Life patterns, should the colors also be changed to fit [R]History? Currently, state 2 uses the same color as state 0, and state 1 uses white instead of green.

Code: Select all

x = 19, y = 16, rule = LifeHistory
13.F$2D$DBD$D3B$.2BA4.F3$16.C$16.C.C$16.2C2$18.F3$13.2E3.F$13.2E!
[[ THEME Golly ]]

The theme would define these colors:

Code: Select all

x = 19, y = 16, rule = LifeHistory
13.F$2D$DBD$D3B$.2BA4.F3$16.C$16.C.C$16.2C2$18.F3$13.2E3.F$13.2E!
[[ COLOR BACKGROUND 48 48 48 COLOR ALIVE 0 255 0 COLOR DEAD 0 0 128 COLOR MARK1 192 255 192 COLOR MARKOFF 255 0 0 COLOR MARK2 255 255 0 COLOR KILL 96 96 96 COLOR DEADRAMP 0 0 128 COLOR ALIVERAMP 0 255 0 ]]

I also think the "LifeHistory" theme should be renamed to the "History" theme, since we've had general [R]History support for close to a decade now. "THEME LifeHistory" could still be kept as an alias for backwards compatibility.

What else is planned for the Neighbor shader, other than hexagonal/triangular grid support, a theme system, and possibly fixing that bounded grid bug?