Life tag testing

[dvgrn]

I like the AutoFit toggle (new button in upper left corner). It occasionally has odd side effects, though -- try it out with the "B0 rule History test" pattern.

I wonder if there's a good algorithm to settle AutoFit down a little, maybe with a something like a weighted average of the bounding box. With an N-tick moving average, though, fast-moving things will always be wanting to be just off the edge of the view.

I guess a better rule might be along the lines of "If the bounding box gets bigger, make the view bigger immediately, but wait N ticks before starting to reduce the view again. Also limit the reduction per tick to 1/K of the pattern diameter".

Another trick might be to include state>1 cells in the bounding box, at least for [R]History patterns, if that's not too much of a pain. For non-[R]History, maybe only include background cells that haven't completely faded yet?

[rowett]

I like the AutoFit toggle (new button in upper left corner). It occasionally has odd side effects, though -- try it out with the "B0 rule History test" pattern.

Yes that's why I made it [experimental]

I wonder if there's a good algorithm to settle AutoFit down a little, maybe with a something like a weighted average of the bounding box. With an N-tick moving average, though, fast-moving things will always be wanting to be just off the edge of the view.

In the next build it uses a weighted average and is a little smoother. The edge of the view isn't a problem since the zoom always leaves a boundary around the bounding box.

Another trick might be to include state>1 cells in the bounding box, at least for [R]History patterns, if that's not too much of a pain. For non-[R]History, maybe only include background cells that haven't completely faded yet?

For [R]History patterns the state>1 cells are already included. For non-[R]History it's just state=1 but I could experiment with non-completely-faded-dead cells.

The next build has a large number of changes and isn't quite finished yet. When it is it will certainly need some proper testing since I've rewritten and/or optimized most of the core routines.

[rowett]

Build 163 is now available on the lazyslug server.
You can try it out here.

Enhancements in this build:

• added a UI button for fit zoom (hotkey "f")
• added a UI toggle for grid display (hotkey "x")
• the ZOOM control is now always visible at the top of the Viewer
• hide the AutoFit, Fit, Zoom and Grid UI controls when help information is displayed
• improved rendering speed at ZOOM < 1
• extended minimum ZOOM from 0.25x (-4x) to 0.0625x (-16x) and adjusted how zoom values are displayed
• AutoFit is now smoother
• improved snapshot memory usage after reset
• shapshot memory now dynamically grows to reduce GC
• added coloured boxes to help information when showing colours
• increased number of stars for larger zoom out
• improved tile usage during snapshot reset and restore
• moved timing information (hotkey "t") so it no longer overlaps help button
• help information now shows both number of grid tiles and number of colour tiles
• help information now shows when grid lines are switched on but hidden (due to non-zero ANGLE or ZOOM < 4)
• ZOOM UI control is locked when AutoFit on
• added a notification when AutoFit switched on or off
• display notification when ZOOM change attempted via hotkeys or mouse wheel and AutoFit is on
• display notification when X or Y change attempted via hotkeys or mouse pan and AutoFit is on
• increased the height of the standalone Viewer so the area without UI controls is square
• UI library can now draw icons on simple buttons
• updated help information to document that "Esc" stops playback
• help information for [R]History rules now includes state colours as well as Theme colours (since Theme only defines states 0, 1 and 2)
• background drag now scrolls help information and error list when displayed

Fixes in this build:

• the pattern decoder was incorrectly identifying some invalid patterns as Life 1.05 format
• corrected colours on the AutoFit button
• removed duplicate grid clears during startup
• removed duplicate initialisation during standalone Viewer creation
• in some cases the RLE decoder would incorrectly decide invalid rules were valid
• fixed an issue with tile clear failing which caused extra tiles to be processed
• corrected the highlight on UI items that are selected
• when step back (hotkey "b") is disabled (with [[ NOSTEPBACK ]]) do not allocate snapshot 0
• ZOOM control was not being disabled during waypoint playback

This build is a Release Candidate so please test it when you get a moment!

[dvgrn]

Build 163 is now available on the lazyslug server.
You can try it out here.
...
This build is a Release Candidate so please test it when you get a moment!

Wow! We have company coming today, so I've only taken the time to run through the LifeHistory test page, but it looks very good so far.

I'll do an in-context test on a likely forum thread or two, either this morning or tomorrow. A fresh run through to try out all the old and new functionality will take a little longer. In particular, I have ideas for some longer waypoint animations using the new LifeHistory support, that might turn up a subtle bug or two somewhere.

@Nathaniel, if nothing comes up by the end of the weekend, I think this build will be worth risking an "experimental release" -- see if patterns in various existing threads still work as expected. There's no particular reason why they shouldn't, but there are too many cases to pre-test manually -- I don't mind making other forum members do some of the testing, given that a rollback can be done fairly easily with no damage done.

[rowett]

@Nathaniel, if nothing comes up by the end of the weekend, I think this build will be worth risking an "experimental release" -- see if patterns in various existing threads still work as expected. There's no particular reason why they shouldn't, but there are too many cases to pre-test manually -- I don't mind making other forum members do some of the testing, given that a rollback can be done fairly easily with no damage done.

I've tested some more and still no issues (they're clearly well hidden) so definitely worth a release.

Next build will have the simple "Show in Molly" launcher, some further rendering optimizations (when ANGLE = 0 and/or no clipping required) and some new hotkeys. This won't be available for a couple of weeks since I'm travelling.

[dvgrn]

@Nathaniel, if nothing comes up by the end of the weekend, I think this build will be worth risking an "experimental release" -- see if patterns in various existing threads still work as expected. There's no particular reason why they shouldn't, but there are too many cases to pre-test manually -- I don't mind making other forum members do some of the testing, given that a rollback can be done fairly easily with no damage done.

I've tested some more and still no issues (they're clearly well hidden) so definitely worth a release.

Same here -- have looked through several random threads using Build 163 now. Everything seems to be working well.

The only issue I've come up with so far is that LifeViewer doesn't handle patterns with "LifeHistory" in lowercase in the header line, quite as well as Golly does:

Code: Select all

x = 3968, y = 3872, rule = lifehistory
67.30D4B26D$67.D30.4B25.2D$67.D31.4B26.2D$67.D32.4B27.2D$67.D33.4B28.
2D$67.D4.3D27.4B29.2D$67.D3.D3.D27.4B30.2D$67.D3.D3.D28.4B31.2D$67.D
3.5D29.4B32.2D$67.D3.D3.D30.4B33.2D$67.D3.D3.D31.4B34.2D$67.D3.D3.D
32.4B35.2D$67.D41.4B36.2D$67.D42.4B10.D26.2D$67.D43.4B8.D.D27.2D$67.D
44.4B8.2D29.2D$67.D45.4B40.2D$67.D46.4B41.D$67.D47.4B40.D$67.D48.4B
39.D$67.D49.4B38.D$67.D50.4B9.2D26.D$67.D51.4B8.2D26.D$67.D40.D6.2D3.
4B35.D$67.D39.D.D4.D.D4.4B34.D$67.D34.D5.2D3.D.D6.4B33.D$67.D33.D.D
10.D8.4B17.2D13.D$67.D34.2D20.4B10.2D4.2D13.D$67.D57.4B9.2D19.D$67.D
14.2A42.4B29.D$67.D14.2A43.4B28.D$67.D60.4B27.D$67.B61.4B26.D$67.2B
61.4B25.D$67.3B61.4B24.D$67.4B61.4B23.D$67.D4B61.4B22.D$67.D.4B61.4B
21.D$67.D2.4B18.2D41.4B20.D$67.D3.4B16.D.D42.4B19.D$67.D4.4B16.D44.4B
18.D15.D$67.D5.4B61.4B17.D14.D.D$67.D6.4B61.4B16.D14.2D$67.D7.4B61.4B
15.D$67.D8.4B61.4B14.D$67.D9.4B20.D40.4B13.D16.2D$67.D10.4B18.D.D40.
4B12.D15.D.D$67.D11.4B18.2D19.2D20.4B11.D16.D$67.D12.4B37.D.D21.4B10.
D$67.D13.4B37.D23.4B9.D$67.D14.4B61.4B8.D19.2D$67.D15.4B61.4B7.D19.D.
D$67.D16.4B39.3B19.4B6.D20.D$67.D17.4B38.5B6.2D10.4B5.D10.2D$67.D18.
4B36.6B6.2D11.4B4.D9.B2D2B3.2D$67.D19.4B10.D24.8B18.4B3.D10.4B2.B2DB$
67.D20.4B7.3D24.8B10.D8.4B2.D6.B.6B3.2B$67.D21.4B5.D21.B4.9B8.3D4.D4.
4B.D4.10B2.2B15.D$67.D6.2D14.4B4.2D19.3B3.11B5.D6.D.D4.4BD4.11B2D2B
13.D.D$67.D6.2D7.2D6.9B17.6B2.13B3.2D5.2D6.3BD3.12B2D3B.B10.2D$67.D
16.D7.6B13.4B2.7B.13B4.B14.2BDB2.18B2D$67.D16.D.2D5.6B3.B2.2B2.28B5.
3B13.BD2B2.15B.B2D$67.D17.D2.D4.45B3.6B12.D18B3.B$67.D18.2DB3.46B2.
10B9.D18B$67.D19.14B2D13B2D21B.11B3.2B2.BD17B$67.D20.13B2D13B2D26B2D
13BD17B$67.D21.55B2D13BD8B.7B5.2D$67.D21.17B.B5.46BD8B2.8B3.2D$67.D
22.15B10.B2.41BD9B.9B$36.4B28.2D20.15B12.42BD20B$37.4B29.2D19.13B12.
24B2.13B.3BD7.14B16.B$38.4B30.2D11.2D6.13B10.24B2.7B.B5.3BD8.14B14.2B
$39.4B31.2D9.2D5.8B4.2D.D6.2DB2.20B15.4B.D8.15B12.3B$40.4B10.A21.2D
14.6B6.2DB3D3.D.DB2.18B17.2D3.D7.17B.D8.4B$41.4B8.A.A22.2D12.5B8.B4.D
2.D6.18B.B15.D3.D7.16B3D7.5B$42.4B8.2A24.2D10.B.B9.2D.3D2.2D7.18B2D
11.3D4.D8.14BDB8.6B$43.4B35.2D9.3B9.D.D13.18B2D11.D6.D9.13B2D7.7B$44.
4B36.2D6.B2DB9.D.D13.3B3.13B19.D7.17B6.7B$45.4B37.2D5.2D3.2D6.D15.B2.
3B.11B19.D5.18B6.7B$46.4B38.2D7.D2.D24.2D2.9B21.D3.20B5.7B$47.4B39.2D
6.2D26.D3.7B22.D.22B4.7B$48.4B9.2A29.2D29.3D5.4B24.D23B3.7B$49.4B8.2A
31.2D27.D8.5B22.D23B2.7B5.B$38.A6.2A3.4B42.2D17.2D18.2D22.D31B5.2B$
37.A.A4.A.A4.4B43.2D15.2D18.D23.17D14B5.3B$32.A5.2A3.A.A6.4B44.2D34.
3D20.D15BD13B5.4B$31.A.A10.A8.4B17.2A26.2D34.D20.D15BD12B5.4B$32.2A
20.4B10.2A4.2A28.2D25.2D26.D9B2D4BD11B3.2D4B$55.4B9.2A36.2D15.2D6.2D
26.D9B2D4BD10B4.2D3B$56.4B48.2D12.D2.D33.D.14BD9B5.4B$57.4B49.2D11.2D
23.2D9.D2.13BD8B5.4B$58.4B50.2D34.D.D8.D5.3B2D5BD7B5.4B$59.4B51.2D16.
2D15.D.D7.D6.3BD5BD6B5.4B$60.4B52.2D14.D.D15.D8.D.2D3.3D6BD5B5.4B$61.
4B53.2D14.D24.D.2D2.D9BD4B5.4B$B61.4B54.2D12.2D23.D5.DB4D4BD3B5.4B$2B
61.4B55.2D35.D6.2D2BD4BD2B5.4B$3B61.4B56.2D17.D15.D8.2BDBD2BDB5.4B$4B
18.2A41.4B57.2D14.D.D14.D8.3B2D2BD5.4B$.4B16.A.A42.4B58.2D13.2D14.D
10.5BD4.4B$2.4B16.A44.4B34.A24.2D27.D9.5B.D3.4B$3.4B61.4B32.A.A25.2D
25.17D2.4B$4.4B61.4B31.2A28.2D23.D7.D4B5.4B$5.4B61.4B62.2D21.D6.D4B5.
4B$6.4B61.4B63.2D19.D5.D4B5.4B$7.4B20.A40.4B30.2A32.2D22.D4B5.4B$8.4B
18.A.A40.4B28.A.A34.2D19.D4B5.4B$9.4B18.2A19.2A20.4B28.A37.2D16.D4B5.
4B$10.4B37.A.A21.4B67.2D13.D3B6.4B$11.4B37.A23.4B68.2D10.D3B6.4B$12.
4B61.4B28.2A39.2D7.D3B6.4B$13.4B61.4B27.A.A40.2D4.D3B6.4B$14.4B39.3B
19.4B27.A43.2D.D3B6.4B$15.4B38.5B6.2A10.4B16.2A54.D3B6.4B$16.4B36.6B
6.2A11.4B14.B2A2B3.2A46.4B6.4B$17.4B10.A24.8B18.4B14.4B2.B2AB44.4B6.
4B$18.4B7.3A24.8B10.A8.4B9.B.6B3.2B44.4B6.4B$19.4B5.A21.B4.9B8.3A4.A
4.4B6.10B2.2B15.A28.4B6.4B$4.2A14.4B4.2A19.3B3.11B5.A6.A.A4.4B5.11B2A
2B13.A.A26.4B6.4B$4.2A7.2A6.9B17.6B2.13B3.2A5.2A6.4B3.12B2A3B.B10.2A
26.4B6.4B$14.A7.6B13.4B2.7B.13B4.B14.4B2.18B2A36.4B6.4B$14.A.2A5.6B3.
B2.2B2.28B5.3B13.4B2.15B.B2A35.4B6.4B$15.A2.A4.45B3.6B12.19B3.B35.4B
6.4B$16.2AB3.46B2.10B10.18B38.4B6.4B$17.14B2A13B2A21B.11B3.2B2.19B38.
4B6.4B$18.13B2A13B2A26B2A31B37.4B6.4B$19.55B2A22B.7B5.2A30.4B6.4B$19.
17B.B5.55B2.6B5.2A29.4B6.4B$20.15B10.B2.51B.7B34.4B6.4B$20.15B12.53B.
6B33.4B6.4B$21.13B12.24B2.13B.4B7.9B33.4B6.4B$15.2A6.13B10.24B2.7B.B
5.3B9.8B32.4B6.4B$15.2A5.8B4.2A.A6.2AB2.20B15.4B11.8B30.4B6.4B$22.6B
6.2AB3A3.A.AB2.18B17.2A14.7B8.A20.4B6.4B$22.5B8.B4.A2.A6.18B.B15.A15.
6B6.3A19.4B6.4B$22.B.B9.2A.3A2.2A7.18B2A11.3A16.7B4.A21.4B6.4B$23.3B
9.A.A13.18B2A11.A18.7B4.2A19.4B6.4B$22.B2AB9.A.A13.3B3.13B31.8B.4B18.
4B6.4B$23.2A3.2A6.A15.B2.3B.11B31.11B19.4B6.4B$27.A2.A24.2A2.9B33.12B
17.4B6.4B$28.2A26.A3.7B34.12B16.4B6.4B$53.3A5.4B23.2A12.11B15.4B6.4B$
53.A8.5B21.2A15.9B13.4B6.4B$45.2A18.2A37.10B.2B9.4B6.4B$45.2A18.A27.
3B4.B.16B7.4B6.4B$66.3A24.28B3.4B6.4B$68.A23.2A33B6.4B$61.2A29.2A32B
6.4B$53.2A6.2A30.B.30B6.4B$52.A2.A39.29B6.4B63.3A$53.2A42.25B7.4B64.A
$98.B5.17B7.4B66.A$62.2A43.14B6.4B$62.A.A42.14B5.4B$64.A43.2B4.3B8.4B
$64.2A41.2B5.2B8.4B$106.B2AB3.3B7.4B$106.B2A3.4B6.4B$105.B5.4B6.4B$
99.2A3.B5.4B6.4B$99.A3.B5.4B6.4B$96.BA.A2.B5.4B6.4B$96.B2A2.B5.4B6.4B
$94.3B3.B5.4B6.4B$115.4B$114.4B$113.4B$112.4B$111.4B21$248.3A$248.A$
249.A38$264.3A$264.A$265.A38$305.3A$305.A$306.A38$346.3A$346.A$347.A
38$377.3A$377.A$378.A38$410.3A$410.A$411.A38$463.3A$463.A$464.A38$
503.3A$503.A$504.A38$536.3A$536.A$537.A38$579.3A$579.A$580.A38$609.3A
$609.A$610.A38$649.3A$649.A$650.A38$698.3A$698.A$699.A38$747.3A$747.A
$748.A38$778.3A$778.A$779.A38$811.3A$811.A$812.A38$867.2A$866.2A$868.
A38$881.3A$881.A$882.A38$924.3A$924.A$925.A38$961.3A$961.A$962.A38$
1000.3A$1000.A$1001.A38$1085.3A$1085.A$1086.A38$1128.3A$1128.A$1129.A
38$1148.3A$1148.A$1149.A38$1193.3A$1193.A$1194.A38$1226.3A$1226.A$
1227.A38$1267.3A$1267.A$1268.A38$1297.3A$1297.A$1298.A38$1360.3A$
1360.A$1361.A38$1399.3A$1399.A$1400.A38$1437.3A$1437.A$1438.A38$1477.
3A$1477.A$1478.A38$1535.3A$1535.A$1536.A38$1576.3A$1576.A$1577.A38$
1616.3A$1616.A$1617.A38$1663.3A$1663.A$1664.A38$1705.3A$1705.A$1706.A
38$1734.3A$1734.A$1735.A38$1785.3A$1785.A$1786.A38$1828.2A$1827.2A$
1829.A38$1855.3A$1855.A$1856.A38$1914.3A$1914.A$1915.A38$1957.3A$
1957.A$1958.A38$1989.3A$1989.A$1990.A38$2030.3A$2030.A$2031.A38$2074.
3A$2074.A$2075.A38$2104.3A$2104.A$2105.A38$2161.3A$2161.A$2162.A38$
2208.3A$2208.A$2209.A38$2236.3A$2236.A$2237.A38$2281.2A$2280.2A$2282.
A38$2317.3A$2317.A$2318.A38$2362.3A$2362.A$2363.A38$2402.3A$2402.A$
2403.A38$2445.3A$2445.A$2446.A38$2477.3A$2477.A$2478.A38$2518.3A$
2518.A$2519.A38$2562.3A$2562.A$2563.A38$2590.3A$2590.A$2591.A38$2650.
3A$2650.A$2651.A38$2691.3A$2691.A$2692.A38$2722.3A$2722.A$2723.A38$
2759.3A$2759.A$2760.A38$2799.2A$2798.2A$2800.A38$2830.2A$2829.2A$
2831.A38$2881.2A$2880.2A$2882.A38$2917.3A$2917.A$2918.A38$2965.3A$
2965.A$2966.A38$2995.3A$2995.A$2996.A38$3069.3A$3069.A$3070.A38$3106.
3A$3106.A$3107.A38$3146.3A$3146.A$3147.A38$3184.2A$3183.2A$3185.A38$
3233.3A$3233.A$3234.A38$3279.2A$3278.2A$3280.A38$3307.3A$3307.A$3308.
A38$3351.3A$3351.A$3352.A38$3383.3A$3383.A$3384.A38$3424.3A$3424.A$
3425.A38$3467.2A$3466.2A$3468.A38$3508.3A$3508.A$3509.A38$3549.3A$
3549.A$3550.A38$3574.3A$3574.A$3575.A38$3607.3A$3607.A$3608.A38$3646.
3A$3646.A$3647.A38$3699.2A$3698.2A$3700.A38$3737.2A$3736.2A$3738.A38$
3770.3A$3770.A$3771.A38$3825.3A$3825.A$3826.A38$3855.3A$3855.A$3856.A
38$3902.3A$3902.A$3903.A38$3952.3A$3952.A$3953.A38$3965.3A$3965.A$
3966.A!
[[ X 1880 Y 1850 ZOOM 2.22 STEP 32 ]]

But that problem is there in Build 160 as well, so I don't see any harm in releasing Build 163 as-is.

[Nathaniel]

Build 163 is live!

[rowett]

Build 163 is live!

Awesome, thanks Nathaniel!

[rowett]

The only issue I've come up with so far is that LifeViewer doesn't handle patterns with "LifeHistory" in lowercase in the header line, quite as well as Golly does

Should I handle all rule and alias names in a case-insensitive manner?

Life = life = LIFE
B23/3 = b23/3
lifehistory = LifeHistory = LIFEHISTORY
Gnarl = GNARL = gnarl ?

[dvgrn]

The only issue I've come up with so far is that LifeViewer doesn't handle patterns with "LifeHistory" in lowercase in the header line, quite as well as Golly does

Should I handle all rule and alias names in a case-insensitive manner?

Life = life = LIFE
B23/3 = b23/3
lifehistory = LifeHistory = LIFEHISTORY
Gnarl = GNARL = gnarl ?

Yes, I think that's pretty safe. On OSes with case-sensitive filenames you can technically define different behavior for different capitalizations, but Golly tends to give annoying warnings when things don't match up. I don't know of any cases where someone has deliberately defined two different rules with identical names except for capitalization.

EDIT: What's keeping LifeViewer from recognizing the two patterns in new-user Linicks' post? I thought it was the lack of a "rule =", or the blank line after the header, or the missing ! at the end of the RLE... but it turns out that the header just has to be changed to say y = 53 or greater, and then LifeViewer is happy -- even if the X value still says -30.

In the course of writing a file-format summary, I discovered that LifeViewer doesn't recognize ASCII format if there are any other comment lines besides the #P header:

Code: Select all

#GLF 1.0
#P-30,-20
....*....
..*.*....
.........
...*.....
..*.*....
......*..
.........
............
..****......
*.**........
..*.**......
...*.***....
*.....*.....
*..*..*.....
............
................
......*...*.....
..*..*.*.*......
.....*...*.*....
.*.*...*........
....***.*.......
.*....*****.....
...*.*.....*....
..***.*.**......
.*.*.*..*.*.....
................
....................
......*....*.*......
..*.*********.......
...***......*.*.....
....***.....*.......
.....*.*...**.*.....
.....*..**.*.*......
...*..*..**.........
........*..**.......
....***.......*.....
...*.**...***.*.....
.....*..............
...*..*.**.**.*.....
....................
........................
............*.**........
...*.*..*****.***.......
...*.***..*..***........
.....*....*....*........
......**..**..**........
...*.*.*...*...*.*......
......**.**.***.........
....*.*...**.*..*.......
...*..***.......*.......
.....*..***...**........
...*.....********.......
...........**.**.*......

And speaking of all this #P and #CXRLE positional stuff, I think the idea has come up before of having an option to mouse over a cell in the LifeViewer and see what its coordinates are. Am I missing a toggle button somewhere that does that? It's getting hard to keep track...! Maybe it could be an option only available when the Menu is visible.

[rowett]

EDIT: What's keeping LifeViewer from recognizing the two patterns in new-user Linicks' post?

The released LifeViewer build (163) is unhappy if the defined y (and x) are incorrect. This is already fixed in the next build.

In the course of writing a file-format summary, I discovered that LifeViewer doesn't recognize ASCII format if there are any other comment lines besides the #P header:

Code: Select all

#GLF 1.0
#P-30,-20
....*....
..*.*....
.........
...*.....
..*.*....
......*..

This is actually failing because LifeViewer doesn't think that #GLF is a valid Life 1.05 pattern format command. It's only expecting:

• #C or #D for comments
• #N for default (Conway Life) rule
• #P for a cell block
• #R for a custom defined rule

What is the canonical set of # commands for Life 1.05?

And speaking of all this #P and #CXRLE positional stuff, I think the idea has come up before of having an option to mouse over a cell in the LifeViewer and see what its coordinates are. Am I missing a toggle button somewhere that does that? It's getting hard to keep track...! Maybe it could be an option only available when the Menu is visible.

You're not missing something it's still on the backlog.

[dvgrn]

This is actually failing because LifeViewer doesn't think that #GLF is a valid Life 1.05 pattern format command. It's only expecting:

• #C or #D for comments
• #N for default (Conway Life) rule
• #P for a cell block
• #R for a custom defined rule

What is the canonical set of # commands for Life 1.05?

You have them all. A good standard resource is the old MCell documentation on file formats.

In regular RLE, the #O, #P, #R, and (especially) #r tags aren't used much any more. #N recently made a minor comeback in the elementary conduits collection, but it's not really important for most Life editors to be able to handle #N name lines -- they're just part of the comments.

It seems as if the new developing standard is that, for any file format, if a line starts with # and the next character isn't anything you were particularly looking for, it can be safely treated as a comment and ignored -- just go on to the next line and see if that looks like a Life file or not.

[rowett]

And speaking of all this #P and #CXRLE positional stuff, I think the idea has come up before of having an option to mouse over a cell in the LifeViewer and see what its coordinates are. Am I missing a toggle button somewhere that does that? It's getting hard to keep track...! Maybe it could be an option only available when the Menu is visible.

You're not missing something it's still on the backlog.

This is now no longer on the backlog and will be in the next released build.
The cell coordinates under the mouse cursor are displayed at the bottom left of the Viewer window when playback is paused and disappear during playback. If stats are switched on (with hotkey "g") the cell coordinates are always displayed.

[rowett]

Build 164 won't be released until the weekend since I'm travelling but contains the following:

Enhancements in this build:

• display cell coordinates under mouse cursor (when ANGLE = 0)
  • coordinates automatically display when paused and disappear during playback unless stats are on (hotkey "g")
• shift and hotkey "2" now sets ZOOM to -2x (used to be on hotkey "5" which now does nothing)
• shift and hotkey "4" now sets ZOOM to -4x
• shift and hotkey "8" now sets ZOOM to -8x
• shift and hotkey "6" now sets ZOOM to -16x
• shift and hotkey "z" now pauses all Viewers (unlike hotkey "z" which pauses all other Viewers)
  • improved notification message when Pause other/all LifeViewers is used (hotkey "z"/shift "z")
• [[ ZOOM ]] script command now accepts negative zoom values -16 to -1 (as well as 0.0625 to 1)
• faster rendering when ANGLE = 0 and/or clipping not required

Fixes in this build:

• population count for T=0 was incorrect in some cases
• Fit Zoom was incorrect for [R]History patterns that had no live cells
• RLE pattern decoder is now case-insensitive for rule names and aliases
• RLE pattern decoder can now deal with incorrect x and y values
• Life 1.05 pattern decoder now ignores non-standard # commands

It will also possibly contain the "SHOW IN MOLLY" link generation but this will need input from Andrew and Nathaniel.

Dave is there anything else burning on (or not yet on) the backlog you're waiting (or hoping) for?

[dvgrn]

Dave is there anything else burning on (or not yet on) the backlog you're waiting (or hoping) for?

That's a very dangerous question to ask. But for the moment I'm still very far behind on exercising all the new functionality that's already in place. Have to come up with an [R]History rule-making script in Golly, for example.

There's one thing that I think would be an improvement, that I've mentioned in passing before, but maybe not persuasively enough... When I'm backspacing with the 'b' key and get to the beginning of the saved snapshots, the "No previous generation" message still kind of bothers me. It seems as if it would seldom take very much time to calculate a new set of snapshots, starting from T=0 if necessary.

I'd rather the viewer took whatever time it needed to get to T=N-1, instead of me having to Reset and then run forward manually to the T=N-1 point of interest again. When I have my finger on the 'b' key, I don't want to stop and reach for the mouse or other shortcut keys -- I want to go backwards!

Maybe if the user keeps stubbornly hitting the 'b' key or the backtrack button after the initial warning message comes up, it might trigger a "Buffering -- please wait" message -- in the rare cases where calculating new snapshots would really take more than a fraction of a second.

That's just a random crackpot idea, though. Really these recent builds of LifeViewer are getting really impressively good!

[rowett]

There's one thing that I think would be an improvement, that I've mentioned in passing before, but maybe not persuasively enough... When I'm backspacing with the 'b' key and get to the beginning of the saved snapshots, the "No previous generation" message still kind of bothers me. It seems as if it would seldom take very much time to calculate a new set of snapshots, starting from T=0 if necessary.

It would always need to go back to T=0 so in extreme cases this would take a long time (extreme meaning busy patterns and a large T). I'll take a look and see what the performance is like.

The other option could be to allow the user to specify a single snapshot themselves which you can always quickly go back to (rather than all the way back to the beginning). Thoughts?

The other thing I've been pondering recently is the LifeViewer 2-state engine computes a lookup table (based on the B/S rule) for fast next generation computation. At the moment the lookup table is populated from the B/S rule using Moore neighborhood. Basically for each combination of cells in the neighborhood it pre-computes the answer. At run time it just has to look up the result in the table (which actually is 4 bits wide so it gets 4 cells per lookup).

It could equally well do the same for Von Neumann neighbourhood (just ignore the NE, SE, NW and SW cells) or even either neighborhood for a non-totalistic rule.

The runtime wouldn't change, I'd just need to enhance the parser to recognise the different rule formats and build table generators.

Is there a reasonable ROI for this work? i.e. would anyone care or use it?

[dvgrn]

It would always need to go back to T=0 so in extreme cases this would take a long time (extreme meaning busy patterns and a large T). I'll take a look and see what the performance is like.

It's probably possible for LifeViewer to guess pretty accurately whether re-snapshotting would take a lot of work or not, just based on T and the size of the pattern, as you said. If it's likely to take more than a second, then I think a pop-up "Taking new snapshots -- back soon" message would be appropriate, and maybe even appreciated.

The other option could be to allow the user to specify a single snapshot themselves which you can always quickly go back to (rather than all the way back to the beginning). Thoughts?

That seems like a good idea. I think hotkey J-for-JumpBackBaseLocation hasn't been taken yet? The hotkey map isn't quite up to date at the moment, though, so you might have used up all of the few remaining keys while I wasn't looking...!

Really if I'm doing very much close inspection of a pattern that's large enough to make it useful to have a user-defined JumpBack location, I'm probably just going to move the pattern over to Golly, where I can select and mark and unlimited-undo to my heart's content.

And I can change the default view location in Golly, too -- hotkeys "0" to set a new origin and "M" to jump back to it... though I never actually use those keys, and in fact I've re-mapped "M" to change the cursor mode the way it did in MCell, so I don't quite know why I'm mentioning it. I guess it seemed analogous to setting a jumpback location... maybe the right generalization is that the key jumpback point is actually a position in spacetime.

I seem to remember there was a feature in Life32 that allowed you to set multiple "named view" locations and jump quickly between them. In the context of LifeViewer, it seems as if something vaguely like that could be done with waypoints and labels, but I'm not sure how a user might pick a specific waypoint to jump to.

The other thing I've been pondering recently is the LifeViewer 2-state engine computes a lookup table (based on the B/S rule) for fast next generation computation. At the moment the lookup table is populated from the B/S rule using Moore neighborhood... It could equally well do the same for Von Neumann neighbourhood (just ignore the NE, SE, NW and SW cells) or even either neighborhood for a non-totalistic rule.
...
Is there a reasonable ROI for this work? i.e. would anyone care or use it?

I think that's probably something to ask on the general-membership Pattern Viewer thread. I don't seem to wander around outside of the Moore neighborhood very much, myself.

-------------------------------

EDIT: Another minor feature request idea that came up today, that might be worth implementing if it's easy:

Now that we have acceleration up to 32 ticks/frame, it's gotten relatively easy to follow moving objects to the edge of the universe, where they crash suddenly and spectacularly into a completely invisible barrier. Is it possible to make the barrier visible somehow?

It probably doesn't really matter what happens at the edge, but it would be nice to avoid behavior that doesn't match the rule, as much as possible anyway. In particular, *WSSes that crash and turn into gliders that head back the other way just seem wrong somehow -- it creates objects that shouldn't really be part of the simulation, that then have to be tracked further.

It probably wouldn't be any good keeping track of actual LifeHistory-type gray cells all the way around the boundary, but I wonder if it would work if the Edge of the Universe killed new ON cells in the same way as gray cells do?

EDIT2: This seems like a good place to advertise Scorbie's use of LifeViewer to make an autoscrolling stamp collection of catalysts. Nice!

[rowett]

I seem to remember there was a feature in Life32 that allowed you to set multiple "named view" locations and jump quickly between them. In the context of LifeViewer, it seems as if something vaguely like that could be done with waypoints and labels, but I'm not sure how a user might pick a specific waypoint to jump to.

Here's my current thinking:

• Allow users to specify a camera reset position. Hotkey "v" already resets (just the view) to the T=0 position without changing T. I could add another hotkey or perhaps shift and "v" to set the camera reset position to the current camera position.
• Allow users to specify multiple camera positions
• Allow users to specify multiple positions in space time (camera position at a particular T/elapsed time)
• For waypoint patterns automatically generate snapshots at each waypoint change allowing rapid step forward/back through the waypoint list (the original LifeViewer actually does this)
• Add script commands to allow definition of points 1, 2 and 3 above

Not directly related but perhaps also useful:

• Add script command to allow running up to an initial T value with the display off so pattern visualisation starts at a particular T with history already displayed for previous generations, with also the ability to step back beyond the first displayed generation
• Add a script command to set the [[ LOOP ]] target T so it goes back to a user defined T rather than 0

Now that we have acceleration up to 32 ticks/frame, it's gotten relatively easy to follow moving objects to the edge of the universe, where they crash suddenly and spectacularly into a completely invisible barrier. Is it possible to make the barrier visible somehow?

It's actually already "visible". It's just drawn in the background colour using the state 0 pen colour. I could easily change it to make it the LifeHistory state 6 pen colour by default (for any rule type).

It probably doesn't really matter what happens at the edge, but it would be nice to avoid behavior that doesn't match the rule, as much as possible anyway. I wonder if it would work if the Edge of the Universe killed new ON cells in the same way as gray cells do?

Yes, that's a good idea.

EDIT2: This seems like a good place to advertise Scorbie's use of LifeViewer to make an autoscrolling stamp collection of catalysts. Nice!

Awesome. Almost why we designed the waypoint system in the first place!

[dvgrn]

Here's my current thinking...

These all look like good ideas. Quick reactions:

Extending hotkey "V" seems like a relatively simple solution, maybe with an associated script command to allow a pattern to have one pre-set defined view as you said.

Multiple views don't seem so necessary unless they can be named.

There's a way to show a popup label at a spacetime location during waypoint playback, but I'm not sure the label will always be a good name for the view.

Some views are time-dependent -- the spacetime location of a key reaction, let's say. Those make sense to include in a series of waypoints. But some views make equal sense for any T value -- different sections of a stamp collection, let's say, or different parts of a piece of complex circuitry like a universal constructor or Calcyman's pi calculator.

These "T-independent" views would be nice to be able to define in a script, but not necessarily zoom and pan between them as part of standard waypoint playback behavior -- it's more something that a user can click to go and see if they're interested, or maybe hit a hotkey to move to the next defined view (and then see the popup label).

Then... when you start talking about allowing users to set multiple views, it starts to seem as if you should really just be providing some way of letting them make their own additions to a script -- kind of a "recorder macro" function, I suppose. Maybe the right thing to do would be to allow access (view and copy) to the script that has been created. This would be a new can of worms, and it gets a little bit away from strict "viewer" functionality -- but really it would be a lot more useful, and makes it more likely that more people will actually write scripts and put labels on their patterns.

I think there won't usually be much point in setting or naming multiple viewpoints, unless the work can be easily saved and re-used. Otherwise probably one viewpoint at a time will be good enough.

Not directly related but perhaps also useful:

• Add script command to allow running up to an initial T value with the display off so pattern visualisation starts at a particular T with history already displayed for previous generations, with also the ability to step back beyond the first displayed generation
• Add a script command to set the [[ LOOP ]] target T so it goes back to a user defined T rather than 0

Hmm, I used to want these a lot more. You can tell in the patterns I posted on the glider-guns thread when the LOOP kicks in, because the history disappears and then is quickly filled in again. But now that the LifeViewer supports [R]History, it's easy to work around that by just including whatever history cells you want in the initial pattern.

The [R]History workaround does increase the size of the pattern by quite a bit, though, so these would both still definitely be good features. Would want some kind of progress bar to show that LifeViewer was doing something, if it was not displaying the pattern for a long time.

-- Hey, and couldn't we do the first item already as well, by setting a custom all-black theme, running up to our target, and switching back to a standard theme?

[rowett]

Hey, and couldn't we do the first item already as well, by setting a custom all-black theme, running up to our target, and switching back to a standard theme?

Yes indeed. In fact I used a similar technique at the end of the LIFEVIEWER How Your Username Evolves animation.

[rowett]

Build 165 is now available on the lazyslug server.
You can try it out here.
The updated hotkey map is here.

Enhancements in this build:

• step back is now unlimited
  • increased step back buffer to 1024 generations
  • when step back buffer exhausted automatically compute the previous set of generations
• area outside maximum grid size is now drawn in gray
• shift and hotkey "v" now saves camera position
  • hotkey "v" now restores saved camera position
• shift and hotkey "c" switches to default Theme

Fixes in this build:

• growing the grid was not being triggered early enough at high STEP sizes

Notes:

• step back function does not behave very well with waypoints yet

[rowett]

Build 166 is available on the lazyslug server.
You can try it out here.
The updated hotkey map is here.

Enhancements in this build:

• ability to define points of interest
  • script command [[ POI ]] followed by X, Y, and ZOOM definitions
  • hotkey "j" to jump to next point of interest
  • shift and hotkey "j" to jump to previous point of interest
  • list of POI definitions added to help information
  • notification if attempt to switch POI while AutoFit is enabled
• added "OPEN MOLLY" link for patterns that are either too big for LifeViewer or patterns that LifeViewer can display but not execute
  • currently just points to Molly on Andrew's site but will be updated to a "SHOW IN MOLLY" link once we agree a pattern passing mechanism

The second test "POI test" has four points of interest defined. Cycle through them with hotkey "j".

[rowett]

Build 167 is available on the lazyslug server.

Enhancements in this build:

• improved performance when computing previous generations for step back function (hotkey "b")
• script command [[ SHOWTIMING ]] will display timing information at pattern load (hotkey "t" to toggle)
• script command [[ SHOWGENSTATS ]] will display generation statistics at pattern load (hotkey "g" to toggle)
• [[ AUTOFIT ]] keyword will now set AutoFit on at pattern load when no Waypoints are specified

Fixes in this build:

• ensure AutoFit reaches target camera position

[rowett]

It probably doesn't really matter what happens at the edge, but it would be nice to avoid behavior that doesn't match the rule, as much as possible anyway. In particular, *WSSes that crash and turn into gliders that head back the other way just seem wrong somehow -- it creates objects that shouldn't really be part of the simulation, that then have to be tracked further.

Dave,
Do you have an example pattern that does this?

[dvgrn]

*WSSes that crash and turn into gliders that head back the other way just seem wrong somehow...

Do you have an example pattern that does this?

Sure. LWSSes and MWSSes both do odd things at the edge, though only the LWSS makes a reverse glider:

Code: Select all

x = 41, y = 6, rule = B3/S23
3o34b3o$o2bo33bo2bo$o36bo$o36bo$bo35bo$38bo!
#C [[ THUMBNAIL AUTOSTART ZOOM .5 STOP 1100 GPS 60 STEP 32 ]]

A dragon explodes into a lot of beehives and honeyfarms, but doesn't produce any reverse gliders in the current build. Why the apparent discrepancy between universe size horizontally and vertically, by the way?

Code: Select all

#N Dragon
#O Paul Tooke
#C An orthogonal period 6 spaceship. The first c/6 spaceship to be constructed.
#C http://www.conwaylife.com/wiki/index.php?title=Dragon
x = 29, y = 18, rule = B3/S23
12bo16b$12b2o14bo$10bob2o5bobo4b2ob$5bo3bo3b3o2bo4bo5b$2o3bo2bo6bobo5b
3o2bo$2o3bob2o6bo3bobobo5b$2o3bo10bobo7b2ob$5b2o14bo6bo$7bo12bobo6b$7b
o12bobo6b$5b2o14bo6bo$2o3bo10bobo7b2ob$2o3bob2o6bo3bobobo5b$2o3bo2bo6b
obo5b3o2bo$5bo3bo3b3o2bo4bo5b$10bob2o5bobo4b2ob$12b2o14bo$12bo!
#C [[ THUMBNAIL AUTOSTART X 2000 ZOOM .1 STOP 25000 GPS 60 STEP 32 ]]

Usually the bigger the spaceship, the bigger the mess. This one, from the Cool Rules with One Known Glider thread, behaves a bit strangely -- crashes into something, but then it seems like the something must not be the edge of the universe after all. I'm not sure what if anything can be done to control edge effects in this kind of explosive rule:

Code: Select all

x = 20, y = 171, rule = B36/S123
11b3ob2o$3bo6b7o$2b6o2b2o2bob2o$2b2ob2ob2o2bo2bob2o$2bo2bo2bobo2b3ob2o
$2b3obob2o3bo3bo$2bo6b2o2b5o$2b4obobo2bo4b2o$3bo2b2obo3bobob2o$2obobob
ob3ob2o2bo$2obob2o2bob4o2b2o$bobo3bobobobobobo$2b2obobob3o3b2o$3bo2b2o
bobobobo$3bob2o2bob4o$2b2o3bobo$2b6obo6bo$3b2ob4ob2ob2o$4b2o3bobob2o$
5bo4bob3o$6b3ob2o$6b2obobo$7bob2o$5bo2bo2bo$10bo2bo$13bo$5b4o3bo$8bo3b
2o$5b2obobo$5b2ob3ob2o$6bo3bo$7bo2bobo$6bo3bo$6b2o$5b3obobo$5b2o2bob2o
$6bo3bobo$6bo3b3o$5b2obob2o$4bob2o2bobo$2b4o4bobo$2b4o4bo2b3o$3b2o2bo
2bo3b3o$3bo6bo4bo$2bo3bo3b6obo$2bobo5bobo2bo$bo4bobobo3b2o$b2ob2ob2ob
2o3bo3bo$bo2bo2bo3bobo2bo$bob2o3b2o3bo3bo$bob2o3b3o2bobobo$2bob4o4bo3b
o$2b2o2bo5b4o$4b2o9bo$5bo8bo$5b2o6b3o$b2obob3o5b2o$b3o3b3o2bobo$2bo2b
2obobobobob2o$2bobo3b3obobob2o$b2ob2o8bobo$3b2obo2bo4b4o$b2o7b2o$7bo3b
o2bob2o$b2obo3bo2bo2bo$bo2bo3b3o3b2o$2obo11b2o$2ob2o11b2o$bo2b3obo2bo
5bo$bo2b2ob2o5b3o$2b2o3b4o2b2obo$4b4ob3o2bo$5b2o2bo2b2o$10bo5bo$4b2o3b
3o$2b2obob2ob4o$6b2o3b2o3bo$3bo3bo4b4o$4b3o7bo$12b2o$3bob2o$12b2o2b2o$
3bob2o6bob4o$2o4b3o4bo3b2o$o2b2ob3o2b3o2b2o$b2o2bo2b2o2b3o$7b3o6b2o$b
2o4b3o$b2o2bob3o3b5o$7b2obo3bo$3bobo2b3o$6bo2bo4bo$bo4bo6b3o$4b2obo4bo
3bo$2bob2o2bo4b2ob2o$2bo2b4obob3obo$3bo2b2o3b2o3bo$3bo8bob2o$7bo5bo$4b
2o3bo$4bo6b3o$3bo2bo3bobo$4bob3ob2o2b2o$7b2obo2b3o$4b3o3b3obo$5b2o3bob
2o$6bo3bobo$10bo$7bo$6bo2b2o$5b4obo$5b3o2bobo$4b2o4b4o$2b5ob3ob2o$b5o
3bo3bo$b4o11b2o$2bo12b2o$14b2o$3bobo7bo$3bo$13b2o$bo2b2obobob5o$5b7o2b
o2bo$4b2obo2bobo4bo$b3obo2b2ob2o3bo$4b2o5b2o3b2o$b2o3bo5bobo$4bobo5b3o
b2o$b3obo7bo2b2o$3b2o11bo$3b2o10bo$3bo3bo6bo$4bo8bo$7bo3b2obo$5bo4bo$
5bo2bo2bo$4bo2bobo2bobo$5bo2b2ob2o$6b2obo4b3o$2bo6bo2b5o$3bo6b2obobo$
4b11o$4b3o2bo2b3o$5bo4bo2bo$10bo$7bo2bo$10bo$3bo4bo$9b4ob2o$3bo2b3obo$
4b3o2b3o2bo$7b2ob4o$5b2obobo$8b3ob2o$5b2obo2bo2bob2o$b2obo3bo4b5o$2b2o
bo2bo4bob2o$2bo2bo2b3o2b3o$3b2o3bobobo$6bobobobob2o$3b4obo$3bo2bo3bo3b
2o$4b3o2b5o$5b3o4b2o$5bo3b3o2bo$6b3o3b3o$6b2o3b2obo$4bo3bo5bo$5b4obob
2o$5b3o3b3o$6bo5bo!
#C [[ THUMBNAIL GPS 60 STEP 32 ]]