Pattern viewer for forum threads

[muzik]

I'm not entirely sure I'm understanding paste modes perfectly. By default, OR works perfectly:

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!

If I use a script command to set the paste mode to AND, COPY or XOR, they all seem to work exactly as intended, but the paste mode selected in the paste menu still reads as OR:

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE AND ]]

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE XOR ]]

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE COPY ]]

And if I try to define any of the other 12 paste modes, pasting just flat out refuses to work:

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE XNOR ]]

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE DIFF ]]

The script commands accept the paste modes as perfectly valid, they just end up being unusable. Invalid paste modes provide errors as one would expect:

Code: Select all

x = 24, y = 12, rule = B3/S23
12o2bo3bobo$13o2b6ob2o$13o5bo3b2o$12o4b2obo3bo$12o6bo$14obo6b2o$13ob2o
b4o$12o4b5o$14o3bo2b2o$12obob5o3bo$13o4b2ob2o$14ob2obo2bobo!
[[ PASTEMODE NONEXISTENT ]]

So I'm not sure exactly what's going wrong here. I'd expect that all paste modes would be usable as expected in the editor, but only four seem to work (and the UI isn't accordingly updated).

I'm also not sure as to why the other 12 can't be selected in the UI either - it's quite inconvenient to have to use script commands to access them, but I'm not sure as to how they could be made conveniently accessible in the selection UI. A second slider could possibly be added to scroll through the 16 types of paste mode just like how you can scroll through different cell states when drawing. Alternatively, since there are four buttons, they could each be made on/off toggles such that each combination would correspond to one of the sixteen paste modes, with the corresponding paste mode name displayed on top of or below the four buttons, but this might be a tad complicated, so do as you see fit.

[rowett]

I'm not entirely sure I'm understanding paste modes perfectly.

There are two different paste modes.

1. The UI paste mode which can be one of AND/CPY/OR/XOR and can only be set in the UI.
This is used to defined the mode when you use the UI to paste cells onto the grid.

2. The script [[ PASTEMODE ]] command which can be one of 16 modes.
This is used to defined the pastemode for subsequent script [[ PASTE ]] commands.

The two do not affect each other (there was an issue I just fixed in this area). This means you can not use the [[ PASTEMODE ]] script command to change the UI paste mode or vice versa.

[muzik]

The two do not affect each other (there was an issue I just fixed in this area).

I had suspected that this was the case, since it seemed odd to have a pattern editions option be controlled via script commands rather than in-viewer, as well as the weird behaviour for inaccessible paste modes.

I'd still like for it to be possible to access and use all 16 paste modes from within the viewer UI, since having the ability to experiment with how pasting a certain pattern over another would work would make writing paste script commands considerably easier. It appears as though the four buttons could be replaced with a 16-value slider that would allow for any desired paste mode to be easily selected. Could this be done?

[rowett]

You can now disable the "If there are no cells displayed click on Help" warning by clicking on Help and then clicking on the OK button next to the workaround description. You'll need to do this once on each website (conwaylife.com, Catagolue, etc.). Note the site will need LifeViewer build 773 or later.

[muzik]

Would it be possible to have the T button remain present in VIEWONLY patterns? It has nothing to do with pattern editing, and the menu it opens is still useful due to it showing the current rule, generation, population and bounded grid density which otherwise aren't visible without digging into Help. The script command that has the T menu open by default still works fine, so all that's needed is for the in-viewer toggle to return.

Code: Select all

#CXRLE Gen=-250
x = 20, y = 20, rule = B3/S23
bo2bo5b3o2bob3o$3bob4o4b3ob3o$5obo3b3o2bo2b2o$2bobob4ob2o3b2o$2b6o2bo
3b5o$3o9bobo3bo$b2ob6ob2o5b2o$b2ob4o4bobo2b2o$3b2ob2ob3obobob2o$b2ob3o
bobobo$2o3b2obo4bo3bobo$3b3ob4o4bobo$3o2b3obob3o2bobo$bobob2obo2bo2b2o
3bo$3bo2b2ob4o3b4o$3obob5obo3bob2o$3ob2o4b2ob2obo2bo$2b4o4bo2bo2b4o$2b
o3b3obo4b3obo$4obo3b7obobo!
[[ VIEWONLY SHOWGENSTATS ]]

[muzik]

There is a new and particularly aggravating bug that I've been experiencing for a while on (guess what) iOS: if a viewer popup window is currently open, the act of switching apps or preparing to do so will render viewers completely unresponsive (aside from the popup itself being able to be dragged around) until the page is refreshed. This gets very annoying if I accidentally swipe from the side and the device thinks that I'm trying to get another currently open app window on the side.

Reproduction steps:
- On any desired page, open a LifeViewer popup
- Swipe up from the bottom to such an extent that it brings up the "all currently open apps which you can tap to switch to" menu
- Go back into the browser
- Attempt to interact with the viewer popup that you opened and find out that it's completely unresponsive, and that closing it and opening another one will also result in a popup that you can't interact with
- Refresh the page and note that interactivity is restored

iPad Air 4th generation, iPadOS 15.6.1. Not sure if this is reproducible on older devices that still have the home button.

----

On the topic of iOS-exclusive bugs, I still need to test the weird slowdown effect across other browsers. And the old bug with triangular selections having weird gaps for the two non-horizontal axes is still present on the iPad, despite looking completely fine on PC. Since you mentioned having an iPhone, can you test to see if the bug is present there? Just go to the Select tab, make a large selection and you should see an unsightly rhombic grid manifest within the selected zone like this:

Code: Select all

x = 1, y = 1, rule = B/SL
!

[muzik]

And finally, there appear to be some very slight gaps between hexagons. It's very slight on desktop devices but is still definitely visible if you're looking for it, especially at non-integer zoom levels. On the following pattern, Select All and then random filling at 100% density should reveal some gaps at the edges where living cells were prior to the rest being filled in:

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ STARTFROM 255 ZOOM 17.28288399183 ]]

An easier way to reproduce this can be done in multistate rules by setting two cell states to an identical or very similar color:

Code: Select all

x = 9, y = 9, rule = B/S0123456HHistory
9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA
$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA!
[[ ZOOM 20.1 COLOR ALIVE #FFFFFF COLOR kill #FFFFFF ]]

Code: Select all

x = 9, y = 9, rule = //7H
9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA
$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA!
[[ ZOOM 20.1 COLOR ALIVE #FFFFFF COLOR 6 #FFFFFF ]]

The left block is made of a single state, and the right block is two states with the same color. A subtle but very noticeable grid of gaps can be seen on the mixed states pattern, whereas the homogeneous block on the left appears completely smooth. I can reproduce this on multiple different devices, to varying extents.

I also tried doing the same with the triangular grid to highlight any potential flaws there. It's incredibly hard to see in this case, but using print screen and filling the right block with a new color highlights the borders between different, identically-colored cell states, whereas the left block is completely solid as expected:

Code: Select all

x = 9, y = 9, rule = //7L
9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA
$9A2.FAFAFAFAF$9A2.AFAFAFAFA$9A2.FAFAFAFAF$9A2.AFAFAFAFA!
[[ ZOOM 20.1 COLOR ALIVE #FFFFFF COLOR 6 #FFFFFF ]]

All three rectangular grid types are unaffected by this bug.

----

I also found a different bug while testing this: for Generations rules, changing the color of a state not present in the initial pattern will not cause that state's color to change even if it does end up being introduced via drawing.

Code: Select all

x = 2, y = 2, rule = //7
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = //7
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

Higher-range rules instead set state 1 to the color if the target state is present in the pattern, for some reason:

Code: Select all

x = 2, y = 2, rule = R1,C7,S,B
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = R1,C7,S,B
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

[R]History and [R]Super are unaffected:

Code: Select all

x = 2, y = 2, rule = LifeHistory
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = LifeHistory
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 2, y = 2, rule = LifeSuper
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = LifeSuper
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

As are ruletables:

Code: Select all

x = 2, y = 2, rule = JvN29
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = JvN29
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

And PCA rules:

Code: Select all

x = 2, y = 2, rule = PCA_4
2A$2A!
[[ COLOR 6 #FFFFFF ]]

Code: Select all

x = 6, y = 2, rule = PCA_4
2A2.2F$2A2.2F!
[[ COLOR 6 #FFFFFF ]]

[rowett]

for Generations rules, changing the color of a state not present in the initial pattern will not cause that state's color to change even if it does end up being introduced via drawing.

Higher-range rules instead set state 1 to the color if the target state is present in the pattern, for some reason:

Fixed, thanks!

[confocaloid]

Is there a way to LOOP so that the looping part begins at a generation other than 0? For example, is it possible to loop from T=10 to T=20, and then restart back to T=10? I tried the following, but it restarts to T=0 instead of T=10:

Code: Select all

#C [[ GPS 4 AUTOSTART STARTFROM 10 LOOP 21 ]]
x = 3, y = 3, rule = B3/S23
b2o$2o$bo!

[muzik]

Higher-range Generations rules appear to count dying cells as alive on the initial generation (the amount of deaths reported for generation 1 is correct, but contradicts the incorrect alive value from generation 0):

Code: Select all

x = 6, y = 2, rule = //7
2A2.2F$2A2.2F!
[[ SHOWGENSTATS ]]

Code: Select all

x = 6, y = 2, rule = R1,C7,S,B
2A2.2F$2A2.2F!
[[ SHOWGENSTATS ]]

[rowett]

Is there a way to LOOP so that the looping part begins at a generation other than 0? For example, is it possible to loop from T=10 to T=20, and then restart back to T=10?

Not currently - as you saw LOOP always goes back to generation 0.

[rowett]

Higher-range Generations rules appear to count dying cells as alive on the initial generation

Fixed, thanks!

[muzik]

To improve the usability of LifeViewer, could you add a mechanism to detect whether the user is running it on Chrome and without the flag enabled?

It's not possible to detect if the flag has been enabled, but I've added a warning if you're running a version of Chrome that is affected by the issue.

This appears to be a Chromium-wide issue, as the blank grid also happens on Brave 1.44.112 running Chromium 106.0.5249.119. I didn't see any warning messages before experiencing the bug.

[rowett]

This appears to be a Chromium-wide issue, as the blank grid also happens on Brave 1.44.112 running Chromium 106.0.5249.119. I didn't see any warning messages before experiencing the bug.

I've added Brave. Interestingly Edge (which also uses Chromium 106) does not have this issue.

[rowett]

Would it be possible to have the T button remain present in VIEWONLY patterns?

Yes, done.

[muzik]

Would it be possible to have the T button remain present in VIEWONLY patterns?

Yes, done.

Could the "Reset" button also be made accessible in viewonly mode? It can be used to restore the pattern to its initial region, zoom level, angle, tilt level, layer count and depth, and probably other things. The ability to restore those first two things is something I use fairly regularly in patterns even without evolving anything.

----

Turning on Rainbow for patterns and then using the reset button causes them to go entirely red for the first generation:

Code: Select all

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

Also, the buttons in the Display menu appear to overlap the background rectangle of the Display text itself.

[rowett]

Could the "Reset" button also be made accessible in viewonly mode? It can be used to restore the pattern to its initial region, zoom level, angle, tilt level, layer count and depth, and probably other things. The ability to restore those first two things is something I use fairly regularly in patterns even without evolving anything.

Use Settings->General->Restore View or hotkey V.

Turning on Rainbow for patterns and then using the reset button causes them to go entirely red for the first generation:

Fixed, thanks. It turned out that after Reset it didn't start raining until generation 1.

Also, the buttons in the Display menu appear to overlap the background rectangle of the Display text itself.

Fixed, thanks.

[confocaloid]

It seems that KILLGLIDERS changes the evolution of the 4g-to-5g reaction (the first one below) by deleting an incoming glider that would interact with the rest.

Below are reactions from Over-unity reaction - the first one fails:

Code: Select all

#C [[ KILLGLIDERS ]]
x = 65, y = 49, rule = B3/S23
obo$b2o$bo22$17bo$15bobo22bo$16b2o22bobo$40b2o19$63bo$62b2o$62bobo!

Code: Select all

#C [[ KILLGLIDERS ]]
x = 58, y = 59, rule = B3/S23
55bobo$55b2o$56bo42$13b2o$12bobo$14bo3$20b3o$20bo$21bo5$b2o$obo$2bo!

Code: Select all

#C [[ KILLGLIDERS ]]
x = 89, y = 66, rule = B3/S23
obo$b2o$bo18$39bo$37bobo$38b2o37$86bobo$87b2o$87bo2$85b2o$84b2o$86bo!

[rowett]

It seems that KILLGLIDERS changes the evolution of the 4g-to-5g reaction (the first one below) by deleting an incoming glider that would interact with the rest.

Fixed, thanks!

[muzik]

Is there any reason why buttons with non-text icons don't have shadows, but buttons with text do?

Code: Select all

x = 9, y = 5, rule = B3/S23
$bo3b3o$b3o2bo$2bo!
[[
COLOR UIFOREGROUND Orange
COLOR UIBACKGROUND LightCyan 
]]

I'd also like to see UI text shadows be made customizable independently of UIBACKGROUND. Ideally there should be one text shadow that corresponds to enabled buttons/UIFOREGROUND and another for disabled buttons/UILOCKED.

It also seems like the square grid's Grid button is incorrectly using the triangular grid's rectangular mode cells instead of proper squares now.

Code: Select all

x = 9, y = 5, rule = B3/S23
$bo3b3o$b3o2bo$2bo!

Code: Select all

x = 9, y = 5, rule = B3/S23L
$bo3b3o$b3o2bo$2bo!
[[ SQUARECELLS ]]

Code: Select all

x = 9, y = 5, rule = B3/S23H
$bo3b3o$b3o2bo$2bo!
[[ SQUARECELLS ]]

[erictom333]

When I open a pattern on my laptop (on Chrome), it doesn't show up.

[rowett]

When I open a pattern on my laptop (on Chrome), it doesn't show up.

See here for the workaround.

[rowett]

Is there any reason why buttons with non-text icons don't have shadows, but buttons with text do?

Added.

It also seems like the square grid's Grid button is incorrectly using the triangular grid's rectangular mode cells instead of proper squares now.

Fixed, thanks.

[muzik]

Is there any reason why buttons with non-text icons don't have shadows, but buttons with text do?

Added.

Usable buttons now have shadows, but greyed-out buttons do not have icon shadows, which is inconsistent with grey buttons with text. Can shadows be added to grey icons as well, or is the fact that it appears for gray text a bug and therefore something that should be removed?

[rowett]

greyed-out buttons do not have icon shadows

They do now.