Pattern viewer for forum threads

[muzik]

I've done some testing to see if I can triangulate the issue and the results are as follows:

Up to and including build 1152, we get an average framerate of around 59fps to 60fps, which is the expected behaviour.

From build 1153 onwards to the current version, the framerate is consistently lower, usually fluctuating from 49fps to 55fps.

Should be fixed in build 1328.

Indeed we now seem to be back to normal, thanks for this!

IMG_2108.jpeg (244.94 KiB) Viewed 2934 times

Performance with icons now also seems to be just fine as well now, unlike previously where it would cut framerates in half.

Also, is there any way to maximize a popup viewer without using a keyboard?

Yes, I've added a toggle in the Settings menu.

I wonder if it'd make more sense to put this in the top bar to the left of the close button since this is what most windows tend to do.

[rowett]

I wonder if it'd make more sense to put this in the top bar to the left of the close button since this is what most windows tend to do.

I've added it to the top bar. It needs to be in both places (like the Close button) since on some devices the title bar is too small to click / tap.

[muzik]

I wonder if it'd make more sense to put this in the top bar to the left of the close button since this is what most windows tend to do.

I've added it to the top bar. It needs to be in both places (like the Close button) since on some devices the title bar is too small to click / tap.

To make it stick out more (as well as be more consistent with the close button) it may be worth adding a background colour to it as well.

Another thing I've noticed is that pressing F9 with an embedded viewer in focus, then opening a popup viewer, will have it automatically open in maximized mode. There's no indication in the embedded viewer that pressing F9 does anything - I don't know if it should display an error, be silently ignored, display a message saying that the next popup is maximized, or if the current behaviour is already correct. This only appears to happen if a popup viewer has already been opened, and then closed.

Code: Select all

# example pattern to open as popup
x = 3, y = 1, rule = B3/S23
3o!

Code: Select all

# example embedded pattern
x = 3, y = 1, rule = B3/S23
3o!

I've reported similar issues before I believe, so the root cause may be the same, but for these four patterns, using the "Fit Pattern" button will cause four distinct things to happen, despite the outcomes in terms of history and dying cells being very similar:

Code: Select all

x = 2, y = 4, rule = /2/2
o$bo$bo$o!
[[ MAXGRIDSIZE 9 AUTOSTART STEP 64 X 256 ]]

Code: Select all

x = 2, y = 4, rule = R1,C2,S,B2
o$bo$bo$o!
[[ MAXGRIDSIZE 9 AUTOSTART STEP 64 X 256 ]]

Code: Select all

x = 2, y = 4, rule = /2/3
o$bo$bo$o!
[[ MAXGRIDSIZE 9 AUTOSTART STEP 64 X 256 ]]

Code: Select all

x = 2, y = 4, rule = R1,C3,S,B2
o$bo$bo$o!
[[ MAXGRIDSIZE 9 AUTOSTART STEP 64 X 256 ]]

[muzik]

The colours of the new maximize button appear to be hardcoded - there don't seem to be any new elements we can change the color of to modify it, nor does changing the colours of any existing element have any effect. This also affects the shadows of polygons, the shadow behind popup viewers and the thin grey border of popup viewers:

Code: Select all

x = 1, y = 48, rule = MAPBJ8g/wSfIP8EnyD/AP8A/w
o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$o$
o$o$o$o$o$o$o$o$o$o$o$o$o!
[[
COLOR BACKGROUND White
COLOR DEAD White
COLOR DEADRAMP White
COLOR ALIVE Pink
COLOR ALIVERAMP Pink
COLOR GRID Pink
COLOR GRIDMAJOR Pink
COLOR BOUNDARY Pink
COLOR SELECT Pink
COLOR PASTE Pink
COLOR SELECTED Pink
COLOR GRAPHBG Pink
COLOR GRAPHAXIS Pink
COLOR GRAPHALIVE Pink
COLOR GRAPHBIRTH Pink
COLOR GRAPHDEATH Pink
COLOR UIFOREGROUND Pink
COLOR UIBACKGROUND Pink
COLOR UIHIGHLIGHT Pink
COLOR UISELECT Pink
COLOR UILOCKED Pink
COLOR UIBORDER Pink
COLOR TEXT Pink
COLOR ERROR Pink
COLOR HELP Pink
COLOR STARS Pink
COLOR TITLEBACKGROUND Pink
COLOR TITLEFOREGROUND Pink
COLOR CLOSEBACKGROUND Pink
COLOR CLOSEFOREGROUND Pink
COLOR SNOW Pink
MAXGRIDSIZE 9 ZOOM 4
COLOR POLY Pink POLYFILL 1 2 1 46 45 46 1 2 4 ]]

This may be a touchscreen-exclusive issue as I haven't been able to reproduce it on PC, but maximizing a viewer then restoring it to its initial size makes it impossible to move it by dragging the top bar, unless you close it and then open another one.

Also, is it just me, or are polygons and such on hexagonal grids a bit distorted? I'd expect this to create an equilateral triangle, with each vertex centered on one of the three outer hexagonal cells, but we see deviation in all three, and the resulting triangle is ultimately not regular.

Code: Select all

x = 7, y = 7, rule = B/S0123HT
o4$2bo2$o5bo!
[[ POLYSHADOW OFF COLOR POLY White POLYLINE 0 0 0 6 6 6 0 0 32 COLOR ALIVE 64 64 64 ]]

This issue does not appear to be nearly as prevalent, if at all, on the triangular grid (there may be a slight upward bias but things otherwise look pretty regular):

Code: Select all

x = 16, y = 9, rule = B/S0123LE
$8bo7$bo13bo!
[[ POLYSHADOW OFF COLOR POLY White POLYLINE 8 1 1 8 15 8 8 1 32 COLOR ALIVE 64 64 64 ]]

As expected, squares look just about perfect:

Code: Select all

x = 8, y = 8, rule = B/S01234V
o6bo7$o6bo!
[[ POLYSHADOW OFF COLOR POLY White POLYLINE 0 0 0 7 7 7 7 0 0 0 32 COLOR ALIVE 64 64 64 ]]

[rowett]

The colours of the new maximize button appear to be hardcoded

Fixed in build 1331.

This may be a touchscreen-exclusive issue as I haven't been able to reproduce it on PC, but maximizing a viewer then restoring it to its initial size makes it impossible to move it by dragging the top bar, unless you close it and then open another one.

This looks like an iOS/Safari bug. I'll see if I can find a workround.

Also, is it just me, or are polygons and such on hexagonal grids a bit distorted?

Fixed in build 1332.

[muzik]

Thank you once again for these fixes!

One minor thing I noticed is that in Help -> Info -> UI, the default value displayed for the fullscreen button background colour is the same as the close button's, which I do not think is correct. If we change the colour via a script command it correctly displays that colour.

Code: Select all

x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!

Code: Select all

x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!
[[ COLOR FULLSCREENBACKGROUND 80 80 199 COLOR FULLSCREENFOREGROUND White ]]

Unlike with the close button the in-viewer fullscreen button does not follow FULLSCREENBACKGROUND, and instead uses UIBACKGROUND like most other buttons, which could be intentional, but I'm not sure.

Code: Select all

x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!
[[ COLOR UIBACKGROUND 80 80 199 ]]

The width of the two buttons on the top bar appears to be influenced by how the browser displays font characters - I noticed on desktop it's closer to a tall rectangle, especially for the fullscreen button, whereas on an iPad they're both closer to squares. For consistency's sake, could they both be made regular squares? Here's a comparison:

desktopbuttonwidths.png (19.7 KiB) Viewed 2841 times

tabletbuttonwidths.png (158.56 KiB) Viewed 2841 times

The thinner button on desktop also exacerbates this irritating phenomenon where the scroll bar only appears when the mouse is close, and it occludes most of it - this could be mostly resolved by having the position where the popup initially appears be slightly offset from the right of the window.

overlapannoyance.png (20.33 KiB) Viewed 2841 times

I think it might be better to use a character like ∧ for the fullscreen button so it's more vertically centered and in line with the close button (and maybe it could use the multiplication character × instead so it looks more geometrically regular, like was done for diagonally-flipping oscillator results in Identify).

Finally: could a button to create a popup viewer be added to the LifeViewer Pro test page (and by extension, the base /lifeview/ and /lifeviewer/ pages)?

[rowett]

One minor thing I noticed is that in Help -> Info -> UI, the default value displayed for the fullscreen button background colour is the same as the close button's, which I do not think is correct.

Fixed in build 1333.

Unlike with the close button the in-viewer fullscreen button does not follow FULLSCREENBACKGROUND, and instead uses UIBACKGROUND like most other buttons, which could be intentional, but I'm not sure.

Yes this is by design.

The width of the two buttons on the top bar appears to be influenced by how the browser displays font characters

Improved in build 1333.

The thinner button on desktop also exacerbates this irritating phenomenon where the scroll bar only appears when the mouse is close, and it occludes most of it - this could be mostly resolved by having the position where the popup initially appears be slightly offset from the right of the window.

This is a Safari "feature". I'll investigate more at some stage.

[muzik]

Yet to check if this looks the same way on desktop, but on a tablet this looks a bit ridiculous:

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ POPUPWIDTH 480 POPUPHEIGHT 300 ]]

IMG_2139.jpeg (282.48 KiB) Viewed 2810 times

Everything appears twice the size it should, and entering any menu will result in many buttons intersecting.

I've wondered for a while what the point of #T is, given that it would always output the exact same string when used. Now that we have distinct Standard and Pro builds, could it display that detail as well - "LifeViewer Standard" for the current release version and "LifeViewer Pro" for the WASM version? (I also remember there being something that allowed you to substitute in the name of the program author, but it doesn't appear to be listed in Help > Scripts, so either it get removed or I'm making things up.)

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ TITLE "#T - build #B" ]]

Some previously reported issues from around September (every time I go back to page 169 the autoidentify example freezes the page for several seconds, which makes reproducing these annoying):

Code: Select all

# "Going to generation" message persists for empty patterns
x = 1, y = 1, rule = B/S0
!
[[ STARTFROM 1 ]]

Code: Select all

# Help > Info > Gridlines still displays "Major" and "Interval" for hexagonal and triangular grids
x = 7, y = 8, rule = B2/S34H
2bo$4bo$2bo3bo$2bo$3bo$o2bo$bo$3bo!

Code: Select all

# all hexagonal history cells outside of a bounding rhombus will stop being rendered after stepping forward one generation
x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM 4 STARTFROM 254 X 96 Y -96 THEME Catagolue ]]

Code: Select all

# zooming out will reveal more history cells that aren't initially shown
x = 1, y = 1, rule = B/SL
!
[[ PASTEMODE XOR AUTOSTART GPS 16 ZOOM 4
PASTET EVERY 4 0 PASTEDELTA 2 0 PASTE o! 0 0 PASTE o! 0 0
PASTET EVERY 4 1 PASTEDELTA 2 0 PASTE o! 0 1 PASTE o! 0 1
PASTET EVERY 4 2 PASTEDELTA 2 0 PASTE o! 1 1 PASTE o! 1 1
PASTET EVERY 4 3 PASTEDELTA 2 0 PASTE o! 1 0 PASTE o! 1 0
]]

Code: Select all

# cells modified by PASTE or KILLGLIDERS will defy HISTORYFIT
x = 125, y = 9, rule = B3/S23
b2o2bob2o$o2bo2b2o$bobo117bo2bo$2bo117bo$8bo111bo3bo$6b3o111b4o$5bo$6b
o$7b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT PASTEMODE XOR PASTET 400 PASTE o! -21 1 ]]

Code: Select all

# copying one cell and pasting it over the other will cause the cut cell to flicker during playback
x = 1, y = 6, rule = PCA_4
A5$B!

Code: Select all

# Help > Info > Identify displays strange values for off-deathforcer cells
x = 4, y = 4, rule = LifeHistory
3.F$.A$.2A$F!
[[ AUTOIDENTIFY ]]

Code: Select all

# CXRLE Pos has limits on the x axis, but not on the y axis
#CXRLE Pos=239,255
x = 1, y = 1, rule = B1357/S1357
o!
[[ MAXGRIDSIZE 9 ZOOM 4 X 255 Y 255 GRID ]]

Code: Select all

# this spaceship is impossible to Identify
x = 1, y = 1, rule = M0,4,1,0,1,0,0,0,8,0,0,0,0,0,0,0
o!
[[ AUTOIDENTIFY ]]

Code: Select all

# switch to Tbl or Map then press Play - some GUI elements will not be hidden
x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!
[[ AUTOIDENTIFY AUTOHIDEGUI ]]

Code: Select all

# in some cases the top and bottom edges of triangular grids are one cell too far to the left
x = 1, y = 1, rule = B1/SL:P8,6
!

Code: Select all

# KILLGLIDERS doesn't get these
x = 116, y = 90, rule = B3/S23
113b2o$113bobo$113bo5$80b2o$79b2o$81bo71$34bo$33b2o$33bobo5$2o$obo$o!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

Code: Select all

# ...or these
x = 116, y = 132, rule = B2i3-cky4e5c6n7c/S2-n3-ce4cy5jkr6ik
114b2o$113b2o$115bo41$67b2o$66b2o$68bo19$4bo$3b2o$3bobo63$b2o$2o$2bo!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

Code: Select all

# ...or these
x = 6, y = 7, rule = B3/S23
2o$obo$o2$3b2o$3bobo$3bo!
[[ KILLGLIDERS AUTOSTART AUTOFIT ]]

The thinner button on desktop also exacerbates this irritating phenomenon where the scroll bar only appears when the mouse is close, and it occludes most of it - this could be mostly resolved by having the position where the popup initially appears be slightly offset from the right of the window.

This is a Safari "feature". I'll investigate more at some stage.

Safari on touchscreen devices is also somewhat affected, but this screenshot is from a desktop instance of Waterfox (the scroll bar only appears when the cursor is near it, which then causes it to block the close button).

[rowett]

Yet to check if this looks the same way on desktop, but on a tablet this looks a bit ridiculous:

The Settings button should be disabled at that window height. Fixed in build 1334.

I've wondered for a while what the point of #T is, given that it would always output the exact same string when used. Now that we have distinct Standard and Pro builds, could it display that detail as well - "LifeViewer Standard" for the current release version and "LifeViewer Pro" for the WASM version?

Eventually the intention was that it would become a user setting (i.e. persistent across browser sessions). This is still on the backlog. For example, it might be helpful to always see the rule in the title bar when you open a pattern.

I've added #Z as a string substitution for the edition name (Standard or Pro) in build 1334.

• "Going to generation" message persists for empty patterns
• Help > Info > Gridlines still displays "Major" and "Interval" for hexagonal and triangular grids
• copying one cell and pasting it over the other will cause the cut cell to flicker during playback
• Help > Info > Identify displays strange values for off-deathforcer cells
• CXRLE Pos has limits on the x axis, but not on the y axis
• switch to Tbl or Map then press Play - some GUI elements will not be hidden

Fixed in build 1334.

[muzik]

Yet to check if this looks the same way on desktop

Just checked, and it does not. On desktop, the popup looks the way that it should:

itlooksfineondesktop.png (200.68 KiB) Viewed 2784 times

...whereas on a tablet screen, the tiny viewer is upscaled to take up this proportion of the screen:

butonanipadittakesuplikethewholepage.png (433.35 KiB) Viewed 2784 times

Desktop's "Scale", "Pixel Ratio" and "Window Zoom" are all 1.00, whereas for the tablet case they're respectively 1.88, 2.00 and 1.00 with this specific script command setup.

I don't know if AUTOHIDEGUI is also supposed to hide the graph or not:

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ AUTOSTART AUTOHIDEGUI GRAPH ]]

If you pause, open the help menu, then play again, the buttons will disappear, but not the darkened background or text lines.

On an unrelated note: I've been wondering if it'd make sense to merge the two hotkeys "Toggle Cell Type [?]" and "Toggle Icons [Alt I]"; icons are only supported on the square grid, whereas non-rectangular cell displays are only supported on the hexagonal and triangular grids, so there should never be a conflict. Both have the core functionality of changing how cells are displayed (if zoomed in enough) to communicate more intricate information about what each cell actually is.

[rowett]

I don't know if AUTOHIDEGUI is also supposed to hide the graph or not

Yes, by design.

If you pause, open the help menu, then play again, the buttons will disappear, but not the darkened background or text lines.

Again, by design.

[muzik]

There still appear to be some remnants of the GRIDMAJOR system for hexagonal and triangular grids - firstly, they're still listed in Help > Themes. Secondly, TRACKLOOP is still multiplied based on whatever the major grid interval would be if it was a square grid pattern. Note the T counter and how it differs for these patterns based on the specified theme:

Code: Select all

x = 4, y = 5, rule = B2o3m56/S2om4oH
2bo$3bo$o2bo$3bo$3bo!
[[ GRID THEME MCell AUTOSTART GPS 4 TRACKLOOP 4 1/2 0 ]]

Code: Select all

x = 4, y = 5, rule = B2o3m56/S2om4oH
2bo$3bo$o2bo$3bo$3bo!
[[ GRID THEME Margolus AUTOSTART GPS 4 TRACKLOOP 4 1/2 0 ]]

Code: Select all

x = 18, y = 24, rule = B39/S23L
$7bobobo$6b2obob2o$6b2o3b2o$8bobo$8bobo$6b2o3b2o$6b2obob2o$7bobobo$9b
o$5b4ob4o$5b2o5b2o3$5b2o5b2o$5b4ob4o$7bo3bo3$4bo9bo$3bob3o3b3obo$bo3b
3o3b3o3bo$b4o9b4o$b3o11b3o!
[[ GRID THEME MCell AUTOSTART GPS 30 ZOOM 4 TRACKLOOP 21 0 12/-21 ]]

Code: Select all

x = 18, y = 24, rule = B39/S23L
$7bobobo$6b2obob2o$6b2o3b2o$8bobo$8bobo$6b2o3b2o$6b2obob2o$7bobobo$9b
o$5b4ob4o$5b2o5b2o3$5b2o5b2o$5b4ob4o$7bo3bo3$4bo9bo$3bob3o3b3obo$bo3b
3o3b3o3bo$b4o9b4o$b3o11b3o!
[[ GRID THEME Margolus AUTOSTART GPS 30 ZOOM 4 TRACKLOOP 21 0 12/-21 ]]

I wonder if we should also display errors if we try to customize the major grid colour or interval for a hexagonal or triangular rule, since you're customizing something that isn't valid for the rule in question.

Code: Select all

x = 4, y = 4, rule = B2/S3H
o$bo$b3o$bo!
[[ COLOR GRIDMAJOR Blue ]]

Code: Select all

x = 4, y = 4, rule = B2/S3H
o$bo$b3o$bo!
[[ GRIDMAJOR 12 ]]

We already do this for cell states that don't apply to the rule or rulespace, so it seems like a natural extension of this:

Code: Select all

x = 4, y = 4, rule = B2/S3H
o$bo$b3o$bo!
[[ COLOR KILL Blue ]]

Code: Select all

x = 4, y = 4, rule = B2/S3H
o$bo$b3o$bo!
[[ COLOR BOUNDED Blue ]]

[muzik]

Use Select All on both of these and then attempt to nudge the contents of the selection. For the first, this works, as expected, but the action is blocked on the second despite there clearly being sufficient space.

Code: Select all

x = 8, y = 8, rule = B3/S23:P10
o6bo7$o6bo!

Code: Select all

x = 8, y = 8, rule = R1,C2,S2-3,B3:P10
o6bo7$o6bo!

Also, is it just me, or are polygons and such on hexagonal grids a bit distorted?

Fixed in build 1332.

For that specific case it's definitely fixed, but scaling things up appears to cause offsets to happen.

Code: Select all

x = 82, y = 82, rule = B/S0123HT
o81$o80bo!
[[ POLYSHADOW OFF COLOR POLY 255 0 0 POLYLINE 0 0 0 81 81 81 0 0 8 ZOOM 8 GRID POPUPWIDTH 800 POPUPHEIGHT 800 ]]

In this case the triangle looks just about regular, but each of the vertices appear to be shifted just barely under three cells to the right of what was specified in the script commands (e.g. (3,81) instead of (0,81)).

Side note: I assume the reason why no changes were made for the triangular grid is due to the centers differing from cell to cell as a result of orientation differences?

Finally: the full screen functionality on phones seems to be quite strange, probably due to the aspect ratio. In potrait mode the entire right half of the viewer is offscreen:

Screenshot_20251017-142229_Samsung Internet.jpg (121.09 KiB) Viewed 2747 times

In landscape mode, we get the top half, which means we can un-fullscreen the viewer, but the buttons on the bottom that you want to use are completely blocked off:

Screenshot_20251017-142314_Samsung Internet.jpg (102.68 KiB) Viewed 2747 times

[rowett]

There still appear to be some remnants of the GRIDMAJOR system for hexagonal and triangular grids - firstly, they're still listed in Help > Themes.

Fixed in build 1335.

TRACKLOOP is still multiplied based on whatever the major grid interval would be if it was a square grid pattern.

Fixed in build 1335.

Use Select All on both of these and then attempt to nudge the contents of the selection. For the first, this works, as expected, but the action is blocked on the second despite there clearly being sufficient space.

Fixed in build 1335.

For that specific case it's definitely fixed, but scaling things up

Fixed in build 1335.

[muzik]

Regarding the fullscreen functionality and small popup sizes:

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!
[[ POPUPWIDTH 480 POPUPHEIGHT 300 ]]

Since the popup is initially not of sufficient size to accommodate the contents of the Settings menu, the settings button is disabled. If we fullscreen, it then becomes usable. If we enter the settings menu and then un-fullscreen the popup, we remain in the settings menu, with all the widgets intersecting:

IMG_2156.jpeg (541.37 KiB) Viewed 2723 times

What I think should be done is that exiting fullscreen mode should eject the user from the settings menu if it's open and there's not enough room (this would be much more preferable to disabling the settings button in fullscreen mode if the initial popup size isn't big enough).

On a related note: the button layout in the Help menu will use the "height lower than 480" layout, even if you fullscreen the popup, which would logically increase the height beyond 480. I think the help menu should react accordingly and change the button layout if it detects a change in size such as this.

IMG_2155.jpeg (275.41 KiB) Viewed 2723 times

In this post, checking the error in the first two patterns will reveal the length of the rulestring to be both 85 and 87. I don't know exactly what causes this, and attempting to copy these into this thread as a test case will not produce the same effect. What causes this to happen?

[muzik]

A compilation of some other reports from around September, alongside some from earlier in the year:

Code: Select all

# some signed 32-bit values overflow, even though others are correctly handled
x = 3, y = 3, rule = B3/S23
o$o$3o!
[[ STARTFROM 5000000000 HISTORYSTATES 5000000000 ]]

Code: Select all

# in range-1 rules bounded grid sizes 16353 to 16379 do not display SHOW PATTERN ERROR despite being invalid
x = 3, y = 3, rule = B3/S23:P16379
o$obo$2o!
[[ MAXGRIDSIZE 14 ]]

Code: Select all

# pressing Step Back will cause a history cell at (-1,0) to be removed
x = 2, y = 2, rule = B/S
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE o! 63 0 STARTFROM 72 X 0 ]]

Code: Select all

# you cannot draw here until you click near the very left and drag it rightward
x = 2, y = 16, rule = B3/S23:T0,32
2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o$2o!
[[ GRID ZOOM 16 X 272 ]]

Code: Select all

# zooming out further than 16.0x will cause transparent areas in icons to become black
x = 3, y = 3, rule = IconDemo3
3A$3A$3A!
[[ ICONS ]]
@RULE IconDemo3
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 96 96 96
1 255 0 0
2 255 0 0
@ICONS
XPM
"7 14 4 1"
"A c #FF0000"
"B c #FF00FF"
"G c #000100"
". c #000000"
"AA.A.AA"
"AA.A.AA"
"..AAA.."
"AAA.AAA"
"..AAA.."
"AA.A.AA"
"AA.A.AA"
"GGGGBBB"
"GGGGBBB"
"GGGGBBB"
"GGGGBBB"
"BBBBGGG"
"BBBBGGG"
"BBBBGGG"

Code: Select all

# no error is produced here, despite "COLOR dead" not being valid for [R]Super even if it is valid for other rules
x = 5, y = 4, rule = B3/S23Super
.A2.A$A$A3.A$4A!
[[ COLOR dead 255 255 255 ]]

Code: Select all

# pausing this will zoom in on alive cells, disregarding HISTORYFIT
x = 4, y = 3, rule = B367/S2-i34q
3o$2obo$b2o!
[[ AUTOSTART AUTOFIT HISTORYFIT ]]

Code: Select all

# oblique spaceships can have a mod identified as lower than their period, which should never be possible
x = 6, y = 6, rule = R3,C2,S5-7,B5-7,NW0000000002020200000000020102000000000202020000000
6o$6o$2o$2o$2b2o$2b2o!
[[ AUTOIDENTIFY ]]

Code: Select all

# set "Refresh Rate" to 144 and this will get jittery (you do not need a 144hz monitor to see this effect)
x = 1, y = 1, rule = B3/S23
b!
[[ PASTEDELTA 1 1 PASTET EVERY 1 PASTE bo$2o! 0 0 TRACK 1 1 ]]

Code: Select all

# Step Back can retroactively modify Graph contents
x = 1, y = 1, rule = B3/S23
b!
[[ PASTET EVERY 1 PASTE o! 0 0 STARTFROM 128 GRAPH ]]

Code: Select all

# changing Theme in-viewer will not change TRACKLOOP's duration and the major grid lines will visibly jump
x = 6, y = 6, rule = MAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////////////////////////////////////w
o$bo3bo$2bo2bo$3bobo$4bo$b3o!
[[ TRACKLOOP 3 1 1 GRID THEME Margolus AUTOSTART GPS 2 ]]

[muzik]

When Pro finally releases, will we be able to access it using showinviewer.lua, or will it be restricted to the standard engine?

This is minor, but there appears to be an = instead of a - in build 1334's changelog entry. (Also, the header has been missing for the last several versions. Was it removed on purpose?)

[muzik]

Having some trouble with labels and tracking. In this pattern, I specify LABELTRACK, but the label remains in place:

Code: Select all

x = 31, y = 8, rule = B3/S23
5b3o15b3o$4bo3bo13bo3bo$3b2o4bo11bo4b2o$2bobob2ob2o3b3o3b2ob2obobo$b2o
bo4bob2ob3ob2obo4bob2o$o4bo3bo4bobo4bo3bo4bo$12bo5bo$2o7b2o9b2o7b2o!
[[ LABEL 15 -6 8 "64P2H1V0\nDean R. Hickerson\n1989" LABELTRACK 0 -1/2 ]]

In this, I specify both TRACK and LABELTRACK, and the label does move (as does the camera).

Code: Select all

x = 31, y = 8, rule = B3/S23
5b3o15b3o$4bo3bo13bo3bo$3b2o4bo11bo4b2o$2bobob2ob2o3b3o3b2ob2obobo$b2o
bo4bob2ob3ob2obo4bob2o$o4bo3bo4bobo4bo3bo4bo$12bo5bo$2o7b2o9b2o7b2o!
[[ TRACK 0 -1/2 LABEL 15 -6 8 "64P2H1V0\nDean R. Hickerson\n1989" LABELTRACK 0 -1/2 ]]

I don't know if I'm just defining commands in the wrong order or something, or maybe even using the wrong command outright, but surely it's meant to be possible to define movement for labels without dictating that the camera should also move (so you can have, for example, multiple labels moving at different speeds, perhaps to annotate a collection of multiple spaceships)?

For the record, simply specifying a track command that does nothing doesn't change things:

Code: Select all

x = 31, y = 8, rule = B3/S23
5b3o15b3o$4bo3bo13bo3bo$3b2o4bo11bo4b2o$2bobob2ob2o3b3o3b2ob2obobo$b2o
bo4bob2ob3ob2obo4bob2o$o4bo3bo4bobo4bo3bo4bo$12bo5bo$2o7b2o9b2o7b2o!
[[ TRACK 0 0 LABEL 15 -6 8 "64P2H1V0\nDean R. Hickerson\n1989" LABELTRACK 0 -1/2 ]]

And if we change TRACK to move across the other axis, the label goes in that direction as well, instead of the direction defined by LABELTRACK:

Code: Select all

x = 31, y = 8, rule = B3/S23
5b3o15b3o$4bo3bo13bo3bo$3b2o4bo11bo4b2o$2bobob2ob2o3b3o3b2ob2obobo$b2o
bo4bob2ob3ob2obo4bob2o$o4bo3bo4bobo4bo3bo4bo$12bo5bo$2o7b2o9b2o7b2o!
[[ TRACK -1/2 0 LABEL 15 -6 8 "64P2H1V0\nDean R. Hickerson\n1989" LABELTRACK 0 -1/2 ]]

[rowett]

Having some trouble with labels and tracking. In this pattern, I specify LABELTRACK, but the label remains in place

You need to specify LABELTRACK before the LABEL you want it to apply to. This is true for most script commands. Define the attributes first and then define the item.

[rowett]

When Pro finally releases, will we be able to access it using showinviewer.lua, or will it be restricted to the standard engine?

Yes it will use Pro.

[muzik]

You need to specify LABELTRACK before the LABEL you want it to apply to. This is true for most script commands. Define the attributes first and then define the item.

Cheers for the clarification. Finished pattern is here. (I wonder if it'd be better to throw an error for unused annotation colour, tracking, etc. commands rather than silently ignoring them to better indicate that the order is incorrect and enforce valid script syntax?)

When moving the cursor fast while drawing, LifeViewer will interpolate so that you get a continuous curve of cells rather than a bunch of isolated dots. However, this system appears to assume that the square grid is in use at all times, which can cause detached cells when scribbling fast on a hexagonal grid (specifically on the top right-bottom left diagonal; those two cells are in the Moore neighbourhood but not correctly excluded from the hexagonal neighbourhood in this case). For the triangular neighbourhood, we also see biases towards orthogonally adjacent cells in the left-right direction but not the other two orthogonal directions. Here are some example scribbles exhibiting detached hexagonal cells and prominently horizontally-adjacent triangular cells but little adjacency in the other two directions:

IMG_2147.jpeg (1.11 MiB) Viewed 2588 times

IMG_2148.jpeg (898.31 KiB) Viewed 2588 times

IMG_2149.jpeg (982.62 KiB) Viewed 2588 times

And some example blank canvases for testing this:

Code: Select all

x = 1, y = 1, rule = B/S01234V
!
[[ GRID ZOOM 4 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123HT
!
[[ GRID ZOOM 4 ]]

Code: Select all

x = 1, y = 1, rule = B/S0123LE
!
[[ GRID ZOOM 4 ]]

Use Select All on both of these and then attempt to nudge the contents of the selection. For the first, this works, as expected, but the action is blocked on the second despite there clearly being sufficient space.

Fixed in build 1335.

The edges of unbounded grids are still affected by this issue. Select All, then try to nudge left or down. You can draw in those spaces just fine, so it'd be expected that selections can be moved into this position as well, but that is not possible.

Code: Select all

x = 1, y = 1, rule = B3/S23
b!
[[ GRID MAXGRIDSIZE 9 X -256 Y 256 PASTE o3bo4$o3bo! -255 250 ]]

Despite the in-viewer close button as well as the "exit error screen" button now using the multiplication symbol instead of the letter X, the "close graph" and "close Identify output" buttons still use the old letter. This is inconsistent. Is this unintended?

Code: Select all

x = 4, y = 4, rule = B2ek3ajnq4aijkqrw5aeijq6-e/S02eik3ajkqr4-ceknt5-akr6eik
obo$3bo$2b2o$3bo!
[[ AUTOIDENTIFY GRAPH ]]

Code: Select all

x = 4, y = 4, rule = B2ek3ajnq4aijkqrw5aeijq6-e/S02eik3ajkqr4-ceknt5-akr6eik
obo$3bo$2b2o$3bo!
[[ PLEASEDISPLAYANERROR ]]

There are still some problems with annotations on hexagonal grids. In this example, the red line is ever so slightly offset to the left from the edge that it should be covering up. The green and blue lines, for some reason, start and end at the centers of edges, rather than the centers of cells. All three of these polylines specify 2 4, so you'd expect them to meet at the very center of that cell, but clearly this does not happen.

Code: Select all

x = 7, y = 7, rule = B/S0123HT
o4$2bo2$o5bo!
[[ GRID ZOOM 64 COLOR GRID Teal COLOR ALIVE White POLYSHADOW OFF COLOR POLY Red POLYLINE 0 0 2 4 0 0 64 COLOR POLY Green POLYLINE 0 6 2 4 0 6 64 COLOR POLY Blue POLYLINE 6 6 2 4 6 6 64 ]]

A square-grid analogue of this setup, which looks exactly as it should:

Code: Select all

x = 7, y = 7, rule = B/S01234V
o5bo3$3bo3$o5bo!
[[ GRID ZOOM 64 COLOR ALIVE White POLYSHADOW OFF COLOR POLY Red POLYLINE 0 0 3 3 0 0 64 COLOR POLY Green POLYLINE 0 6 3 3 0 6 64 COLOR POLY Blue POLYLINE 6 6 3 3 6 6 64 COLOR POLY Yellow POLYLINE 6 0 3 3 6 0 64 ]]

[b-engine]

I'm trying to embed LifeViewer in Turbowarp, but apparently lazyslug.com doesn't allow embedding in iframe:

Screenshot from 2025-10-22 19-46-12.png (36.67 KiB) Viewed 2565 times

Is there any alternatives of embedding LV without downloading the plugin (which can't been used in Turbowarp)?

[rowett]

I'm trying to embed LifeViewer in Turbowarp, but apparently lazyslug.com doesn't allow embedding in iframe
Is there any alternatives of embedding LV without downloading the plugin (which can't been used in Turbowarp)?

I've never used Turbowarp. It appears to be a scratch to JS compiler. It mentions Javascript extensions to perhaps that's a way to embed. I don't really have the bandwidth to look into it.

[b-engine]

I've never used Turbowarp. It appears to be a scratch to JS compiler. It mentions Javascript extensions to perhaps that's a way to embed. I don't really have the bandwidth to look into it.

Basically Turbowarp is faster Scratch with more extensions.
I know about the custom JS extensions, but I couldn't get LifeViewer to work; an embed link would be much easier to implement, both for the LV and many other sites that wants to embed it.

[rowett]

Basically Turbowarp is faster Scratch with more extensions.
I know about the custom JS extensions, but I couldn't get LifeViewer to work; an embed link would be much easier to implement, both for the LV and many other sites that wants to embed it.

Perhaps you could host LifeViewer locally or on your own domain. lazyslug.com will not permit embedding in an iFrame (it's a security risk).

See here for instructions in creating your own webpage with LifeViewer.