Pattern viewer for forum threads

[unname4798]

"01 Apr" Seems suspicious...
Oh, it's actually April Fools!

[rowett]

Messing around with LifeViewer and I've seemingly found another way to put cells out of bounds without using PASTEDELTA or extreme torus shifts.

It's working as designed. In this case the bounded grid is inverted, so everything outside the box is inside, and vice-versa.

[muzik]

Checking prior 01 Apr postings, and this now seems to cause, if not an outright crash, then an unexpected and very long freeze once Play is pressed:

I was just looking for an example of a use of PASTET to fit a long single-channel recipe into LifeViewer's relatively small grid.

Here's a sample pattern that I'm fairly sure was working last September 23rd, but it isn't any more. Did something change that means I should update the script? I'm also seeing some other odd behavior here, like the viewer popping up mostly off the screen at first, then getting corrected if I resize the window.

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ MAXGRIDSIZE 14 ]]
[[ COLOR LABEL Orange ]]
[[ LABELT 0 10000 0 LABEL 90 0 2 "Snarkmaker\nSnarkmaker,\nmake me a Snark --" ]]
[[ COLOR LABEL Green ]]
[[ LABELT 0 2500 100 LABEL -10 80 2 "recipe to create an offset block" ]]
[[ LABELT 3000 6500 100 LABEL -10 80 2 "line up elbow with new block\n(two parts)" ]]
[[ LABELT 6700 8900 100 LABEL -10 80 2 "duplicate the elbow,\ncreate a 0-degree elbow" ]]
[[ LABELT 9000 10500 100 LABEL -10 80 2 "move 0-degree elbow to safe distance" ]]
[[ LABELT 11000 248000 100 LABEL -10 80 2 "0-degree slow salvo recipe" ]]
[[ LABELT 249000 251000 100 LABEL -10 80 2 "remove 0-degree elbow" ]]
[[ LABELT 251000 260000 100 LABEL -10 80 2 "push new elbow back\n(optional)" ]]
#C Define block pattern
#C [[ RLE block 2o$2o! ]]
#C [[ RLE glider 2o$obo$o! ]]
#C [[ PASTE block ]]
#C [[ PASTEMODE OR ]]
#C [[ RLE elbow_to_block 2o$obo$o25$28bo$27b2o$27bobo21$50b2o$50bobo$50bo21$74bo$73b2o$73bobo21$96b2o$95b2o$97bo31$129b2o$128b2o$130bo27$157b3o$157bo$158bo29$190bo$189b2o$189bobo21$212b2o$212bobo$212bo21$234b3o$234bo$235bo20$258bo$257b2o$257bobo22$281b2o$281bobo$281bo21$303b3o$303bo$304bo26$332b2o$332bobo$332bo39$372b3o$372bo$373bo56$431b2o$430b2o$432bo38$470b3o$470bo$471bo20$493b2o$493bobo$493bo37$532b2o$531b2o$533bo29$564bo$563b2o$563bobo22$586b3o$586bo$587bo27$616b2o$616bobo$616bo21$638b3o$638bo$639bo20$662bo$661b2o$661bobo21$684b2o$683b2o$685bo!
PASTE elbow_to_block 4 0 ]]
# elbow_to_block = 0 109 91 93 90 132 115 127 91 90 91 95 90 114 162 233 159 90 155 126 93 118 90 91 90 1114
#C [[ RLE PULL10.5fd
3o$o$bo25$28b2o$27b2o$29bo21$50b3o$50bo$51bo21$74b2o$74bobo$74bo21$97b
2o$96b2o$98bo21$119b3o$119bo$120bo21$142b3o$142bo$143bo20$165b2o$165bo
bo$165bo40$208bo$207b2o$207bobo21$230b2o$230bobo$230bo21$252b3o$252bo$
253bo27$281b3o$281bo$282bo20$304b2o$304bobo$304bo26$333bo$332b2o$332bo
bo!
PASTE PULL10.5fd 754 751 ]]
# PULL10.5fd = 4000 109 91 94 91 91 92 90 169 91 90 116 90 113
#C [[ RLE PULL3fd
b2o$2o$2bo25$28b2o$28bobo$28bo21$51b2o$50b2o$52bo21$74b2o$74bobo$74bo
21$97b2o$96b2o$98bo37$136b2o$135b2o$137bo21$158b3o$158bo$159bo20$182bo
$181b2o$181bobo22$205b2o$204b2o$206bo20$228bo$227b2o$227bobo21$250b2o$
250bobo$250bo33$285b2o$285bobo$285bo21$308b2o$307b2o$309bo24$333b3o$
333bo$334bo20$357bo$356b2o$356bobo21$379b2o$379bobo$379bo31$412b2o$
412bobo$412bo!
PASTE PULL3fd 1164 1161 ]]
# PULL3fd = 6000 109 91 93 91 156 91 91 94 90 91 140 91 103 91 91 132
#C [[ RLE elbow_duplicator
3o$o$bo25$28b2o$27b2o$29bo20$51bo$50b2o$50bobo22$73b3o$73bo$74bo20$97b
o$96b2o$96bobo21$119b2o$119bobo$119bo21$141b3o$141bo$142bo20$164b2o$
164bobo$164bo23$189b2o$189bobo$189bo21$211b3o$211bo$212bo20$234b2o$
234bobo$234bo35$270b3o$270bo$271bo22$294b3o$294bo$295bo20$317b2o$317bo
bo$317bo21$339b3o$339bo$340bo20$362b2o$362bobo$362bo21$385b2o$385bobo$
385bo37$424b2o$424bobo$424bo34$460b2o$460bobo$460bo!
PASTE elbow_duplicator 1754 1751 ]]
#C elbow_duplicator = 8000 109 90 93 91 91 90 90 100 90 90 146 96 90 90 90 92 156 144
#C [[ RLE PULL10.5fd_shallow_envelope
3o$o$bo25$28b2o$27b2o$29bo21$50b3o$50bo$51bo21$74b2o$73b2o$75bo21$96b
3o$96bo$97bo31$129b3o$129bo$130bo26$159bo$158b2o$158bobo24$184b2o$183b
2o$185bo20$207bo$206b2o$206bobo21$229b2o$229bobo$229bo21$252b2o$251b2o
$253bo21$274b3o$274bo$275bo20$297b2o$297bobo$297bo21$319b3o$319bo$320b
o36$358b2o$358bobo$358bo!
PASTE PULL10.5fd_shallow_envelope 2292 2289 ]]
#C PULL10.5fd_shallow_envelope 10000 109 91 93 91 132 115 102 90 91 91 91 90 90 154
#C a trailing "98" would mark a safe location for the first glider in a following copy of the recipe
#C [[ PASTET 10500 93 91 118 91 151 90 159 91 92 90 136 90 90 154 90 101 104 165 129 91 109 91 93 91 97 90 91 111 91 116 91 94 330 91 90 95 91 90 90 91 123 90 91 152 90 90 93 91 116 91 131 91 95 188 113 91 91 147 122 91 173 91 91 133 247 92 90 109 91 93 91 129 148 91 93 154 90 134 91 91 90 91 91 111 91 91 91 91 91 109 90 93 91 91 158 94 113 91 90 91 96 90 142 91 109 91 94 91 91 179 91 90 94 91 114 90 166 90 90 90 91 117 90 96 90 90 95 91 91 109 91 93 90 156 91 91 94 91 90 147 117 91 144 90 91 128 100 91 90 105 91 91 109 91 94 91 91 124 91 105 90 169 91 90 116 91 142 90 90 91 109 91 93 91 92 91 90 90 95 102 91 91 91 130 91 90 136 91 91 119 113 90 91 114 90 109 91 94 91 91 179 91 90 94 91 102 91 151 90 90 101 90 91 125 184 90 90 90 109 91 94 91 91 179 91 90 94 91 102 91 151 90 90 101 90 91 125 184 90 90 90 109 91 93 90 140 150 132 212 103 90 98 90 148 90 90 91 91 91 119 101 108 90 91 91 119 90 109 91 94 91 90 99 90 112 90 91 105 90 121 118 103 90 144 117 95 91 109 91 93 91 92 91 90 90 95 102 91 91 91 130 91 90 136 91 91 119 113 90 91 114 91 109 90 93 91 91 181 90 95 110 114 100 160 90 143 91 119 90 106 129 109 91 93 91 92 91 90 90 162 91 91 90 129 91 113 90 90 90 90 109 91 93 90 140 150 142 91 90 111 91 91 193 97 91 91 155 90 98 90 91 93 91 151 90 139 180 103 115 167 91 120 139 135 91 91 170 109 91 93 90 155 106 91 121 90 90 91 137 90 232 90 91 91 94 90 171 90 91 103 102 109 91 93 91 137 90 166 91 102 90 104 91 96 96 91 90 90 90 166 90 90 93 90 91 109 91 94 91 91 124 91 105 91 119 91 132 99 90 90 90 150 160 116 91 91 91 90 96 90 90 109 91 93 90 171 90 90 91 90 91 90 91 129 144 90 90 120 90 91 91 169 90 91 109 91 93 91 118 90 91 91 91 104 219 91 135 105 154 90 91 164 91 132 90 90 140 94 93 90 96 90 90 91 149 90 90 161 100 109 91 93 91 92 91 90 90 124 91 142 90 90 91 91 112 90 102 102 103 90 90 90 117 112 90 189 90 90 109 91 93 91 92 91 90 90 162 91 91 90 129 91 113 90 90 90 90 109 91 93 91 92 90 97 91 116 91 145 90 91 98 90 90 188 91 91 91 90 115 91 109 91 93 91 97 91 90 91 120 91 117 91 123 90 118 91 146 110 160 90 109 91 93 90 129 148 90 93 90 143 96 92 90 165 90 118 90 90 91 91 109 91 94 91 91 93 90 158 90 91 90 90 116 104 109 91 94 91 91 167 90 90 91 95 90 90 148 90 151 90 90 136 134 155 115 103 91 109 91 93 90 155 106 91 121 90 90 91 137 90 232 90 91 91 94 90 171 90 91 103 101 109 91 94 91 91 136 91 91 90 168 90 90 110 90 90 93 91 111 91 91 90 132 91 91 93 91 118 90 137 91 173 93 158 90 90 90 118 90 91 90 151 154 167 91 133 90 119 178 155 90 90 90 109 91 94 91 91 95 91 90 93 218 142 90 91 161 90 138 90 162 91 90 140 95 109 109 91 93 91 92 91 98 201 91 129 90 90 90 90 90 103 90 108 90 104 90 109 91 93 90 129 148 90 93 90 143 96 92 90 165 90 118 90 90 91 91 109 91 94 91 91 179 91 90 94 91 111 90 90 90 171 91 110 91 154 90 132 91 109 91 94 91 91 124 90 144 90 90 90 165 119 90 104 90 100 90 90 91 109 91 93 91 92 91 90 90 162 91 91 90 129 91 113 90 90 90 91 109 91 94 91 91 95 91 90 93 218 172 90 90 90 116 112 341 107 106 90 163 91 90 109 91 93 90 169 90 91 103 91 133 90 90 91 91 90 110 91 93 90 112 171 90 109 91 94 91 91 171 91 90 113 90 97 114 90 105 90 139 90 113 90 106 98 121 90 109 91 94 91 91 124 90 142 90 90 146 91 153 90 102 91 152 108 97 91 109 91 94 91 91 124 90 170 90 90 91 90 99 91 90 91 110 121 161 117 115 137 90 91 90 109 90 93 91 91 128 90 139 91 90 97 91 124 157 91 90 90 129 144 91 91 147 130 91 90 90 91 90 140 90 92 90 90 109 91 93 90 156 91 91 102 91 91 90 90 106 91 166 90 125 91 90 126 91 109 91 94 91 91 179 91 90 94 91 102 91 151 90 90 101 90 91 125 184 90 90 90 93 91 151 90 139 180 103 115 167 91 120 139 135 91 91 170 109 90 93 91 91 128 90 139 91 90 97 91 124 157 91 90 90 129 144 91 91 147 130 91 90 90 91 90 140 90 92 90 90 109 91 93 91 145 215 114 91 121 91 150 91 91 153 91 141 90 91 91 90 123 91 109 90 101 169 213 133 195 90 132 143 91 139 138 158 151 99 91 108 99 91 90 91 91 90 91 131 91 109 91 93 90 156 91 91 96 132 91 91 106 91 90 119 185 91 96 90 132 90 91 90 142 109 91 94 91 91 124 90 170 90 90 91 90 99 91 90 91 110 121 161 117 115 137 90 91 90 109 91 93 90 155 106 91 121 90 90 91 137 90 232 90 91 91 94 90 171 90 91 103 102 109 91 93 90 129 148 91 102 91 91 145 178 91 115 90 90 91 104 90 90 92 249 90 90 91 109 91 94 91 90 152 91 90 91 117 90 91 111 91 91 118 90 145 90 100 116 90 90 99 90 109 91 94 91 91 128 126 90 161 151 90 109 91 90 90 94 144 106 90 94 90 90 90 109 91 94 91 91 124 91 105 90 169 91 90 116 91 142 90 90 91 109 91 93 90 140 150 108 91 90 111 91 91 194 98 90 169 90 109 91 94 91 91 141 90 171 90 155 90 111 91 90 130 90 91 90 97 90 90 109 91 94 91 91 121 90 90 90 90 90 90 99 90 165 119 90 106 90 90 91 109 91 94 91 91 93 90 95 90 113 90 99 90 156 90 90 90 138 170 109 91 94 91 91 92 90 169 90 90 90 107 90 90 91 90 95 91 91 109 91 93 90 171 90 90 91 90 91 90 91 129 144 90 90 120 90 91 91 169 90 91 109 90 95 245 90 131 135 90 90 154 90 91 91 91 111 90 90 91 91 128 91 96 91 109 91 94 91 91 124 91 105 91 119 91 132 99 90 90 90 150 160 116 91 91 91 90 96 90 91 93 91 116 91 151 90 109 111 127 91 113 91 169 186 90 90 158 91 90 90 90 117 91 160 90 91 96 90 90 91 109 91 94 91 90 95 91 90 147 167 90 160 90 160 104 90 90 91 91 101 139 91 90 136 129 90 109 91 93 91 123 91 118 90 91 108 91 91 90 90 90 90 143 91 92 177 129 101 167 91 90 90 91 130 127 90 137 91 93 90 91 91 94 229 107 91 90 104 91 91 101 91 91 93 90 119 90 133 90 91 93 145 91 132 91 109 91 93 91 137 90 166 91 102 90 104 91 96 96 91 90 90 90 166 90 90 93 90 90 109 90 93 91 91 128 90 139 91 90 97 91 124 157 91 90 90 129 144 91 91 147 130 91 90 90 91 90 140 90 92 90 91 123 270 90 125 90 90 90 94 137 123 90 145 136 90 91 100 91 105 91 153 91 90 145 155 109 91 93 91 92 91 139 90 91 91 90 96 130 97 91 164 90 97 91 90 91 114 90 90 118 90 90 123 270 90 125 90 90 90 94 137 123 90 145 136 90 91 100 91 105 91 153 91 90 145 155 109 90 93 91 91 148 91 90 151 90 91 163 108 151 112 144 90 149 90 90 99 90 109 91 94 91 91 124 91 126 91 140 162 148 90 90 119 90 91 109 91 93 91 155 106 91 91 96 90 90 91 108 90 156 90 90 120 90 112 91 99 91 109 91 93 91 129 148 91 93 154 90 134 91 91 90 91 91 111 91 91 91 91 90 109 91 93 91 129 148 91 93 154 90 134 91 91 90 91 91 111 91 91 91 91 90 109 91 93 91 129 149 91 90 90 142 219 90 99 91 109 115 92 185 91 109 90 93 91 91 142 90 98 90 91 125 114 127 90 111 90 109 91 93 91 130 91 90 134 90 90 103 122 156 112 90 183 117 91 152 141 90 98 90 91 93 91 116 91 131 91 95 188 113 91 91 147 122 91 173 91 91 133 247 92 91 109 91 93 90 156 91 91 94 91 90 147 117 91 144 90 91 128 100 91 90 105 91 91 93 91 116 91 106 91 155 90 106 90 167 90 90 91 148 123 111 155 91 105 90 90 92 90 124 90 91 109 91 94 91 91 95 91 90 97 143 171 90 105 90 91 144 91 90 90 90 94 90 90 90 109 91 93 91 92 90 158 90 94 270 172 130 90 91 91 96 90 90 147 91 109 91 93 91 92 90 162 90 129 91 91 91 90 137 99 90 90 111 91 153 90 90 90 109 91 95 125 128 90 90 90 172 90 90 90 119 91 113 247 90 144 90 140 90 109 90 93 91 90 95 91 91 139 90 147 90 90 99 117 91 157 91 126 90 90 91 160 90 91 91 91 111 90 90 113 90 91 109 91 94 91 90 99 90 112 90 91 105 90 121 118 103 90 144 117 95 91 109 91 94 91 91 124 90 144 90 90 90 165 119 90 104 90 100 90 90 90 109 91 94 91 91 179 91 90 94 91 114 90 166 90 90 90 91 117 90 96 90 90 95 91 91 109 91 94 91 91 95 91 90 150 90 140 90 91 90 171 90 118 91 111 90 104 91 109 91 93 91 97 91 90 91 120 90 95 91 143 90 90 90 90 91 109 90 95 245 90 95 90 123 91 90 115 142 91 109 91 94 91 91 124 91 90 91 91 90 91 90 141 90 172 91 161 90 169 228 90 109 91 94 91 91 93 90 91 91 90 100 90 94 90 108 90 91 91 119 1114 109 91 95 113 90 134 90 1114 109 90 93 91 90 95 91 91 138 157 96 90 120 91 97 107 90 90 93 188 109 90 93 91 90 95 91 91 138 157 96 90 120 91 97 107 90 90 93 188 109 90 93 91 90 95 91 91 138 157 96 90 120 91 97 107 90 90 93 188 109 91 93 91 92 90 97 91 116 91 93 115 90 91 130 ]]
#C a trailing "90" would mark a safe location for the first glider in a following copy of the recipe
[[ PASTE glider 254 250
X 40 Y 10 Z 2 STEP 9
T 11000
T 11001 STEP 64
T 249000
T 249001 STEP 9
T 251000 ]]

Something small, but for completeness: can mouse buttons be included in Help > Keys?

[rowett]

Checking prior 01 Apr postings, and this now seems to cause, if not an outright crash, then an unexpected and very long freeze once Play is pressed

Fixed, thanks.

[muzik]

Is it supposed to be possible to use the middle mouse button as though it were the left mouse button? It moves the grid, makes a selection and draws cells in much the same way.

The right mouse button's behaviour is strange to me: it opens a context menu as though the viewer was an image, but sometimes it also becomes possible to drag/draw/select as though it were the left button.

[rowett]

Is it supposed to be possible to use the middle mouse button as though it were the left mouse button?

Yes, any button will do.

The right mouse button's behaviour is strange to me: it opens a context menu as though the viewer was an image, but sometimes it also becomes possible to drag/draw/select as though it were the left button.

If clicked it's the context menu where you can grab a screenshot etc.
If held it's the same as any other button.

[muzik]

Is it supposed to be possible to use the middle mouse button as though it were the left mouse button?

Yes, any button will do.

From my testing:
- mouse buttons 1, 2 and 3 all work identically (besides the context menu for the second button)
- mouse buttons 4 and 5 are not recognised, and will move the browser one page back or forward, even if the viewer is in focus
- mouse buttons 6, 7 and 8 (supported by macOS and Linux) do not appear to be recognised at all

I'm yet to check any mouse buttons above 8 as this will probably require rebinding things or using a script to send arbitrary inputs.

[confocaloid]

OCADOTY2025 candidate, the first known spaceship in any cellular automaton with range-0 Moore neighbourhood (namely B/S012345678):

Code: Select all

x = 43, y = 60, rule = B/S012345678
16b3o2bo5bo3b2o$17bo3bo4b3o3bo$b2o2bo5b2o4bo3b3o3bo4b2o$2o3bo2bo2b2o2b
o13bo$bo3bo2bo2bo3bo7bo4b2o$5bo2bo5b2o2bobo2b2o4bo$5bo2b2o4bo3b3o3b2o
3bo16$15b2o12b2o$15bo2bo10bo2bo$15bo3bo9bo3bo$16bo2b2o9bo2b2o$16bo2b2o
9bo2b2o2$16b3ob3o7b3ob3o$17bo5b2o6bo5b2o$15b3obobo7b3obobo$15bobo5bob
2o2bobo5bob2o$15bo2b2obo3bo3bo2b2obo3bo$17b2o4b2o6b2o4b2o$19bo13bo$15b
2o6bo5b2o6bo$19b2obobo8b2obobo$16bo5bob3o3bo5bob3o$16b2o3bo2bo2bo2b2o
3bo2bo2bo$15bo5b2obo4bo5b2o2b3o$16bobo2bo3bo3b2obo2bo4b3o$18bob2o2b2o
6bob2o6bo$18bo3b4o3b2obo2b2o3b3o$19bo9bobobo2bo2bo$19bo3bo4b2o3bo5bo$
21b3o4b3o2bo4bo$25bo2b2o9bo$26bo3bo6bo$24b3o2bo6bo$36b3o2$28bo$29bo6bo
$27b3o5bo$35b3o2$31bo$32bo2bo$30b3obo$34b3o!

[b-engine]

It's working as designed. In this case the bounded grid is inverted, so everything outside the box is inside, and vice-versa.

I know this is April Fools joke, but could this be made into an actual feature?
Well, by setting the bounded grid size to negative:

Code: Select all

x = 16, y = 16, rule = B3/S23:T-16,-16
bo30bo$2bo$3o30$o!

[confocaloid]

First, at least that wouldn't be anything "negatively sized", so the syntax would have to be different to (attempt to) reduce resulting unnecessary confusion.

Second, I think it isn't currently well-defined, and would be counterintuitive if defined. Consider the following pattern and imagine that the opposite edges of the 20-by-20 square in the middle are "glued together". It seems reasonable to expect that the white cell (LifeHistory state 3) would have eight Moore neighbours (LifeHistory state 5). However, it is unclear which of the blue cells (LifeHistory state 2) should be counted as neighbours of the red cell (LifeHistory state 4):

Code: Select all

#C [[ GRID ]]
x = 38, y = 25, rule = LifeHistory
35.A$33.A3.A$3B17.3B9.A$B20FDB9.A4.A$BF18.F2B9.5A$.F18.F$.F18.F$.F18.
F$.F18.F$.F18.F$.F18.F$.F18.F$EF18.F2E$EF18.FCE$EF18.F2E$.F18.F$.F18.
F$.F18.F$.F18.F$.F18.F$.F18.F$.F18.F$B20F2B$3B17.3B$3B17.3B!

Overall, it looks like any attempt to implement some form of this would mean a shift towards cellular automata on arbitrary graphs. And I think Golly/LifeViewer are unlikely to support CA on arbitrary graphs (better to focus on a reasonably small set of features that can be expected to interact with each other in understandable ways).

It's working as designed. In this case the bounded grid is inverted, so everything outside the box is inside, and vice-versa.

I know this is April Fools joke, but could this be made into an actual feature?
Well, by setting the bounded grid size to negative:

Code: Select all

x = 16, y = 16, rule = B3/S23:T-16,-16
bo30bo$2bo$3o30$o!

[muzik]

This [R]History bounding box issue was recently fixed but has returned:

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

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

As has this:

Code: Select all

x = 3, y = 5, rule = Life
2o$obo$2bo$obo$2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 3 2 AUTOIDENTIFY ]]

Code: Select all

x = 3, y = 5, rule = LifeHistory
2o$obo$2bo$obo$2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 3 2 AUTOIDENTIFY ]]

I've reported this difference between LifeViewer Standard and LifeViewer Pro before, but it still seems to exist. Pro is incorrectly setting dead cells to state 63 instead of state 0 here, unlike what happens in the standard engine. This probably impacts performance as well since those history cells have to be ticked.

Code: Select all

x = 7, y = 5, rule = B3/S23
3b2o$bo4bo$o$o5bo$6o!
[[ STARTFROM 64 HISTORYSTATES 0 LAYERS 10 GRID ZOOM 16 X -16 ]]

Strange behaviour can be seen here if we use the Step Back button:

Code: Select all

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

Something funny appears to be going on with births/deaths labels when something crosses a bounded grid border:

Code: Select all

x = 3, y = 3, rule = B3/S23:T20,20+1
o$obo$2o!
[[ LABEL -0.5 -13 16 "#F #E" ]]

[confocaloid]

This [R]History bounding box issue was recently fixed but has returned: [...]
As has this: [...]

It works correctly. There is a nonzero cell to the left of the gun (LifeHistory state 2). All nonzero cells must be included into the bounding box. Thisi matches how Golly handles bounding boxes, selections, "fit pattern", etc.

It seems like it was recently temporarily broken and didn't match the expected functionality / Golly, but was fixed later.

Related discussion:
viewtopic.php?p=208966#p208966
viewtopic.php?p=208874#p208874
viewtopic.php?p=208821#p208821
viewtopic.php?p=208809#p208809
viewtopic.php?p=208302#p208302

[muzik]

It works correctly. There is a nonzero cell to the left of the gun (LifeHistory state 2). All nonzero cells must be included into the bounding box. Thisi matches how Golly handles bounding boxes, selections, "fit pattern", etc.

It seems like it was recently temporarily broken and didn't match the expected functionality / Golly, but was fixed later.

If that's the case, why is the history cell counted by the KILLGLIDERS case but not the eaters case?

As I see it, Identify should only care about cells which are actually involved in the behaviour of the oscillator. State 2 is an annotation state and therefore should be ignored.

[confocaloid]

It works correctly. There is a nonzero cell to the left of the gun (LifeHistory state 2). All nonzero cells must be included into the bounding box. Thisi matches how Golly handles bounding boxes, selections, "fit pattern", etc.

It seems like it was recently temporarily broken and didn't match the expected functionality / Golly, but was fixed later.

If that's the case, why is the history cell counted by the KILLGLIDERS case but not the eaters case?

As I see it, Identify should only care about cells which are actually involved in the behaviour of the oscillator. State 2 is an annotation state and therefore should be ignored.

You didn't clarify what "this [R]History bounding box issue" was intended to mean. The most obvious recent issue with [R]History bounding boxes was that selections/bounding boxes incorrectly excluded state-2 cells.

As for "Identify", there is no "Identify" in Golly. However, there is a script "oscar.lua" in Golly. The script "oscar.lua" (correctly!) refuses to identify the following pattern:

Code: Select all

x = 12, y = 9, rule = LifeHistory
10.A$11.A$9.3A6$B!

- even though it is just a glider and an additional state-2 LifeHistory cell. There are no two generations matching each other.
It also (correctly!) refuses to identify "the glider and nothing else" in LifeHistory, because the glider is no longer a spaceship in LifeHistory. It is a growing pattern. It grows by leaving state-2 cells behind it.

[R]History defines a multistate cellular automaton, different from [R].

As I see it, tools such as LifeViewer's "Identify" or "oscar.lua" in Golly should avoid making any distinctions between types of nonzero cells. All nonzero cells need to be taken into account.
(Also: are stator cells "actually involved in the behaviour of the oscillator"? How about those stator cells that have at least one neighbour in the rotor? How about a faraway block of alive cells?)

[muzik]

As I see it, tools such as LifeViewer's "Identify" or "oscar.lua" in Golly should avoid making any distinctions between types of nonzero cells. All nonzero cells need to be taken into account.

This may be correct from a particularly technical standpoint, but to me this seems overly pedantic and handling [R]History in such a way with Identify would make it less useful. It may be a multistate rule, but (excluding state 6, which is special-cased in a way that works) the rule is still a 2-state rule with annotation states for convenience. Certainly there are cases where things should be handled exactly as they are, but when using tools such as Identify to understand pattern behaviour, treating history trail cells as any other dead cell is going to yield more useful results 99% of the time.

[confocaloid]

[...] Certainly there are cases where things should be handled exactly as they are, but when using tools such as Identify to understand pattern behaviour, treating history trail cells as any other dead cell is going to yield more useful results 99% of the time.

[R]History defines a multistate cellular automaton, different from the plain two-state [R].

At least, whether or not "Identify" can distinguish LifeHistory state 2 from LifeHistory state 0, that shouldn't affect bounding boxes or selections in any way. (Every nonzero cell is included in the bounding box and in the "Select All" selection. It doesn't matter if it is a single faraway state-2 cell, or if it is a nearby cluster of state-6 cells, or any other possibility. If the cell is added accidentally, then the actual fix is to change the pattern to clean the unwanted cell. However, the cell might be added deliberately, and in such cases it should be taken into account. Software cannot "guess" whether cells were added deliberately, so it should simply take the given input pattern and process it as is.)

I definitely would prefer it if "Identify" also acknowledged existence of state-2 cells. It is much more natural, and much more consistent, to avoid making any distinctions between different nonzero cells, and count them all. If a pattern produces an unbounded number of state-2 cells, then it is not a spaceship anymore. If you want to see it differently, you can convert the pattern from LifeHistory to plain B3/S23 before running "Identify".

Apart from purely cosmetic adjustments (such as displaying names of cellstates), trying to make distinctions between "types" of nonzero cellstates in a multistate cellular automaton is likely to lead to inconsistencies and arbitrary distinctions, which are biased towards a specific viewpoint/interpretation. It is simpler and more consistent to count all nonzero cells.

[b-engine]

I definitely would prefer it if "Identify" also acknowledged existence of state-2 cells. It is much more natural, and much more consistent, to avoid making any distinctions between different nonzero cells, and count them all. If a pattern produces an unbounded number of state-2 cells, then it is not a spaceship anymore. If you want to see it differently, you can convert the pattern from LifeHistory to plain B3/S23 before running "Identify".

Apart from purely cosmetic adjustments (such as displaying names of cellstates), trying to make distinctions between "types" of nonzero cellstates in a multistate cellular automaton is likely to lead to inconsistencies and arbitrary distinctions, which are biased towards a specific viewpoint/interpretation. It is simpler and more consistent to count all nonzero cells.

I disagree.

In my opinion, a spaceship should be a spaceship even if it leaves trails of cells that's exactly the same as off cells, or else LifeHistory would be explosive.
Treating a basically off cell as an on cell isn't "much more natural and consistent".

If something works, leave it as it is.

[confocaloid]

[...] If something works, leave it as it is. [...]

oscar.lua in Golly works. It doesn't treat state-2 cells "the same way" as state-0 cells. That's as expected. If I want to avoid history trails, I will convert to plain two-state CA before running the script.

[...] In my opinion, a spaceship should be a spaceship even if it leaves trails of cells that's exactly the same as off cells, or else LifeHistory would be explosive. [...]

The claim "exactly the same as off cells" is incorrect. In LifeHistory, the intent of state-2 cells is to denote off cells that were on at some time earlier (or were already present in generation 0). In LifeHistory, the intent of state-0 cells is to denote off cells that were never on. They are different.

In fact, soups in LifeHistory do produce very many infinite growth patterns, most of which would be gliders if the pattern was converted to plain B3/S23 before evolving it. (Whether or not it's "explosive" is up to a technical definition of explosive CA.)

[rowett]

This [R]History bounding box issue was recently fixed but has returned

This will be fixed in the next build.

Here is how LifeViewer handles [R]History rules:

• For editing they are treated as multi-state rules.
  • Functions like Select All, Shrink Selection, Save Pattern etc., will include all states.
• For iteration odd-numbered states are considered alive, and even-numbered states dead.
  • This is also true for the Population calculation.
• For Identify they are treated as two-state rules plus state 6:
  • This means that states 2 and 4 are not part of the Identify bounding box.

[muzik]

Apart from purely cosmetic adjustments (such as displaying names of cellstates), trying to make distinctions between "types" of nonzero cellstates in a multistate cellular automaton is likely to lead to inconsistencies and arbitrary distinctions, which are biased towards a specific viewpoint/interpretation. It is simpler and more consistent to count all nonzero cells.

Is it necessarily a bad thing to be biased toward a specific viewpoint/interpretation? I would argue that bias was itself present when LifeHistory was first created - its intent was to behave exactly as Life did, with annotation states existing exclusively to serve as a visual aid. Giving state 2 an equal weight to state 1 in pattern treatment seems misguided to me, even if technically right.

Also note that LifeViewer 2-state rules have 128 states to begin with, since 64 states are used for tracking alive cells and 63 for dead cells, alongside state 0 for the background. Should they then be handled as 128-state rules, or is this an absurd proposition as these "bonus" states only exist to indicate extra information? If so, when exactly does this logic fall apart when applied to [R]History instead of [R]Standard, as its only difference from [R]Standard is also a matter of annotation (discounting the logistical mess that is state 6)?

The following may be a matter of semantics, but this is LifeViewer we're talking about - this started out as a program for displaying patterns, rather than something for in-depth technical analysis (for which we have Golly). Obviously LifeViewer has very much outgrown the scope of being a simple pattern display tool, which I'd argue is very much for the better and I definitely prefer it in its current state, but it certainly still isn't an in-depth technical analysis tool like Golly and accompanying scripts are - and Golly is probably what I'd use when accounting for "technically"s like this. If I wanted to match Golly's behaviour with [R]History Identify, I'd probably define a dedicated @RULE file for use in LifeViewer. The way things work currently with native [R]History support match my use cases, and I'd argue those of most others as well.

If anything, I'd argue that @RULE files should be able to communicate information about the significance of cells in and of themselves. Here's an annotated Life variant that has multiple history trail cells for all cell death population counts. Note that once every state-1 cell dies, playback continues, and the population doesn't reach 0. If we could assign a population value to each cell state in the rule table, we could have LifeViewer behave in a more expected way.

Code: Select all

x = 3, y = 7, rule = LifeNoted
.A$3A2$.A2$3A$.A!
[[ SHOWGENSTATS ]]

[rowett]

Something funny appears to be going on with births/deaths labels when something crosses a bounded grid border:

Births and Deaths are not calculated correctlly with Bounded Grids. You'll note they are not displayed elsewhere (Population Graph, Generation Statistics, etc.).

[muzik]

Here is how LifeViewer handles [R]History rules:

• For editing they are treated as multi-state rules.

One thing to point out is that unlike multistate rules, [R]History does not have a separate multistate random fill button in the select menu, much like how 2-state rules don't:

Code: Select all

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

Code: Select all

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

[R]Super and [R]Investigator do have such a button:

Code: Select all

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

Code: Select all

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

I don't actually think having a multistate random fill in the latter two rules is useful, since the extra states are effectively annotational much like [R]History states, so it could be removed and the only random fill option available would be 2-state, as in [R]History.

[confocaloid]

[...] Also note that LifeViewer 2-state rules have 128 states to begin with, since 64 states are used for tracking alive cells and 63 for dead cells, alongside state 0 for the background. Should they then be handled as 128-state rules, or is this an absurd proposition as these "bonus" states only exist to indicate extra information? If so, when exactly does this logic fall apart when applied to [R]History instead of [R]Standard, as its only difference from [R]Standard is also a matter of annotation (discounting the logistical mess that is state 6)? [...]

I think your logic falls apart because (as far as I understand) the part "LifeViewer 2-state rules have 128 states to begin with" means an implementation detail of LifeViewer.
In contrast, LifeHistory is defined as a multistate cellular automaton with specific rules. It is no longer merely an implementation detail or "a matter of annotation". Instead, it is part of the design of the CA. Either some software tool implements LifeHistory correctly, or it does not.

When the user provides a two-state pattern in a two-state cellular automaton, it should be treated as such.
When the user provides a pattern in a multistate cellular automaton, it should be treated as such.

[...] If I wanted to match Golly's behaviour with [R]History Identify, I'd probably define a dedicated @RULE file for use in LifeViewer. [...]

That sounds like a very good argument for ensuring that LifeViewer correctly implements [R]History in the exact same way as LifeHistory was originally designed and defined, and in the exact same way how Golly does it. (Fixing any inconsistencies and bugs.)

It shouldn't be necessary to define a separate @RULE file to duplicate the exact same CA design as was already implemented in [R]History
It is unreasonable to ask the user to do that kind of duplication.

[...] If anything, I'd argue that @RULE files should be able to communicate information about the significance of cells in and of themselves. [...]

That leads to many other headaches, nontrivial questions, arbitrary decisions, etc. Again, it is simpler and more consistent to keep the current handling (count all nonzero cells). The user can write a Lua script to do something different from the default processing.

[b-engine]

oscar.lua in Golly works. It doesn't treat state-2 cells "the same way" as state-0 cells. That's as expected. If I want to avoid history trails, I will convert to plain two-state CA before running the script.

I don't expect oscar to treat state-2 cells as "on" - it's tedious to convert LifeHistory into the two-state rule.

The claim "exactly the same as off cells" is incorrect. In LifeHistory, the intent of state-2 cells is to denote off cells that were on at some time earlier (or were already present in generation 0). In LifeHistory, the intent of state-0 cells is to denote off cells that were never on. They are different.

Yes, but state-2 are still off cells. There's no reason why an off cell variant should be treated as on.

In fact, soups in LifeHistory do produce very many infinite growth patterns, most of which would be gliders if the pattern was converted to plain B3/S23 before evolving it. (Whether or not it's "explosive" is up to a technical definition of explosive CA.)

No. There's no reason a common infinite growth exists in a variant of a chaotic rule with very few natural infinite growths, which the former adds literally just different annotations of on and off cells and a gray cell that make any nearby cell dies.

rowett: Inappropriate EDIT removed.

[rowett]

This is a thread about LifeViewer. I've documented how LifeViewer handles [R]History rules.

No need for futher debate on this point in this thread.