Pattern viewer for forum threads

[rowett]

I assume that the presence of said buttons for other bounded grid types is still not intended, given that the statistic they control isn't printed or calculated in the first place?

Yes, build 847 is your friend.

[muzik]

This is a random and weird request, but could the "LifeHistory" theme be renamed to something a bit more general, such as just the "History" theme? "LifeHistory" could be kept as an alias for backward compatibility's sake, but given that general [R]History is supported for Golly and LifeViewer and has been for a while at this point I think reflecting this in the theme's name would be better.

[muzik]

To reiterate a persistent iOS bug that impacts usability (tested with iPad OS 16.2), it's still possible to render the viewer in a state which is unresponsive to further interaction (besides the close button at the top, as well as moving it) until the page is refreshed.

- Open a viewer pop-up, such as the one provided below
- Interact with the viewer window to verify that it's responsive
- Swipe up from the bottom of the screen slightly, like one would to go back to the home menu (if that's what it's called? I forget), but don't actually go there, just keep the finger on the screen
- Release the touch so that iOS disowns the list of currently open apps
- Touch the open browser to re-enter it
- Attempt to interact with the viewer again to see if it remains responsive. If it still is, repeat from step 3

Eventually, you should reach a state where the viewer will simply not react to touching it, and this will still be the case even if that popup viewer is closed or another is opened. Achieving this state isn't consistent, but repeating the steps seems to have it happen eventually within five to ten tries. Sometimes it just doesn't happen, though, for whatever reason, seemingly as though this bug only wants to occur at inconvenient times.

Code: Select all

x = 10, y = 10, rule = B3/S23
obob3ob2o$2o3bo2bo$obobob2obo$b2ob4obo$2o6b2o$bo2bobo2bo$4obo2bo$3o2b
2ob2o$5b3o$3o2bo2bo!

[rowett]

To reiterate a persistent iOS bug that impacts usability (tested with iPad OS 16.2), it's still possible to render the viewer in a state which is unresponsive to further interaction (besides the close button at the top, as well as moving it) until the page is refreshed.

Unfortunately I've got no way to look into this since I don't own an iPad.

[muzik]

It may be worth looking into optimizing historical cells, since their presence has the potential to slow down the viewer to a considerable degree from what I've experienced.

Here's an example pattern:

Code: Select all

x = 12, y = 13, rule = 2PCA4,0,2,4,3,8,10,6,7,1,9,5,11,12,13,14,15
M6.GC.MH$.DEH5.N.L$2O.OMJM.D2B$.I.IO2J.K2.C$2.O2.D.K.IC$2.L2KN.MN.LC$
.JB2.LA2I2.H$BA5.JO.L$3.D.B.N.G$.H.JE2.MG2MF$F.CN4.KGCJ$.AH.BL.OIECD$
O.C.FMGFKC.N!
[[ STEP 64 ZOOM -2 STARTFROM 5000 ]]

If we let this pattern run to generation 5000, then select the central mass and clear everything outside it, hitting play again will result in noticeably slow playback (step size maxes out at 7 on my device) despite the fact that the central mass still has a very small bounding box until it emote another spaceship just before T=6000.

If we instead clear all of the history cells by using Select All and then inverting the entire pattern twice, and then clear everything outside of the central mass, the step size is noticeably bigger, averaging around 20.

It seems that LifeViewer still processes long-since-dead cells far away from any active cells, hurting performance as a result. This has been a noticeable issue when simulating a given pattern to its final state, disregarding escaping spaceships, as the trail of history cells they leave behind are causative of performance drops like this. I have not tested other rulespaces to determine if they are also affected by this, since PCA rules are where I see this effect most often.

EDIT: Even after clearing the history states with the method described above, it doesn't seem like the viewer's performance is reaching its full potential. If we clear the history states, clear everything outside of the central mass, save the pattern using the Save Pattern button and reopen it, we get playback that isn't even throttled at all until another spaceship pops out.

[rowett]

It may be worth looking into optimizing historical cells, since their presence has the potential to slow down the viewer to a considerable degree from what I've experienced.

The PCA iterator is currently bounding-box based (slower) rather than tile-based (faster). It's (still) on the backlog to rewrite as tile-based.

[muzik]

Does LifeViewer aim to have functional and behavioural parity with [R]History and [R]Super for states 0-6? I have a list of differences of various sizes that I've noted down over the past six months or so that I could send and set up test cases for (preferably in a dedicated thread to reduce clutter) if bringing the two rulespaces closer to each other is a long-term goal.

----

Unrelated feature request: when identifying a given pattern, would it be possible to have the T button fill up (similar to what is seen for timed script commands) to indicate how close LifeViewer is to reaching the maximum identifiable period of 1048576 generations?

[rowett]

Does LifeViewer aim to have functional and behavioural parity with [R]History and [R]Super for states 0-6? I have a list of differences of various sizes that I've noted down over the past six months or so that I could send and set up test cases for (preferably in a dedicated thread to reduce clutter) if bringing the two rulespaces closer to each other is a long-term goal.

No that's not an aim.

Unrelated feature request: when identifying a given pattern, would it be possible to have the T button fill up (similar to what is seen for timed script commands) to indicate how close LifeViewer is to reaching the maximum identifiable period of 1048576 generations?

No, it doesn't give any meaningful information. If it ever gets to the top of the backlog I'll use the progress bar to show strict volatility calculation progress.

[muzik]

For PCA on bounded grids, the density value is not divided by 4 at the end, allowing for density values of up to 400 where a maximum of 100 is expected:

Code: Select all

x = 40, y = 40, rule = 2PCA4,0,4,8,12,1,10,9,13,2,6,5,14,3,7,11,15:T40
40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O
$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$
40O$40O$40O$40O$40O!
[[ THEME Mono SHOWGENSTATS ]]

[rowett]

For PCA on bounded grids, the density value is not divided by 4 at the end

Fixed, good catch!

[muzik]

The following examples have script commands that result in a custom theme due to a custom GRIDMAJOR period value being defined, however the custom theme is grayed out in the themes menu and cannot be returned to:

Code: Select all

x = 13, y = 10, rule = B3/S23
5bo$5bo$6bo2bo$4b3ob2obo$2o6b2ob2o$2o6b2ob2o$4b3ob2obo$6bo2bo$5bo$5bo
!
[[ ZOOM 16 GRID GRIDMAJOR 0 ]]

Code: Select all

x = 13, y = 10, rule = B3/S23
5bo$5bo$6bo2bo$4b3ob2obo$2o6b2ob2o$2o6b2ob2o$4b3ob2obo$6bo2bo$5bo$5bo
!
[[ ZOOM 16 GRID GRIDMAJOR 5 ]]

The expected behaviour would be for this to not be greyed out. The theme should still be considered a custom theme due to GRIDMAJOR being a theme element.

On the topic of GRIDMAJOR: can its value be displayed for all themes in Help > Themes, rather than only those with a custom value, for the sake of consistency?

----

There's also the following odd case: since the default GRIDMAJOR period for the Blues theme is 10, manually defining GRIDMAJOR to also be 10 results in no visual difference in the grid, however the theme still becomes custom.

Code: Select all

x = 13, y = 10, rule = B3/S23
5bo$5bo$6bo2bo$4b3ob2obo$2o6b2ob2o$2o6b2ob2o$4b3ob2obo$6bo2bo$5bo$5bo
!
[[ ZOOM 16 GRID GRIDMAJOR 10 ]]

The same may be true of other things i.e. cell colors are manually defined with script commands to give a result which is ultimately visually identical to the Blues theme or possibly one of the other non-custom themes, however this would be far more of an edge case since all of them have to be defined at once (you can't just change the alive color and leave it at that, since the background color changes and so on if you don't change it manually to also match the theme you're replicating).

For this specific case at least, since nothing has changed as a result of the script commands, I'd expect the viewer to acknowledge this and not define a custom theme, instead sticking with Blues.

[rowett]

The following examples have script commands that result in a custom theme due to a custom GRIDMAJOR period value being defined, however the custom theme is grayed out in the themes menu and cannot be returned to

Fixed, thanks!

There's also the following odd case: since the default GRIDMAJOR period for the Blues theme is 10, manually defining GRIDMAJOR to also be 10 results in no visual difference in the grid, however the theme still becomes custom.

I think it would be confusing for people to specify custom elements and not see the Theme change to Custom (even if those elements are the same as the existing Theme).

[muzik]

I am not entirely sure, but the amount of deaths seems underreported for this pattern. For a population-conserving rule, shouldn't the amount of deaths be identical to the amount of births for each generation?

Code: Select all

x = 40, y = 40, rule = 2PCA4,0,4,8,12,1,10,9,13,2,6,5,14,3,7,11,15
40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O
$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$40O$
40O$40O$40O$40O$40O!
[[ THEME LifeHistory SHOWGENSTATS AUTOFIT ]]

[rowett]

... the amount of deaths seems underreported for this pattern.

Fixed, thanks!

[muzik]

This Rainbow bug seems quite persistent. If we manually turn Rainbow on if it's off by default, or turn it off if it's on to begin with, then step ahead one generation and then back one generation, we either get everything to turn red again or get the stripy effect.

Code: Select all

x = 81, y = 81, rule = B3/S23
81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo3bob2ob
o3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$3o3b6o
3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$9o9b18o9b18o9b9o
$ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o
9b18o9b9o$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b3o$obo3bobo9bobo3bob2obo
3bobo9bobo3bob2obo3bobo9bobo3bobo$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b
3o$9o9b18o9b18o9b9o$ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo
9bob2ob2obo$9o9b18o9b18o9b9o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b
6o3b6o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo
3bob2obo3bob2obo3bobo$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2obo$81o$27o27b27o$ob2ob2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob
2ob2ob2obo$27o27b27o$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$obo3bob2obo3bob2o
bo3bobo27bobo3bob2obo3bob2obo3bobo$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$27o
27b27o$ob2ob2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o
27b27o$9o9b9o27b9o9b9o$ob2ob2obo9bob2ob2obo27bob2ob2obo9bob2ob2obo$9o
9b9o27b9o9b9o$3o3b3o9b3o3b3o27b3o3b3o9b3o3b3o$obo3bobo9bobo3bobo27bobo
3bobo9bobo3bobo$3o3b3o9b3o3b3o27b3o3b3o9b3o3b3o$9o9b9o27b9o9b9o$ob2ob
2obo9bob2ob2obo27bob2ob2obo9bob2ob2obo$9o9b9o27b9o9b9o$27o27b27o$ob2ob
2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o27b27o$3o3b6o
3b6o3b3o27b3o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bobo27bobo3bob2obo3bob2o
bo3bobo$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$27o27b27o$ob2ob2ob2ob2ob2ob2ob
2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o27b27o$81o$ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$
3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bob2obo3bob
2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$3o3b6o3b6o3b6o3b6o3b6o3b6o3b
6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2ob2obo$81o$9o9b18o9b18o9b9o$ob2ob2obo9bob2ob2ob2ob
2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o9b18o9b9o$3o3b3o9b3o3b6o
3b3o9b3o3b6o3b3o9b3o3b3o$obo3bobo9bobo3bob2obo3bobo9bobo3bob2obo3bobo
9bobo3bobo$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b3o$9o9b18o9b18o9b9o$ob
2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o9b
18o9b9o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo
3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$
3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o!

Code: Select all

x = 81, y = 81, rule = B3/S23
81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo3bob2ob
o3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$3o3b6o
3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$9o9b18o9b18o9b9o
$ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o
9b18o9b9o$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b3o$obo3bobo9bobo3bob2obo
3bobo9bobo3bob2obo3bobo9bobo3bobo$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b
3o$9o9b18o9b18o9b9o$ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo
9bob2ob2obo$9o9b18o9b18o9b9o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b
6o3b6o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo
3bob2obo3bob2obo3bobo$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2obo$81o$27o27b27o$ob2ob2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob
2ob2ob2obo$27o27b27o$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$obo3bob2obo3bob2o
bo3bobo27bobo3bob2obo3bob2obo3bobo$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$27o
27b27o$ob2ob2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o
27b27o$9o9b9o27b9o9b9o$ob2ob2obo9bob2ob2obo27bob2ob2obo9bob2ob2obo$9o
9b9o27b9o9b9o$3o3b3o9b3o3b3o27b3o3b3o9b3o3b3o$obo3bobo9bobo3bobo27bobo
3bobo9bobo3bobo$3o3b3o9b3o3b3o27b3o3b3o9b3o3b3o$9o9b9o27b9o9b9o$ob2ob
2obo9bob2ob2obo27bob2ob2obo9bob2ob2obo$9o9b9o27b9o9b9o$27o27b27o$ob2ob
2ob2ob2ob2ob2ob2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o27b27o$3o3b6o
3b6o3b3o27b3o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bobo27bobo3bob2obo3bob2o
bo3bobo$3o3b6o3b6o3b3o27b3o3b6o3b6o3b3o$27o27b27o$ob2ob2ob2ob2ob2ob2ob
2ob2obo27bob2ob2ob2ob2ob2ob2ob2ob2obo$27o27b27o$81o$ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o$
3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo3bob2obo3bob2obo3bob2obo3bob
2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$3o3b6o3b6o3b6o3b6o3b6o3b6o3b
6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2ob2obo$81o$9o9b18o9b18o9b9o$ob2ob2obo9bob2ob2ob2ob
2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o9b18o9b9o$3o3b3o9b3o3b6o
3b3o9b3o3b6o3b3o9b3o3b3o$obo3bobo9bobo3bob2obo3bobo9bobo3bob2obo3bobo
9bobo3bobo$3o3b3o9b3o3b6o3b3o9b3o3b6o3b3o9b3o3b3o$9o9b18o9b18o9b9o$ob
2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2ob2ob2ob2obo9bob2ob2obo$9o9b18o9b
18o9b9o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2obo$81o$3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$obo
3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bob2obo3bobo$
3o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b6o3b3o$81o$ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2obo$81o!
[[ RAINBOW ]]

[rowett]

This Rainbow bug seems quite persistent.

True. It needed fixing in two different places and I only found one last time.

[muzik]

If GRIDMAJOR is set to 0 via commands and the in-viewer theme selector is used to switch to another theme, the "Major GridLines" button in Help > Display will start out as looking off (with n blue highlight), even though major grid lines are present. Toggling it twice resets the viewer to an expected state (the button is off and so are major grid lines).

Code: Select all

#C [[ GRID GRIDMAJOR 0 ]]
x = 191, y = 144, rule = B3aiky4ace5aejk6in/S2en3cij4aciw5-cn6aei7e
12$122bo$123bo5$112bo13b3o$110b5o11bobo$108b4ob4o11bo$106b3obo3bob3o$
104b4obo4bo2bo$102b3obobo5bobo$103bobo$102b3obo$101bobobo$104b2o$102b
3o2$112bo$110b5o$108b4ob4o18bo$106b3obo3bob3o15b2o$104b4o2bo3bo2b4o14b
2o$102b3obo7bobobob3o11bobo$100b4o2bo8b2ob2ob4o8bob3o$99b2ob2o2bo8bo3b
o2bob2o6bobob2o$98b2obo17bobobob2o6b3ob2o$98bob2o24bo5bob3obo$97b5o2bo
20b3o7b5o$97b4ob3o21b2o4b3ob4o$96b2ob4o9bo12bob2o5b4ob2o$96bob3o9b5o
13bo7b3obo$95b4o9b4ob4o8b5o8b4o$95b3o9b2ob2ob2ob2o9b3o9b3o$94b2o10b2ob
2o3bo2b2o10b2o10b2o$94bo11bo2bo4b3obo11bo11bo$93b5o7b4o8b3o9b3o9b3o$
93b3o9b3o7b2obo11bo11bo$92b2o10b2o8b2ob2o10b2o10b2o$81bo10bo11bobo8b3o
9b3o10b2o$79bob3o7b3o9b3o10bo10b3o9b3o$80bo11bo11bobo19bobo9bobo$80b2o
10b2o10b2o21b2o10b2o$81b3o9b3o9b2o19b2o9b3o$81bob3o7b3o9b3o16b4o7b5o$
84bo9bobo9bo15b3obo6b2o3bo$94b2o10b2o2bo11bo2b2o7b2ob2o$95b2o10b2ob2o
9b2ob2o10b2o$95b4o9b4ob2o3bo2b4o8b5o$96bo13b3ob2ob2ob3o13bo$96b2o14b4o
b4o8b2o4b2o$97b3o14b5o10bo3b3o$97b3o16bo11b2o3b3o$98bobo2b3o22bob3obo$
98b2o5bo21b5ob2o$99b2ob3obo20b4ob2o$100b4obo20b2ob4o$102b3obobo17bob3o
$104b4obo13bob4o$106b3ob2o2bo3bo2b2ob3o$108b4o2bo3bo2b4o$110b3obo3bob
3o$112b4ob4o$114b5o$116bo!

If we start out with a theme that does have major grid lines, and then change to a theme that does not such as the Catagolue or Caterer theme, the Major GridLines button is disabled as expected (although it does appear to be on in such a state):

Code: Select all

#C [[ GRID ]]
x = 191, y = 144, rule = B3aiky4ace5aejk6in/S2en3cij4aciw5-cn6aei7e
12$122bo$123bo5$112bo13b3o$110b5o11bobo$108b4ob4o11bo$106b3obo3bob3o$
104b4obo4bo2bo$102b3obobo5bobo$103bobo$102b3obo$101bobobo$104b2o$102b
3o2$112bo$110b5o$108b4ob4o18bo$106b3obo3bob3o15b2o$104b4o2bo3bo2b4o14b
2o$102b3obo7bobobob3o11bobo$100b4o2bo8b2ob2ob4o8bob3o$99b2ob2o2bo8bo3b
o2bob2o6bobob2o$98b2obo17bobobob2o6b3ob2o$98bob2o24bo5bob3obo$97b5o2bo
20b3o7b5o$97b4ob3o21b2o4b3ob4o$96b2ob4o9bo12bob2o5b4ob2o$96bob3o9b5o
13bo7b3obo$95b4o9b4ob4o8b5o8b4o$95b3o9b2ob2ob2ob2o9b3o9b3o$94b2o10b2ob
2o3bo2b2o10b2o10b2o$94bo11bo2bo4b3obo11bo11bo$93b5o7b4o8b3o9b3o9b3o$
93b3o9b3o7b2obo11bo11bo$92b2o10b2o8b2ob2o10b2o10b2o$81bo10bo11bobo8b3o
9b3o10b2o$79bob3o7b3o9b3o10bo10b3o9b3o$80bo11bo11bobo19bobo9bobo$80b2o
10b2o10b2o21b2o10b2o$81b3o9b3o9b2o19b2o9b3o$81bob3o7b3o9b3o16b4o7b5o$
84bo9bobo9bo15b3obo6b2o3bo$94b2o10b2o2bo11bo2b2o7b2ob2o$95b2o10b2ob2o
9b2ob2o10b2o$95b4o9b4ob2o3bo2b4o8b5o$96bo13b3ob2ob2ob3o13bo$96b2o14b4o
b4o8b2o4b2o$97b3o14b5o10bo3b3o$97b3o16bo11b2o3b3o$98bobo2b3o22bob3obo$
98b2o5bo21b5ob2o$99b2ob3obo20b4ob2o$100b4obo20b2ob4o$102b3obobo17bob3o
$104b4obo13bob4o$106b3ob2o2bo3bo2b2ob3o$108b4o2bo3bo2b4o$110b3obo3bob
3o$112b4ob4o$114b5o$116bo!

[rowett]

If GRIDMAJOR is set to 0 via commands and the in-viewer theme selector is used to switch to another theme, the "Major GridLines" button in Help > Display will start out as looking off (with no blue highlight), even though major grid lines are present.

Fixed, thanks!

[muzik]

Setting GRIDMAJOR to 0 and setting the grid and gridmajor colors to identical values both give visually identical results (there are no visible major grid lines), however they have functionally different results:

- In the latter case, the Major GridLines button in Settings > Display remains toggleable.
- In the former case, the color that would be used by the nonexistent major grid lines is still listed in Help > Info > Gridlines.

Code: Select all

x = 21, y = 4, rule = B3/S23
o2bo13bo2bo$4bo11bo$o3bo11bo3bo$b4o11b4o!
[[ GRID GRIDMAJOR 0 ]]

Code: Select all

x = 21, y = 4, rule = B3/S23
o2bo13bo2bo$4bo11bo$o3bo11bo3bo$b4o11b4o!
[[ GRID COLOR GRIDMAJOR 80 80 80 ]]

I think the best way to handle this would be similar to how DEAD and DEADRAMP, etc. are handled: setting them to identical colors would have the major's color set to "none", and setting the interval to 0 would also have the major color set to "none" similar to DEADRAMP. "Interval" would be listed as "Off" for both cases as well.

[muzik]

EDIT: Even after clearing the history states with the method described above, it doesn't seem like the viewer's performance is reaching its full potential.

It seems as though "clearing all history via inverting and inverting again" may actually be harmful to performance itself, regardless of rule family or algorithm. Here's an example test case:

Code: Select all

x = 44, y = 5, rule = B3/S23
obo3bobo3bob3ob3ob3o18bo$ob2o2bobo3bobo3bobo2bo17b3o$obobobobo3bob2o2b
2o3bo18bo$obo2b2o2bobo2bo3bobo2bo$obo3bo3bo3b3obobo2bo!
[[ ZOOM -20 STEP 5 ]]

If we just run this normally, everything is fine. However, if we select the entire 8192x8192 playing field, invert, and invert again such that we return to the initial configuration, playback ends up being capped at 2 generations per second. I'm not sure if it assumes the maximum possible bounding box and slows down because of that, or somehow gets confused since there were a lot of cells within the deletion radius of the boundary, or something else entirely.

[muzik]

When I use Select All on the pattern described by this page, only a 1x1 region ends up being selected: https://catagolue.hatsya.com/object/xp2 ... /g256b3s23

[rowett]

When I use Select All on the pattern described by this page, only a 1x1 region ends up being selected: https://catagolue.hatsya.com/object/xp2 ... /g256b3s23

Fixed, thanks!

Note you'll need to wait until Catagolue updates to build 854.

[muzik]

Using Identify and then viewing the periods tables for these patterns reveals something weird:

Code: Select all

x = 1, y = 1, rule = B02468/S1357:T129,129
o!

Code: Select all

x = 1, y = 1, rule = B1357/S02468:T129,129
o!

For the first case, despite period-254 cells taking up exactly 100% of the rotor, the rotor is also still composed of 0.01% period-2 cells. The second pattern has those periods cut in half (but is otherwise behaviourally equivalent due to not requiring emulation), and the period-1 cell percentage is completely omitted from the "% Rotor" column.

For alternating rules, emulated B0 rules and anything else this may apply to, should period-2 cells be left out of the "% Rotor" column, especially given that period-2 patterns themselves are regarded as still lifes by Identify?

[muzik]

Unfortunately I've got no way to look into this since I don't own an iPad.

It may still occur on an iPhone given that the operating systems and touch controls are similar, so you could try to reproduce this on one of those. It may even manifest with normal usage if you browse the forums clumsily enough (accidentally swiping yourself into the next app over, etc.) while opening every viewer you possibly can, but given how unpredictable this bug is, I can't promise anything.

Speaking of iOS-exclusive bugs: how do selections look on triangular grids on the iPhone? I still see gaps dividing selections into a rhombic grid to this day. This has only ever affected the iPad in my experience; other devices don't have this rendering bug. Can you test this on the iPhone to see how it looks there (I don't have one, so I can't test it myself)? I can send images of the undesirable rendering if you need something to compare it to.

Code: Select all

x = 23, y = 23, rule = B/S0123456789XYZL
4o$2o$o$o2b5ob5obo$3bo5bo5bo$3b5ob5obo$7bobo5bo$3b5ob5ob5o2$3b5ob5ob5o
$3bo5bo7bo$3b5obo7bo$3bo5bo7bo$3b5ob5o3bo2$3b5obo5bo$3bo3bobo5bo$3b5ob
o5bo$3bo3bobo5bo$3bo3bob5ob5o2bo$22bo$21b2o$19b4o!
[[ THEME Gray ]]

[muzik]

When auto-fitting to this pattern, it seems to pulsate strangely after going farther out than 2x zoom:

Code: Select all

x = 16, y = 16, rule = M0,2,8,3,1,5,6,14,4,9,10,13,12,11,7,15|M0,4,1,5,8,3,9,7,2,6,12,11,10,13,14,15
14$31bobobo2bobob2o$28b2ob2o3bobo2b2o$30b2ob3o3b2o$30b2obo3bo2b3o$28b
2o4bo3b2o$30b3o2bobo4b2o$28bob3o3bobo3bo$28b2o4b2o3bobo$28bo2bobo3bo2b
4o$28b3o5b2ob2obo$31b2o5bo2bo$28bob5obobob4o$29b2o3b2o3b2o$28bob2obo4b
2o3bo$29b3ob2o3bo3bo$28bo3b2o5b2o2bo!
[[ AUTOFIT ]]

Compare this to the "underreported PCA deaths" example earlier on this page, in which this effect does not happen despite said pattern's bounding box expanding at the same speed.