Pattern viewer for forum threads

For discussion directly related to ConwayLife.com, such as requesting changes to how the forums or home page function.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

rowett wrote: February 28th, 2025, 7:28 am
muzik wrote: February 27th, 2025, 6:39 pm Is it possible to customize the colours of age states other than just using a single gradient?
It's possible in the engine but there's no way to specify the custom colours at the moment. The engine doesn't know anything about gradients - it's just given a palette of colours to use.

It will need a naming convention for the alive states that isn't the state numbers. Thoughts?
"dying 1", "dying 2", "dying 3", ... "dying n" are already the names we use for cell states from DYING to DYINGRAMP, correct? In that case, it only seems logical to me to extend that system to "alive 1", "alive 2", ... "alive 64" and "dead 1", "dead 2", ... "dead 64" for historical alive and dead cells.

I'm not sure if these names should only be visible when State Number is enabled, and instead just displayed as "alive" and "dead" as is currently done when the option is disabled. Or perhaps it could be tied to another option such as "Info Bar", since it's used to obtain information for scripting.

Perhaps a naming system for cell states of the neighbourhood shader - and possibly rainbow shader - would also be of use to implement. Neighbourhood themes are still something needed at some point, after all.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

Depending on what the viewer is scaled to, the map key background can extend lower than expected:
IMG_6609.jpeg
IMG_6609.jpeg (685.32 KiB) Viewed 1163 times
In the following viewers, in Help > Info > Cells, the first and third examples have lines for Dead and DeadRamp. The second, however, omits these lines. All three of these functionally do the same thing, so consistent behaviour would be expected, and it may be preferable to omit these lines in all three cases since they don't carry any important information.

Code: Select all

x = 1, y = 3, rule = B3/S23
o$o$o!
[[ THEME Mono ]]

Code: Select all

x = 1, y = 3, rule = B3/S23
o$o$o!
[[ THEME Mono HISTORYSTATES 0 ]]

Code: Select all

x = 1, y = 3, rule = B3/S23
o$o$o!
[[ THEME Mono SHADER Basic ]]
Due to how rules with only one dying state work, I'd expect the value shown for "Deaths" to match the number of dying cells present in the pattern. This works correctly in the range-1 algorithm, but does not for the general-range algorithm: despite there being four deaths, only two dying cells are present.

Code: Select all

x = 2, y = 2, rule = /2/3
BA$BA!
[[ MAXGRIDSIZE 9 X 256 STARTFROM 253 SHOWGENSTATS ]]

Code: Select all

x = 2, y = 2, rule = R1,C3,S,B2
BA$BA!
[[ MAXGRIDSIZE 9 X 256 STARTFROM 253 SHOWGENSTATS ]]
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

Both pull requests on Github should be ready at this point to be accepted in.

version.txt appears to be missing a bullet for build 1200 and line breaks after builds 1081 and 1216.

In LifeViewer Pro specifically (latest available build is 1260), AUTOFIT will do a very strange bouncing motion when used on Generations spaceships. 2-state spaceships are not affected. Also, pausing will cause the viewer to zoom out to view all the history cells, which it is not supposed to do as there isn't a specified history fit command. 2-state is also not affected by this.

Code: Select all

x = 2, y = 4, rule = B2/S
o$bo$bo$o!
[[ AUTOFIT ]]

Code: Select all

x = 3, y = 4, rule = /2/3
BA$.BA$.BA$BA!
[[ AUTOFIT ]]
For the general-range algorithm, Generations patterns do not do this horrible bounce. However they still zoom out when paused, which is wrong. The 2-state case is not affected by this issue.

Code: Select all

x = 2, y = 4, rule = R1,C2,S,B2
o$bo$bo$o!
[[ AUTOFIT ]]

Code: Select all

x = 3, y = 4, rule = R1,C3,S,B2
BA$.BA$.BA$BA!
[[ AUTOFIT ]]
This evolves incorrectly in both LifeViewer Standard and LifeViewer Pro - in Standard this acts as a still life and in Pro it dies:

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,2,4,6,8,B0,2,4,6,8
o!
Expected behaviour can be seen if we use the range-1 algorithm instead:

Code: Select all

x = 1, y = 1, rule = B02468/S02468
o!
Identify gives this too large of a bounding box, which also visibly affects the period map and frequency map:

Code: Select all

x = 179, y = 184, rule = B36/S23History
131.4B$130.4B$129.4B$128.4B$127.4B$126.4B$125.4B$124.4B$123.4B$122.4B
$121.4B$120.4B$119.4B$118.4B$117.4B$116.4B$115.4B$114.4B$113.4B$112.4B
$111.4B$110.4B$109.4B$108.4B$107.4B$106.4B$105.4B$104.4B$103.4B$102.4B
$101.4B$100.4B$99.4B$98.4B$97.4B$96.4B$95.4B$94.4B$93.4B$92.4B$91.4B$
90.4B69.B$89.4B69.2B$88.4B69.3B$87.4B69.4B$86.4B2.B66.4B$85.4B2.3B64.
4B$84.4B2.5B62.4B$83.4B2.7B60.4B$82.4B2.9B58.4B$80.5B4.7B58.4B$78.9B2.
7B57.4B$77.19B56.4B$77.20B54.4B$77.2C20B51.4B$75.4BC16BC3B49.4B$74.B2C
B2C15B3C2B48.4B$74.B2C2B2C13B2CB2C2B46.4B$73.C6B3C10B2CB2C5B43.4B$71.
2BCBC5BCBC8B2CB2C7B41.4B$70.4B3C6BC9B3C8B40.4B$70.6B2C2B2C12BC10B38.4B
$69.2C6B2CB2C8B2.15B35.4B$67.4BC5BC4B.5B6.10BC3B33.4B$66.B2CB2C6B2C15.
8B3C2B32.4B$66.B2C2B2C6B16.7B2CB2C2B30.4B$65.C6B3C4B17.5B2CB2C5B27.4B
$63.2BCBC5BCBC2B20.2B2CB2C7B25.4B$62.4B3C6BC23.2B3C8B24.4B$62.6B2C2B2C
B24.3BC10B22.4B$61.8B2CB2CB25.15B19.4B$59.10BC4B28.14B17.4B$58.12B2C31.
13B16.4B$58.13B32.14B3.B10.4B$55.16B33.18B8.4B$54.16B36.14BC2B6.4B$54.
4C10B39.12BCBC2B4.4B$53.C2B2C9B40.18B2.4B$53.2BC11B41.11B3C2B2.4B$52.
C13B42.2BCBC10B2.4B$51.B3C5BCBC4B40.3BC2BC8B2.4B$50.9BC4BC2B40.BC4BC4B
2.B2.4B$49.4B.9B2C2B39.B2C4B2C3B4.4B$48.4B2.5BC3B4C39.4C3BC5B2.4B$47.
4B4.3B2C4B2CB39.2B2C9B.4B$46.4B2.B2.4BC4BCB40.2BC4BC9B$45.4B2.8BC2BC3B
40.4BCBC5B3CB$44.4B2.10BCBC2B42.13BC$43.4B2.2B3C11B41.11BC2B$42.4B2.18B
40.9B2C2BC$41.4B4.2BCBC12B39.10B4C$40.4B6.2BC14B36.16B$39.4B8.18B33.16B
$38.4B10.B3.14B32.13B$37.4B16.13B31.2C12B$36.4B17.14B28.4BC10B$35.4B19.
15B25.B2CB2C8B$34.4B22.10BC3B24.B2C2B2C6B$33.4B24.8B3C2B23.C6B3C4B$32.
4B25.7B2CB2C2B20.2BCBC5BCBC2B$31.4B27.5B2CB2C5B17.4B3C6BC$30.4B30.2B2C
B2C7B16.6B2C2B2CB$29.4B32.2B3C8B15.2C6B2CB2CB$28.4B33.3BC10B6.5B.4BC5B
C4B$27.4B35.15B2.8B2CB2C6B2C$26.4B38.10BC12B2C2B2C6B$25.4B40.8B3C9BC6B
3C4B$24.4B41.7B2CB2C8BCBC5BCBC2B$23.4B43.5B2CB2C10B3C6BC$22.4B46.2B2C
B2C13B2C2B2CB$21.4B48.2B3C15B2CB2CB$20.4B49.3BC16BC4B$19.4B51.20B2C$18.
4B54.20B$17.4B56.19B$16.4B57.7B2.9B$15.4B58.7B4.5B$14.4B58.9B2.4B$13.
4B60.7B2.4B$12.4B62.5B2.4B$11.4B64.3B2.4B$10.4B66.B2.4B$9.4B69.4B$8.4B
69.4B$7.4B69.4B$6.4B69.4B$5.4B69.4B$4.4B69.4B$3.4B69.4B$2.4B69.4B$.4B
69.4B$4B69.4B$3B69.4B$2B69.4B$B69.4B$69.4B$68.4B$67.4B$66.4B$65.4B$64.
4B$63.4B$62.4B$61.4B$60.4B$59.4B$58.4B$57.4B$56.4B$55.4B$54.4B$53.4B$
52.4B$51.4B$50.4B$49.4B$48.4B$47.4B$46.4B$45.4B$44.4B$43.4B$42.4B$41.
4B$40.4B$39.4B$38.4B$37.4B$36.4B$35.4B$34.4B$33.4B$32.4B$31.4B!
[[ AUTOIDENTIFY KILLGLIDERS ]]
If we turn on State Number, mousing over the bounded grid edges for the first pattern shows 255, but for the second it shows 0. Is this intended or is State Number not functioning as it should for Generations?

Code: Select all

x = 1, y = 1, rule = B/S0:P1
o!

Code: Select all

x = 1, y = 1, rule = 0//3:P1
o!
Unexpectedly low framerates and GPS are becoming increasingly irritating and considerably impacting usability on mobile platforms. Seeing a cap of 20fps is becoming more and more common. Is there any way at all I can produce useful debug info to help fix this?
IMG_6631.jpeg
IMG_6631.jpeg (248.79 KiB) Viewed 1098 times
Here's a few old bugs:
- clicking to draw in the top row or left column won't work for this pattern
- Select All creates a box in the wrong place
- manually selecting the entire bounded grid and flipping will delete cells, attempting to rotate will produce an error
- if we do end up creating cells in the top row or left column, then save the pattern and load it, everything will be shifted down and to the right by one cell, deleting every cell on the bottom row and right column

Code: Select all

x = 12, y = 12, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15:T10,10
$bo$2b9o$2b9o$2b9o$2b9o$2b9o$2b9o$2b9o$2b9o$2b9o!
Finally, and this is extremely low-priority, but during my annual reading-through-the-whole-thread-again-to-see-if-any-bugs-have-shown-up-again session I came across a bunch of links that still point to the defunct no-ip.biz address rather than the new .com site. These should be easy fixes but I don't know if it's worth the effort. Clicking on a link only to have to take longer than I should processing the fact that it's outdated and will never load is a bit irritating, but not many people visit the early ages of this thread anyway. Hopefully this is comprehensive since everything following late 2018 seems to work now:

Code: Select all

https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=50#p22659
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=75#p22840 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=75#p22847 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=75#p22849
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=75#p22866
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=100#p22873
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=100#p22877
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=100#p22885
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=100#p22886
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=125#p25431
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=125#p26626
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=125#p29324
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p29766
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p30118
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p30314
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31517
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31530 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31567
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31571
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31582
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31613
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=150#p31901
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=175#p31940
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=175#p32557
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=175#p33212
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=175#p34562
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=200#p35498
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=200#p35504
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=225#p35632
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=225#p40208
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=250#p40996
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=250#p41205
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=250#p41665
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=250#p42111
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=250#p43784 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=275#p44633
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=275#p45932
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=275#p48910
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=300#p57182
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=325#p58125
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=325#p58181 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=325#p58203
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=325#p58315
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=350#p63604
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=375#p66598
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

dvgrn wrote: June 3rd, 2019, 4:29 pmHere's the old weekender-to-glider converter, as an unreasonably huge example:
Since this is a periodic loop, I've also used this as an unreasonably huge performance benchmark for LifeViewer Pro (build 1255 since that's seemingly the latest version available). The results are as follows, in a rather unscientific setup where HISTORYSTATES and AGESTATES are set to 0, the Mono theme is used, and the Basic shader is selected:

- WASM Engine off: 863.4 seconds for period detection, 977.5 seconds total
- WASM Engine on: 167.9 seconds for period detection, 251.6 seconds total

The performance improvement here is obvious.

What I want to know: what else about LifeViewer Pro needs testing? Are there any rulespaces whose performance hasn't been measured to a satisfactory degree? Are there other things needing checked besides iterating patterns? Input appreciated.

I also want to know if this benchmark would be of any use in a modern context.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: February 28th, 2025, 9:34 am In the following viewers, in Help > Info > Cells, the first and third examples have lines for Dead and DeadRamp. The second, however, omits these lines. All three of these functionally do the same thing
Fixed, thanks.
muzik wrote: February 28th, 2025, 9:34 am Due to how rules with only one dying state work, I'd expect the value shown for "Deaths" to match the number of dying cells present in the pattern.
Fixed, thanks.
muzik wrote: March 1st, 2025, 10:12 am This evolves incorrectly in both LifeViewer Standard and LifeViewer Pro - in Standard this acts as a still life and in Pro it dies
Fixed, thanks.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

Build 1121 introduced a feature which displays the period of something when Identify detects it is periodic, which is great for high-period stuff when waiting on further info. However, for low-period things, it introduces a short delay before the table of information is shown, which I find slightly irritating - it was far more satisfying to immediately be presented with all of the info as soon as (and in some cases, seemingly before) you pressed F6. Could it be changed so that this text only appears if more than five seconds or so have elapsed since the identification process has begun?

Comparison for before and after - here's build 1120:
1120identify.gif
1120identify.gif (125.78 KiB) Viewed 1049 times
and build 1121:
1121identify.gif
1121identify.gif (239.51 KiB) Viewed 1049 times


Turning on KILLGLIDERS will delete the two gliders, despite the fact that they will end up interacting with the rest of the pattern if it isn't turned on. I assume the algorithm is intended for B3/S23 behaviour specifically and cases like these aren't intended to be covered?

Code: Select all

x = 69, y = 47, rule = B2ik34-r5-n678/S234-k5678
33b3o$33b3o$33b3o42$o65bobo$obo64b2o$2o65bo!


If an alternating pattern is saved on an odd generation, it won't work correctly when loaded again since the rules will be out of alignment.

Code: Select all

x = 3, y = 3, rule = B3678/S23678|B3/S23
o$3o$bo!
This can be easily fixed by simply reversing the alternating rulestring - could alternating patterns saved on odd generations be made to do this automatically?

Code: Select all

# saved at gen 67
x = 13, y = 20, rule = B3/S23|B3678/S23678
4b5o$5b3o2bo$bo4bo3bo$bob2o3bobo$obo$bo4bo$bo4bo2bo$5bob2o3bo$8bob3o$
8bob3o2$9b3o2$b3o$b3o2$b3o$obobo$bobo$2bo!


These generate bugged frequency maps, and NaN% in the frequency table (and has alerted me to the fact that frequency maps are off-center):

Code: Select all

x = 1, y = 1, rule = B/SInvestigator
F!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = B/SInvestigator
J!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = B/SInvestigator
S!
[[ AUTOIDENTIFY ]]


When the number of generations is high, why does the edge of bounded grids change colour, but the cells outside of the unbounded grid stay the same color?

Code: Select all

x = 255, y = 2, rule = /2/256:T480
yOyNyMyLyKyJyIyHyGyFyEyDyCyByAxXxWxVxUxTxSxRxQxPxOxNxMxLxKxJxIxHxGxFxE
xDxCxBxAwXwWwVwUwTwSwRwQwPwOwNwMwLwKwJwIwHwGwFwEwDwCwBwAvXvWvVvUvTvSvR
vQvPvOvNvMvLvKvJvIvHvGvFvEvDvCvBvAuXuWuVuUuTuSuRuQuPuOuNuMuLuKuJuIuHuG
uFuEuDuCuBuAtXtWtVtUtTtStRtQtPtOtNtMtLtKtJtItHtGtFtEtDtCtBtAsXsWsVsUsT
sSsRsQsPsOsNsMsLsKsJsIsHsGsFsEsDsCsBsArXrWrVrUrTrSrRrQrPrOrNrMrLrKrJrI
rHrGrFrErDrCrBrAqXqWqVqUqTqSqRqQqPqOqNqMqLqKqJqIqHqGqFqEqDqCqBqApXpWpV
pUpTpSpRpQpPpOpNpMpLpKpJpIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$yO
yNyMyLyKyJyIyHyGyFyEyDyCyByAxXxWxVxUxTxSxRxQxPxOxNxMxLxKxJxIxHxGxFxExD
xCxBxAwXwWwVwUwTwSwRwQwPwOwNwMwLwKwJwIwHwGwFwEwDwCwBwAvXvWvVvUvTvSvRvQ
vPvOvNvMvLvKvJvIvHvGvFvEvDvCvBvAuXuWuVuUuTuSuRuQuPuOuNuMuLuKuJuIuHuGuF
uEuDuCuBuAtXtWtVtUtTtStRtQtPtOtNtMtLtKtJtItHtGtFtEtDtCtBtAsXsWsVsUsTsS
sRsQsPsOsNsMsLsKsJsIsHsGsFsEsDsCsBsArXrWrVrUrTrSrRrQrPrOrNrMrLrKrJrIrH
rGrFrErDrCrBrAqXqWqVqUqTqSqRqQqPqOqNqMqLqKqJqIqHqGqFqEqDqCqBqApXpWpVpU
pTpSpRpQpPpOpNpMpLpKpJpIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA!
[[ MAXGRIDSIZE 9 STARTFROM 100 X 250 ZOOM 8 ]]
Also, when mousing over a cell which is outside of a bounded grid, but still within "normal" bounds (i.e. not a "boundary" cell and uses the "background" color), could the text at the bottom left say [background] instead of [boundary]? The current behaviour is perhaps inaccurate.



I've put in a pull request containing some aliases that were missed a few years ago, so this should bring us closer to completion. Feedback on all three PRs that are currently open would be appreciated when possible.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 1st, 2025, 7:55 pm Build 1121 introduced a feature which displays the period of something when Identify detects it is periodic, which is great for high-period stuff when waiting on further info. However, for low-period things, it introduces a short delay before the table of information is shown, which I find slightly irritating
Could it be changed so that this text only appears if more than five seconds or so have elapsed since the identification process has begun?
No. I can't forecast how long the post-period detection phase will take.
muzik wrote: March 1st, 2025, 7:55 pm Turning on KILLGLIDERS will delete the two gliders, despite the fact that they will end up interacting with the rest of the pattern if it isn't turned on. I assume the algorithm is intended for B3/S23 behaviour specifically and cases like these aren't intended to be covered?
It's designed for any rule where gliders exist and are fast enough to escape.
muzik wrote: March 1st, 2025, 7:55 pm If an alternating pattern is saved on an odd generation, it won't work correctly when loaded again since the rules will be out of alignment.
This can be easily fixed by simply reversing the alternating rulestring - could alternating patterns saved on odd generations be made to do this automatically?
I'm not sure I like changing the rule string. Perhaps #CXRLE Gen would be a better solution. I'll add it to the list of things to investigate.
muzik wrote: March 1st, 2025, 7:55 pm These generate bugged frequency maps, and NaN% in the frequency table
Fixed in build 1263, thanks.
muzik wrote: March 1st, 2025, 7:55 pm When the number of generations is high, why does the edge of bounded grids change colour, but the cells outside of the unbounded grid stay the same color?
Because there are only 256 cell colours. If they're all being used by pattern states then there isn't a separate colour for the bounded grid. The area outside the grid is separate and not drawn as cells so it can use any colour.
muzik wrote: March 1st, 2025, 7:55 pm when mousing over a cell which is outside of a bounded grid, but still within "normal" bounds (i.e. not a "boundary" cell and uses the "background" color), could the text at the bottom left say [background] instead of [boundary]?
No. I'm happy with the current behaviour.
muzik wrote: March 1st, 2025, 7:55 pm I've put in a pull request containing some aliases that were missed a few years ago, so this should bring us closer to completion. Feedback on all three PRs that are currently open would be appreciated when possible.
Thanks for the PRs. I'll review when I have a moment.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 1st, 2025, 5:30 pm What I want to know: what else about LifeViewer Pro needs testing?
Firstly, LifeViewer Pro is still in development. It won't be functionally complete until the Beta release.

So far 102 functions have been optimized. They cover the following areas:

Code: Select all

// HROT
//	nextGenerationHROTMoore2/N (Moore, deterministic)
//	nextGenerationHROTVN2/N (von Neumann, deterministic)
//	nextGenerationCornerEdge2/N (Corner/Edge, deterministic)
//	nextGenerationCross2/N (Cross, deterministic)
//	nextGenerationHash2/N (Hash, deterministic)
//	nextGenerationStar2/N (Star, deterministic)
//	nextGenerationSaltire2/N (Saltire, deterministic)
//	nextGenerationCheckerboard2/N (Checkerboard, deterministic)
//	nextGenerationAlignedCheckerboard2/N (Aligned Checkerboard, deterministic)
//	nextGenerationShaped2/N (L2 or Circular, deterministic)
//	nextGenerationHexagonal2/N (Hexagonal, deterministic)
//	nextGenerationAsterisk2/N (Asterisk, deterministic)
//	nextGenerationTripod2/N (Tripod, deterministic)
//	nextGenerationTriangular2/N (Triangular, deterministic)
//	nextGenerationCustom2/N (Custom, deterministic)
//	nextGenerationGaussian2/N (Gaussian, deterministic)
//	nextGenerationWeighted2/N (Weighted, deterministic)
//	nextGenerationWeightedStates2/N (Weighted with weighted states, deterministic)
//	updateGridFromCounts2/N
//	cumulativeMooreCounts2/N (Moore)
//	cumulativeVNCounts2/N (von Neumann)
//	clearTopAndLeft (Moore)
//	wrapTorusHROT (Torus Bounded Grid)
//	clearHROTOutside (Bounded Grid)

// Iterators
//	convertToPens2 (Life-like Basic Shader)
//	convertToPensAge (Life-like Cell Age Shader)
//	convertToPensNeighbours (Life-like Neighbour Count Shader)
//	nextGeneration (Life-like)
//	nextGenerationGenerations (Generations)
//	nextGenerationSuperMoore (Super, Moore)
//	nextGenerationSuperHex (Super, Hex)
//	nextGenerationSuperVN (Super, von Neumann)
//	nextGenerationInvestigatorMoore (Investigator, Moore)
//	nextGenerationInvestigatorHex (Investigator, Hex)
//	nextGenerationInvestigatorVN (Investigator, von Neumann)
//	nextGenerationRuleTreeMoore (RuleTree, Moore)
//	nextGenerationRuleTreeMoorePartial4 (RuleTree, Moore)
//	nextGenerationRuleTreeVN (RuleTree, von Neumann)
//	nextGenerationRuleTableMoore (RuleTable, Moore)
//	nextGenerationRuleTableHex (RuleTable, Moore)
//	nextGenerationRuleTableVN (RuleTable, Moore)
//	nextGenerationRuleLoaderMooreLookupN (RuleLoader, Moore)
//	nextGenerationRuleLoaderVNLookupN (RuleLoader, von Neumann)
//	nextGenerationRuleLoaderHexLookupN (RuleLoader, Hex)

// Loading
//	resetColourGridNormal (Life-like)
//	resetPopulationBit (Life-like)
//	resetBoxesBit (Life-like)
//	shrinkTileGrid (Life-like)

// Identify
//	updateOccupancyStrict
//	updateCellCounts
//	updateCellCountsSuperOrRuleLoader
//	getHashTwoState
// 	getHashRuleLoaderOrPCAOrExtended
//	getHashGenerations
//	getHashLifeHistory
//	getHashSuper

// Rendering
//	createNxNColourGrid (N = 2, 4, 8, 16, 32)
//	createNxNColourGridSuper (N = 2, 4, 8, 16, 32)
//	renderGridNoClipNoRotate (single layer, square or triangular)
//	renderGridClipNoRotate (single layer, square or triangular)
//	renderOverlayNoClipNoRotate (single layer [R]History, square or triangular)
//	renderOverlayClipNoRotate (single layer [R]History, square or triangular)
muzik wrote: March 1st, 2025, 5:30 pm Are there any rulespaces whose performance hasn't been measured to a satisfactory degree? Are there other things needing checked besides iterating patterns?
Anything not on that list hasn't been changed (yet). Some things on that list need further optimization.
For example I haven't yet optimized the Rainbow shader for LifeViewer Pro.

In general the testing needs to ensure that there are no discrepancies between LifeViewer Standard and the things that have changed for LifeViewer Pro, and also that the performance is improved in each case.
An example of a discrepancy would be your recent report about AutoFit in LifeViewer Pro.
muzik wrote: March 1st, 2025, 5:30 pm I also want to know if this benchmark would be of any use in a modern context.
Yes, this is still valid and actually quite relevant. It was written before the Shader support but at a time where there was an optimization for no-history Themes. This was later deprecated for a number of technical reasons and is now replaced by the Basic shader. It was also testing zoomed out rendering performance (something that is significantly improved in LifeViewer Pro).
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

rowett wrote: March 2nd, 2025, 3:53 am
muzik wrote: March 1st, 2025, 5:30 pm I also want to know if this benchmark would be of any use in a modern context.
Yes, this is still valid and actually quite relevant. It was written before the Shader support but at a time where there was an optimization for no-history Themes. This was later deprecated for a number of technical reasons and is now replaced by the Basic shader. It was also testing zoomed out rendering performance (something that is significantly improved in LifeViewer Pro).
Decided to run this on the iPad (copying and pasting into the /pro/ just to be sure). The results are as follows:

WASM Engine off:
IMG_6861.jpeg
IMG_6861.jpeg (59.48 KiB) Viewed 983 times
WASM Engine on:
IMG_6862.jpeg
IMG_6862.jpeg (58.8 KiB) Viewed 983 times
I also tried this on desktop, and the results were a bit more interesting. Here's with WASM off:
Image

With it turned on, we see an extreme improvement:
Image

Double-checking by refreshing the page confirms these results:
Image

Either this is platform-dependent, or the cause of it was fixed some time between build 1255 (latest pro build on desktop) and build 1260 (latest on mobile).
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

Some further testing with the following low-density pattern, changing the neighbourhood each time.

Code: Select all

x = 100, y = 100, rule = R5,C2,S,B1,NM:T100,100
23bo23bo23bo$4bo36bo20bo29bo$10bo11bo18bo6bo12bo8bo21bo2bo$22bo4bo58b
o$14bo4bo24bo13bo26bo$9bo70bo7bo$37bo47bo$23bo26bo$15bo3bo14bo10bo49b
o$8bo19bo5bo21bo$19bo51bo3bo10bo3bo2bo$7bo31bo28bo15bo$bobobo76bo6bob
o$15bo10bo4bo3bo37bo5bo5bo5bo$24bo13bo51bo$16bo20bo12bo40bo$34bo34bo10b
o3b2obo$o30bo11bo32bo5bo9bo$bo2bobo11bo10bo14bo34bo9bo8bo$6bo4bo7bo3b
o8bo7bo4bo4bo31b3o$23bo46bo7bo7bo$37bo34bo10bo$19bo24bo33bo2bo14bo$bo
5bo24bo8bo45bo$20bo10bo32bo$19b2o43bo3bo30bo$16bo17bo3bo$11bo9bo10bo2b
o31bo24bo3bo$o13bo9bo6bo22bo5bo12bo9bo$2o7bo21bo39bo$25bo25b2o18bo21b
o$11bo28bo19bo9bo5bo13bo$bo32bo33bo$8bo3bo16bo22bobo3bo13bo17bo4bo$48b
o16bo6bo$36b2o7bo12bo8bo9bo13bo$7bo4bo22bo4bo9bo13bo23bo$12bo3bo80bo$
14bobo19bo32bo$6bo61bo$7bo10bo22bo13bo14bo6bo$3bo16bo22bo9bo23bo$21bo
21bo33bo19bo$24bo25bo$6bo49bo3bo25bo8bo2bo$20bo6bo17bo3bo10bo26bo$8bo
9bo39bo15bo18bo$4b2o17bo41bo26b2obo$29bo34bo$11bo8bo27bo5bo13bo13bo8b
obobo$57b2obo36bo$bo19bo19bo27bo16bo3bo$39bo57bo$11bo13bo4bo9bo14bobo
9bo4bo$22bo42bo6bo26bo$48bo7bo31bo2bo$65bo5b2o10bo$45bo16bo$3bo19bo8b
o18bo7bo34bo$14bo48bo2bo9bo15bo$35bo10b2o24bo17bo$13bo4bo23b2o2bo$7bo
24bo25bo8b2o27bo$5bo5bo11bo3bo4bo24bo$10bo14bo5b2o34bo19bo$16bo7bo10b
o4bo9bo24bo12bo6bo$2bo8bo29bo43bo12bo$13bo12b2o2bo4bo5bo12bo12bo18bo8b
o$4bo4bo19b3o64bo$31bo5bo10bo25bo5bo$13bo4bo3bo7bo5bo9bo8bo35bo$o29bo
15bo15bo34bo$3bo3bo43bobo7bo6b2o4bo22bo$o20bo12bo45bobo9bo$16bo23bo14b
o30bo$25bo10bo20bo4bo6bo3bo15bo$10bo22bo47bo6bo2bobo$10bo44bo5b2o15bo
$bo9bo16bo4bo5bo8bo4bo34b2o$8bo8bo14bo32bo10bo16bo$13bo23bo7bo48bo$74b
obo20bo$3bo90b2o$36bo31bo2bo$66bo4bo11bo14bo$16bo32bo23bo$14bo11bo27b
o8bo27bo$4bo8bo6bo8bobo50bo$23bo10bo27bo11bo14b2obobo$13b2o4bo13bo$6b
o19bo17bo18bo21bobo$3b2o16bo22bo10bo29bo11bo$43bo32b2o13bo$12bo13bo23b
o13bo25bo$26bo27bo$bo10bo16bo18bo6b2o3bo19bo12bo$50bo$68bo4bo4bo8bo$16b
o31bo9bo16bo$4bo2bo15bo4bo50bo7bo!
[[ STEP 96 NOTHROTTLE SHOWTIMING EXTENDEDTIMING ]]
Go To Gen 100000b. Browser: Waterfox, Operating system: Kubuntu 24.04

WASM Engine off:

Code: Select all

N+: 28.6s / 3496gps
NX: 40.3s / 2483gps
N*: 28.5s / 3503gps
N#: 43.9s / 2277gps
NB: 42.0s / 2380gps
ND: 40.2s / 2490gps
N2: 39.9s / 2505gps
NC: 39.3s / 2547gps
NN: 37.7s / 2649gps
NM: 7.1s / 14138gps
NG: 121.4s / 823gps
N3: 35.3s / 2830gps
NA: 49.5s / 2018gps
NH: 32.7s / 3054gps
NL: 27.5s / 3630gps
WASM Engine on:

Code: Select all

N+: 6.0s / 16700gps
NX: 9.8s / 10248gps
N*: 14.0s / 7136gps
N#: 12.8s / 7837gps
NB: 20.0s / 5007gps
ND: 19.3s / 5182gps
N2: 13.5s / 7401gps
NC: 13.6s / 7367gps
NN: 21.2s / 4706gps
NM: 2.0s / 48995gps
NG: 61.4s / 1628gps
N3: 7.8s / 12771gps
NA: 11.8s / 8478gps
NH: 11.2s / 8938gps
NL: 12.1s / 8267gps
By the way, for Themes for Generations patterns, do cell state colors have to be expressed as gradients? I have a more faithful palette to what MCell actually uses for multistate patterns, which would require defining a fixed color per numbered cell state.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 1st, 2025, 10:12 am In LifeViewer Pro specifically (latest available build is 1260), AUTOFIT will do a very strange bouncing motion when used on Generations spaceships.
Fixed in build 1264, thanks.
muzik wrote: March 2nd, 2025, 9:50 am With it turned on, we see an extreme improvement
This might also be fixed, though I couldn't reproduce it.
User avatar
LuveelVoom
Posts: 655
Joined: April 27th, 2022, 7:59 pm

Re: Pattern viewer for forum threads

Post by LuveelVoom »

Autofit camera feels too bouncy to use on small spaceships anyway, is there any chance an auto track option could be added (I know that you can do this with [[TRACK]], though)
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

rowett wrote: March 2nd, 2025, 2:57 pm
muzik wrote: March 2nd, 2025, 9:50 am With it turned on, we see an extreme improvement
This might also be fixed, though I couldn't reproduce it.
The latest build of Pro specifically that seems to be available is 1260 so I can't say for sure:
1260wasmoff.png
1260wasmoff.png (13.33 KiB) Viewed 921 times
1260wasmon.png
1260wasmon.png (10.11 KiB) Viewed 921 times
Is there a newer version available and how can I access it?
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

For some reason, the following bounded grid patterns are positioned differently than they used to be at time of posting (I remember these occupying the full grid rather than only the bottom right). Is this due to the specified dimensions being zero?
ColorfulGalaxy wrote: February 13th, 2021, 12:22 am Bug: Venetian blinds freeze in strobing rule B03/S23
Also, in B0/S5, it oscillates, but "Identify" says it's a still life.

Code: Select all

x = 0, y = 0, rule = B3/S23:T8,8
8o$8o3$8o$8o!

Code: Select all

x = 0, y = 0, rule = B03/S23:T8,8
8o$8o3$8o$8o!

Code: Select all

x = 0, y = 0, rule = B03/S238:T8,8
8o$8o3$8o$8o!

Code: Select all

x = 0, y = 0, rule = B0/S5:T8,8
8o$8o3$8o$8o!
A still life that oscillates??????
Patterns which LifeViewer doesn't recognise as valid will generate a smaller popup viewer than expected. Can the normal minimum width and height be enforced when the popup is created, rather than when the content has finished loading?: https://catagolue.hatsya.com/object/xp6 ... 7l12345678

Also, for BSFKL, deficient and genext rules, could the rulestrings at least be decoded and validated (like was done for LtL back in 2018) even if the actual runtime isn't ready, so that the pattern can be edited and saved just like any other pattern?

Caterer seems like it has changed its Generations color scheme, so it may be worth updating the built-in theme to match this:
1345923587051225098.gif
1345923587051225098.gif (126.5 KiB) Viewed 889 times

Code: Select all

x = 20, y = 4, rule = /2/20
SRQPONMLKJIHGFEDCBA$.SRQPONMLKJIHGFEDCBA$.SRQPONMLKJIHGFEDCBA$SRQPONM
LKJIHGFEDCBA!
[[ THEME Caterer ]]
EDIT: further testing shows it's a tad inconsistent, and differs for state counts as well as range-1 versus higher-range. I may need to check with the bot developers to see if the current behaviour is intended at all.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 2nd, 2025, 6:38 pm Is there a newer version available and how can I access it?
Build 1264 is the latest for Standard and Pro. Just hard refresh the browser.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 2nd, 2025, 8:58 pm For some reason, the following bounded grid patterns are positioned differently than they used to be at time of posting
Fixed in build 1265, thanks.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

Will it be possible to use any other paste modes in the UI? Currently only four are provided whereas commands can use 16.

Several even-numbered states appear to be killed by state 6 in [R]Super. State 6 is only meant to kill alive cells to my knowledge, so this doesn't make sense; these even states are specifically meant for annotation purposes.

Code: Select all

x = 6, y = 11, rule = B3/S23Super
2H2F2X$2H2F2X$2H2F2X$2.2F$2R2F2P$2R2F2P$2R2F2P$2.2F$2T2F2V$2T2F2V$2T2F
2V!
Attempting to load this shows an error regarding RuleLoader, despite the issue being nothing to do with RuleLoader. Also, Help > Info > Cells shows the color for state 1 (which is not present) but shows nothing for state 64 (the only nonzero state present).

Code: Select all

x = 8, y = 7, rule = R1,C2,S0-8,B0,8,NM|R1,C2,S2-3,B0,3,NM:T100,100
b2o$3bo$3ob3o$2b6o$3ob4o$2bob3o$b3o!
On that topic, for some reason, Help > Info > Cells doesn't show state 1's color despite it obviously being present here.

Code: Select all

x = 10, y = 10, rule = B3/S23:T10000,10000
2o2b2obobo$o2bo3bo$b3o2bobo$o4bo$2bo2b3obo$4bobo2bo$7ob2o$bo5b2o$5b4o$
2o4bobo!
Are Dead and DeadRamp supposed to be shown in Help > Info > Cells if the Basic shader is in use?

Code: Select all

x = 4, y = 4, rule = B3/S23
2bo$obo$bobo$bo!
[[ STARTFROM 128 SHADER Basic ]]
AliveRamp sometimes doesn't appear in Help > Info > Cells but I'm yet to get consistent reproduction steps.

Is there a difference between https://lazyslug.com/lifeview/ and https://lazyslug.com/lifeviewer/ ? Would it make sense for one to redirect to the other? /lifeview/pro/ doesn't work, which sometimes catches me out.

These script commands appear to work perfectly fine to rotate and tilt the grid. Despite this, the sliders are grayed out. Can they be enabled?

Code: Select all

x = 0, y = 0, rule = none
o!
[[ ANGLE 45 TILT 0.5 ]]
When VIEWONLY is used, can the buttons and sliders (play, pause, reverse, undo, etc.) still be displayed across the bottom, but grayed out and disabled?

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ VIEWONLY ]]
This may be evolving incorrectly - it acts as a still life despite having no survival conditions. If we try this in LifeViewer Pro (the latest version I can use, at least, since I haven't cache refreshed), it dies, which I'd expect, though this does highlight another difference between Standard and Pro.

Code: Select all

x = 3, y = 3, rule = R1,C2,S,B,NW999909999
3o$obo$3o!
Finally, a feature request with a visual demonstration: could a cursor be added under the mouse highlighting the cell being targeted? This would be useful when editing patterns, on mobile (since it's not at all obvious where the viewer regards the "targeted cell" mentioned on the bottom left to be), when viewing patterns, and could be customised like other things.
cursordemo.png
cursordemo.png (9.48 KiB) Viewed 823 times
cursoronlivingcell.png
cursoronlivingcell.png (9.05 KiB) Viewed 823 times
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

rowett wrote: March 3rd, 2025, 3:01 amBuild 1264 is the latest for Standard and Pro. Just hard refresh the browser.
Now on Pro build 1265: I can confirm that the autofit bouncing issue is gone. Pausing still seems to zoom out, however.

As for benchmarking, we now have the following, less obscene results:
1265wasmoff.png
1265wasmoff.png (20.96 KiB) Viewed 811 times
1265wasmon.png
1265wasmon.png (21.68 KiB) Viewed 811 times
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
confocaloid
Posts: 6697
Joined: February 8th, 2022, 3:15 pm
Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms

Re: Pattern viewer for forum threads

Post by confocaloid »

muzik wrote: March 3rd, 2025, 8:55 am [...]
This may be evolving incorrectly - it acts as a still life despite having no survival conditions. If we try this in LifeViewer Pro (the latest version I can use, at least, since I haven't cache refreshed), it dies, which I'd expect, though this does highlight another difference between Standard and Pro.

Code: Select all

x = 3, y = 3, rule = R1,C2,S,B,NW999909999
3o$obo$3o!
[...]
Maybe that definition shouldn't be accepted at all, at least with the current meaning. Currently it is interpreted as "all neighbours have negative weights".

Now, the ability to use negative weights may or may not be useful in those cases when at least some neighbours are positively-weighted. (Although I didn't find evidence of people finding negative weights useful at all / actively using them for some purpose. In my opinion, the ability to specify positive weights up to 15 with one hex digit per neighbour and the ability to specify positive weights up to 255 with two hex digits per neighbour would be much more useful in practice. I certainly would use positive neighbour weights up to 255, if that was possible at all.)

Regardless of that, when all neighbours are negatively-weighted, that means all possible nonempty neighbourhood configurations give negative sums; that can be easily simplified by negating all neighbour weights and negating all birth/survival conditions. So I think weighted neighbourhoods without any positive weights should be simply rejected with an error message.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

confocaloid wrote: March 3rd, 2025, 9:52 amMaybe that definition shouldn't be accepted at all, at least with the current meaning. Currently it is interpreted as "all neighbours have negative weights".
I'm not the most familiar with weighted definitions. Could negative birth conditions be accepted in theory? I don't think LifeViewer nor Golly support this, but it seems like something that would end up working as a logical extension of how neighbour weighting works.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
confocaloid
Posts: 6697
Joined: February 8th, 2022, 3:15 pm
Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms

Re: Pattern viewer for forum threads

Post by confocaloid »

I would prefer to avoid any negative living conditions (and avoid the need to support them). I think the rulestrings would look awkward and harder to read/understand. (And as I wrote, I doubt supporting negative weights is useful at all, especially compared to possible support of higher positive weights.)

Crossposting earlier relevant discussion:
confocaloid wrote: August 31st, 2024, 5:48 am An additional complication with B0 NW is that B0 is not necessarily limited to strobing background. The NW... format allows to specify negative weights of neighbours. There can be two or more alive neighbours in neighbourhood positions whose weights add to zero (e.g. one alive neighbour in position weighted +1, one alive neighbour in a position weighted -1, and no other alive neighbours). Any such configuration would query the same birth condition (B0).

I don't know how much is explored re: CA with negatively-weighted neighbours, though.
confocaloid wrote: August 31st, 2024, 5:32 am What are known explored CA with negatively-weighted neighbours?
The NW... neighbourhood format allows to specify negative weights ("[...] The hexadecimal representation has the MSB as the sign bit [...]"). However, there seems to be little evidence of people actually using that feature.
muzik wrote: August 29th, 2022, 1:37 pm On the topic of weighted neighbourhoods, since certain neighbours can have negative weights, shouldn't birth conditions also be able to be negative?

Code: Select all

x = 41, y = 49, rule = R1,C2,S2-3,B3,NW111101111
19b2o$19b4o$19bob2o2$20bo$19b2o$19b3o$21bo$33b2o$33b2o7$36bo$35b2o$34bo3bo$35b2o2bo$40bo$37bobo$38bo$38bo$38b2o$38b2o3$13bo10bo$12b5o5bob2o11bo$11bo10bo3bo9bo$12b2o8b3obo9b2o$13b2o9b2o12bo$2o13bo21b3o$2o35b3o7$8b2o$8b2o11b2o$19b2o2bo$24bo3bo$18bo5bo3bo$19bo2b2o3bobo$20b3o5bo$28bo!

Code: Select all

x = 41, y = 49, rule = R1,C2,S-2--3,B-3,NW999909999
19b2o$19b4o$19bob2o2$20bo$19b2o$19b3o$21bo$33b2o$33b2o7$36bo$35b2o$34bo3bo$35b2o2bo$40bo$37bobo$38bo$38bo$38b2o$38b2o3$13bo10bo$12b5o5bob2o11bo$11bo10bo3bo9bo$12b2o8b3obo9b2o$13b2o9b2o12bo$2o13bo21b3o$2o35b3o7$8b2o$8b2o11b2o$19b2o2bo$24bo3bo$18bo5bo3bo$19bo2b2o3bobo$20b3o5bo$28bo!
rowett wrote: August 30th, 2022, 9:42 am
muzik wrote: August 29th, 2022, 1:37 pm On the topic of weighted neighbourhoods, since certain neighbours can have negative weights, shouldn't birth conditions also be able to be negative?
No that's by design.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
User avatar
rowett
Moderator
Posts: 4589
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: Pattern viewer for forum threads

Post by rowett »

muzik wrote: March 3rd, 2025, 8:55 am Will it be possible to use any other paste modes in the UI? Currently only four are provided whereas commands can use 16.
No.
muzik wrote: March 3rd, 2025, 8:55 am Several even-numbered states appear to be killed by state 6 in [R]Super.
It's consistent with the original LifeSuper rule.
muzik wrote: March 3rd, 2025, 8:55 am Attempting to load this shows an error regarding RuleLoader, despite the issue being nothing to do with RuleLoader.
Fixed, thanks.
muzik wrote: March 3rd, 2025, 8:55 am Help > Info > Cells shows the color for state 1 (which is not present) but shows nothing for state 64 (the only nonzero state present).

On that topic, for some reason, Help > Info > Cells doesn't show state 1's color despite it obviously being present here.
This is by design. Not all metrics are calculated if the pattern was invalid.
muzik wrote: March 3rd, 2025, 8:55 am Are Dead and DeadRamp supposed to be shown in Help > Info > Cells if the Basic shader is in use?

AliveRamp sometimes doesn't appear in Help > Info > Cells but I'm yet to get consistent reproduction steps.
Fixed, thanks.
muzik wrote: March 3rd, 2025, 8:55 am Is there a difference between https://lazyslug.com/lifeview/ and https://lazyslug.com/lifeviewer/ ? Would it make sense for one to redirect to the other? /lifeview/pro/ doesn't work, which sometimes catches me out.
LifeViewer Pro will move once it is released.
muzik wrote: March 3rd, 2025, 8:55 am These script commands appear to work perfectly fine to rotate and tilt the grid. Despite this, the sliders are grayed out. Can they be enabled?
No.
muzik wrote: March 3rd, 2025, 8:55 am When VIEWONLY is used, can the buttons and sliders (play, pause, reverse, undo, etc.) still be displayed across the bottom, but grayed out and disabled?
No.
muzik wrote: March 3rd, 2025, 8:55 am This may be evolving incorrectly - it acts as a still life despite having no survival conditions.
Fixed, thanks.
muzik wrote: March 3rd, 2025, 8:55 am Finally, a feature request with a visual demonstration: could a cursor be added under the mouse highlighting the cell being targeted? This would be useful when editing patterns, on mobile...
It wouldn't help on mobile since there's no cell targetted until you touch it.
User avatar
confocaloid
Posts: 6697
Joined: February 8th, 2022, 3:15 pm
Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms

Re: Pattern viewer for forum threads

Post by confocaloid »

Currently the "Change rule" dialog (Alt R) gives an alias instead of the definition, when there is an alias. For example the dialog gives "Life" instead of "B3/S23". I think this is inconvenient when doing "syntactically minor tweaks". I suggest to show the definition always, regardless of whether there is an alias.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

The new error message for the prior alternating error case is inaccurate, since this still works fine:

Code: Select all

x = 30, y = 30, rule = Bugs R10|Bugsmovie
3o4b2o3b4obobo2bo5b2o$o3b4o2b7o3bob6o$bo4bobo3bo2bo8bob4o$b2o3b2ob5o2b
obo2bob3o2bo$obobobobo4b4o2bob2o2bob2o$o4b3ob3o2b5o3b2ob2obo$2o2b2o2bo
bo6bobo2b3o2bo$bo3bob2o2b2o5bo6b5o$ob3o5bobo3b6ob3o$bob3obo4bob2o2b4o
2bo2bo$bo2b4ob2o2b5ob2ob4o$3o2bo3bob3obobo3bo2b3ob2o$b5ob3ob2obob2obo
3bo2bob2o$3obo2bob2o3bobo2b4ob4o$2b2o2b2ob3o2bob3ob2ob3ob3o$4obobo3b3o
2b5ob2ob2ob2o$2o4bobo2bo3bob3o2bobob4o$obo2b3ob4ob2ob2ob2obo3b2o$3obo
2bo2bo3bobo2bob3obobobo$2bob2o2bob2o2bo3bob2obobobobo$3obobo6bobob3o2b
obo4bo$bo2b3o3bob4o2bo3bob2obobo$2bob2ob2ob2obob3o2b2obobo2bo$b4ob5o5b
ob2o3b4o$2o4bo4b4obobobobo$2ob2o2bo3bob3ob6obo2bobo$ob2obo2bobob2o2b2o
3bo2b2o2bo$2o2b2ob13obo4bobo$b2o4b3o2bo4b2obob2o2b4o$2o3b2obobo2b2o6bo
b2ob2obo!
Selection offset issues appear to be arising again on bounded grids - try Select All on the below:

Code: Select all

x = 10, y = 10, rule = B/S012345678:T10,10
$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o!

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
$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o!

Code: Select all

x = 11, y = 11, rule = M0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15:T10,10
$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o$b10o!
Try creating selections manually on this:

Code: Select all

x = 0, y = 0, rule = B/S012345678:T10,10
10o$10o$10o$10o$10o$10o$10o$10o$10o$10o!
Would it be possible to enable period maps for Generations rules? To my understanding, only state 1 needs to be tracked, and they should work the same. For some examples, the following should centrally be p62 with two outer p124 blobs due to the period doubling mechanism:

Code: Select all

x = 33, y = 10, rule = R2,C6,M0,S2..3,B3..3,NN
30.A.A2$30.A.A2$11.4A$11.ACEB$11.2A2E$A.A8.2AE$12.D2E$A.A!
Here's a 2-state oscillator that does something similar:

Code: Select all

x = 7, y = 5, rule = B2in3aijqr4ikqz5r6n/S2aek3-ae4city5-ejqy6a7e
2bo$b3o$2obo$bobo$4bobo!
Similarly, this oscillator should have two intersecting diagonal "gutteroids" of half the period intersecting at the center:

Code: Select all

x = 10, y = 6, rule = R2,C5,S2-3,B3,8,NB
.A6.A$.2AC2.C2A$B2D.2A.2DB$B2D.2A.2DB$.2AC2.C2A$.A6.A!
Again, a 2-state oscillator which is similar:

Code: Select all

x = 2, y = 12, rule = B3/S5
2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o!
And there's just some oscillators I want to see actual maps of:

Code: Select all

x = 114, y = 59, rule = 34/34/10L
31$5.G2HIGH$6.H2I.HIG$11.IH9.C2B$9.I.I9.2D2C$I18.FG3ED$I17.F2G3E$15.H
I.I2H.2E$14.H4IGDBECDB2A$10.2ABAGEHGDGBF3C2BA$10.A3BAEF3EDA2B2A$10.A2B
CDEDE$10.5ACD$13.A!
Seems I missed some posts that use the old site links, since there were some from 2019, so here's the remaining cases I found:

Code: Select all

https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=625#p69751
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=725#p72543
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=725#p72657
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=725#p72916
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=750#p73045
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=750#p73364
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=750#p73442
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=775#p73496 and reply
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=850#p75984
https://conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=925#p78859
rowett wrote: March 3rd, 2025, 10:08 am
muzik wrote: March 3rd, 2025, 8:55 am Are Dead and DeadRamp supposed to be shown in Help > Info > Cells if the Basic shader is in use?
Fixed, thanks.
The rainbow and neighbour shaders also still display the alive, dead and history colours, even though they don't apply in this case, so it may be worth not displaying these and instead providing more relevant color information for these shaders.
rowett wrote: March 3rd, 2025, 10:08 am
muzik wrote: March 3rd, 2025, 8:55 am Finally, a feature request with a visual demonstration: could a cursor be added under the mouse highlighting the cell being targeted? This would be useful when editing patterns, on mobile...
It wouldn't help on mobile since there's no cell targetted until you touch it.
From what I've seen, this is true until you first touch the viewer: after this point, there will permanently be coordinates in the bottom left of the viewer. It is not at all obvious what exact position these coordinates are referring to, so a visual indicator like this would be very helpful.
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
User avatar
muzik
Posts: 6605
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Pattern viewer for forum threads

Post by muzik »

rowett wrote: March 2nd, 2025, 3:36 am
muzik wrote: March 1st, 2025, 7:55 pm When the number of generations is high, why does the edge of bounded grids change colour, but the cells outside of the unbounded grid stay the same color?
Because there are only 256 cell colours. If they're all being used by pattern states then there isn't a separate colour for the bounded grid. The area outside the grid is separate and not drawn as cells so it can use any colour.
As for "not drawn as cells": does this only apply for the square grid? The hexagonal grid and triangular grid lag considerably when you're rendering enough of the out-of bounds area at once.

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 SHOWTIMING EXTENDEDTIMING ]]

Code: Select all

x = 1, y = 1, rule = B/SH
!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 SHOWTIMING EXTENDEDTIMING ]]

Code: Select all

x = 1, y = 1, rule = B/SL
!
[[ MAXGRIDSIZE 9 ZOOM 4 X -256 Y -256 SHOWTIMING EXTENDEDTIMING ]]
If this is the case, I wonder if it'd be possible to optimize this by only rendering actual "cells" at the very edges, where the boundary between playable universe and outside of it needs to appear "bumpy". Beyond this point, you'd just render the solid color instead, rather than having to render thousands of hexagons or triangles.

----

Mousing over these orange cells will say "state 64" in the first pattern, but will display nothing in the brackets for the second.

Code: Select all

x = 4, y = 4, rule = Frogs:T9000
4o$o2bo$o2bo$4o!

Code: Select all

x = 4, y = 4, rule = PCA_4:T9000
4o$o2bo$o2bo$4o!
If we manually switch to the Mono theme and then back to the Blues theme, the history trail will reappear, which implies to me that we didn't switch to the Basic shader when we started using the Mono theme. Also, if we increase the number of layers when using the Mono theme, some black cells are duplicated across layers, which furthers my suspicions. If, instead of switching themes, we switch to the Basic shader, no such duplication occurs, and the history trail is indeed reset if we go back to the age shader.

Code: Select all

x = 7, y = 5, rule = B3/S23
3b2o$bo4bo$o$o5bo$6o!
[[ ZOOM 4 STARTFROM 100 GRID ]]
In Help > Info > Cells, the top line displays the active shader. I don't know if this is relevant, however, for rulespaces other than range-1 2-states or Margolus, since the shader can't be configured here. I can see it possibly coming to general-range 2-state rules in the future since they're similar, but other than that I'm not so sure. Generations, PCA and [R]History do handle cell history so "Cell Age" does at least seem to make sense here, but the rest do not have an ageing system (so far, in the case of [R]Super) so I don't know if this line should display something else, or be present at all.

Code: Select all

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

Code: Select all

x = 2, y = 2, rule = R1,C2,S2-3,B3
2o$2o!

Code: Select all

x = 2, y = 2, rule = LifeHistory
2o$2o!

Code: Select all

x = 2, y = 2, rule = LifeSuper
2o$2o!

Code: Select all

x = 2, y = 2, rule = LifeInvestigator
2o$2o!

Code: Select all

x = 2, y = 2, rule = 23/3/3
2o$2o!

Code: Select all

x = 2, y = 2, rule = Life-RuleLoader
2o$2o!

Code: Select all

x = 2, y = 2, rule = PCA_4
2o$2o!

Code: Select all

x = 2, y = 2, rule = none
2o$2o!
This glider will be stopped by this LWSS, but turning Kill Gliders on will remove the glider before this happens.

Code: Select all

x = 29, y = 21, rule = B3/S23
b2o$b3o$ob2o$3o$bo14$28bo$26b2o$27b2o!
There is a difference in the default zoom and center here:

Code: Select all

x = 15, y = 13, rule = B2/S34HHistory
8.F$4.6D$4.7D$4.8D$4A9D$4A10D$4A11D$.4A10D$2.4A9D$7.8D$8.7D$9.6D$14.F
!

Code: Select all

x = 15, y = 13, rule = B2/S34HSuper
8.F$4.6D$4.7D$4.8D$4A9D$4A10D$4A11D$.4A10D$2.4A9D$7.8D$8.7D$9.6D$14.F
!
These script commands produce visually identical results, however there are discrepancies. If the GRID and GRIDMAJOR colors are identical, can the "Major GridLines" toggle in Display be disabled, and the line indicating the major color in Help > Info > Gridlines be omitted, like what happens when you set GRIDMAJOR to 0?

Code: Select all

x = 7, y = 5, rule = B3/S23
3b2o$bo4bo$o$o5bo$6o!
[[ GRID COLOR GRID 128 128 128 COLOR GRIDMAJOR 128 128 128 ]]

Code: Select all

x = 7, y = 5, rule = B3/S23
3b2o$bo4bo$o$o5bo$6o!
[[ GRID COLOR GRID 128 128 128 GRIDMAJOR 0 ]]
Help > Info > Gridlines also still displays a line for the major value in hexagonal and triangular rules despite neither of these having a system for major grid lines anymore, so this line should probably be removed. It does correctly say the interval is off, though (however whether this line should be omitted in the specific case of non-square grids is also debatable).

Code: Select all

x = 2, y = 2, rule = B/SH
2o$bo!

Code: Select all

x = 3, y = 2, rule = B/SL
3o$bo!
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
Post Reply