Pattern viewer for forum threads

[rowett]

Additionally, if I type Alt+R -> Alt+Left, it automatically leaves the page without prompting me. This could result in data loss.

I've just figured out what you meant. I'm working on a solution...

[muzik]

Another LifeViewer Pro exclusive issue: Generations rules with large amounts of states start to behave wrongly. This only appears to affect the range-1 algorithm (and may be related to the "some cells don't fade" issue from build 1323).

This works fine:

Code: Select all

x = 2, y = 4, rule = /2/66
A$.A$.A$A!

Starting from here, two permanent state 2 cells remain near the origin:

Code: Select all

x = 2, y = 4, rule = /2/67
A$.A$.A$A!

Starting from here, the pattern will spontaneously die at generation 257:

Code: Select all

x = 2, y = 4, rule = /2/80
A$.A$.A$A!

Starting from here, we start to see "bands" of colour left behind in the spaceship trail, where aged dying cells revert to fresher dying cells as you continue left:

Code: Select all

x = 2, y = 4, rule = /2/83
A$.A$.A$A!

When zoomed out beyond 1.0, the movement of the front end of these spaceships looks quite strange and bouncy as the number of states increases. None of these effects appear to happen in LifeViewer Standard.

Back to Standard bugs: there's still a GRIDMAJOR remnant in the hex/tri grids, since trying to customize it with a command will create a custom theme even though for these grids it does not exist.

Code: Select all

x = 5, y = 5, rule = B/S0123HT
obo2$o3bo2$2bobo!
[[ GRID COLOR GRIDMAJOR Blue ]]

Code: Select all

x = 12, y = 6, rule = B/S0123LE
bo9bo5$6bo!
[[ GRID COLOR GRIDMAJOR Blue ]]

Code: Select all

x = 5, y = 5, rule = B/S0123HT
obo2$o3bo2$2bobo!
[[ GRID GRIDMAJOR 32 ]]

Code: Select all

x = 12, y = 6, rule = B/S0123LE
bo9bo5$6bo!
[[ GRID GRIDMAJOR 32 ]]

For these, despite COLOR DEAD/DEADRAMP/ALIVERAMP not doing anything to these patterns due to those states not existing, there is no error produced when trying to customize them. In addition, they create a custom theme, which again should not happen as no actual color change has taken place.

Code: Select all

x = 2, y = 2, rule = /2/255
AB$AB!
[[ STARTFROM 256 COLOR DEAD Blue ]]

Code: Select all

x = 2, y = 2, rule = /2/256
AB$AB!
[[ STARTFROM 256 COLOR DEAD Blue COLOR DEADRAMP Green ]]

Code: Select all

x = 2, y = 4, rule = B2/S
bo$o$o$bo!
[[ STARTFROM 5 HISTORYSTATES 1 COLOR DEAD Green ]]

Code: Select all

x = 2, y = 4, rule = B2/S
bo$o$o$bo!
[[ STARTFROM 5 HISTORYSTATES 0 COLOR DEAD Green COLOR DEADRAMP Red ]]

Code: Select all

x = 1, y = 3, rule = B3/S23
o$o$o!
[[ STARTFROM 5 AGESTATES 0 COLOR ALIVERAMP Green ]]

Here's a better test case for a previously reported bug (for me this only works on desktop): open the first viewer and the top bar will look fine. If you open the second viewer, close it, then open the first one again, the top bar will shrink, making the buttons harder to use and the popup harder to move. This effect, from my testing, cannot be reverted without refreshing the page.

Code: Select all

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

Code: Select all

x = 1, y = 1, rule = B/S0123HT
!
[[ POPUPWIDTH 4096 ]]

Further testing on a previously reported bug: it turns that Step Back doesn't just remove a single cell, but instead blanks an entire row or column:

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ PASTEDELTA 0 -1 PASTET EVERY 1 PASTE 512o! -256 255 STARTFROM 288 Y 0 MAXGRIDSIZE 9 ZOOM 1 ]]

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ PASTEDELTA -1 0 PASTET EVERY 1 PASTE 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$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$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$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$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$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$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$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$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$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$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! 255 -256 STARTFROM 288 X 0 MAXGRIDSIZE 9 ZOOM 1 ]]

This test case for drawn cell connectedness may be clearer: try drawing a straight line as fast as you can within the bounds of the green lines and within the bounds of the red lines. Green lines indicate that the resulting line is connected (as it should be), whereas red lines indicate where gaps will occur.

Code: Select all

x = 37, y = 37, rule = B/S0123HT
9bb9$b26bb9$18bo9$9bb26bb9$27bb!
[[ GRID ZOOM 24 POLYSHADOW OFF COLOR POLY Red POLYLINE 26 7 7 26 32 POLYLINE 29 10 10 29 32 COLOR POLY Green POLYLINE 7 -1 26 37 32 POLYLINE 10 -1 29 37 32 POLYLINE -1 10 37 29 32 POLYLINE -1 7 37 26 32 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Code: Select all

x = 37, y = 19, rule = B/S0123LE
9bb17bb9$b17bo17bb9$9bb17bb!
[[ GRID ZOOM 24 POLYSHADOW OFF COLOR POLY Green POLYLINE -4 8.5 40 8.5 32 POLYLINE -4 11.5 40 11.5 32 COLOR POLY Red POLYLINE 27/6 0 159/6 22 32 POLYLINE 9 -1.5 93/3 20.5 32 POLYLINE 27 -1.5 5 20.5 32 POLYLINE 189/6 0 11 20.5 32 THUMBNAIL THUMBSIZE 4 WIDTH 600 HEIGHT 600 ]]

Is there a bias toward higher state numbers when zoomed out beyond one cell per pixel? State 2's colour dominates in both of these, despite the cell roles being swapped entirely in both of the following examples (otherwise behaviourally equivalent):

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_hexagonal
A!
[[ AUTOFIT STARTFROM 728 ]]

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_hexagonal
B!
[[ AUTOFIT STARTFROM 728 ]]

[muzik]

Another LifeViewer Pro exclusive issue: Generations rules with large amounts of states start to behave wrongly. This only appears to affect the range-1 algorithm

Upon further investigation this is wrong. Both of the following behave incorrectly in LifeViewer Pro, but in different ways. This explodes chaotically:

Code: Select all

x = 1, y = 1, rule = /1/83H
A!
[[ ZOOM -2 AUTOSTART ]]

By contrast, this initially evolves correctly but then loses symmetry:

Code: Select all

x = 1, y = 1, rule = R1,C83,S,B1,NH
A!
[[ ZOOM -2 AUTOSTART ]]

Also compare:

Code: Select all

x = 1, y = 1, rule = R1,C83,S,B1,N@dbH
A!
[[ ZOOM -2 AUTOSTART ]]

Code: Select all

x = 1, y = 1, rule = R1,C83,S,B1,NW110101011H
A!
[[ ZOOM -2 AUTOSTART ]]

Anomalous behaviour first appears to manifest from 66 states rather than 67, from what I've seen:

Code: Select all

x = 1, y = 1, rule = /1/66H
A!
[[ STARTFROM 16 ZOOM 8 ]]

Code: Select all

x = 1, y = 1, rule = R1,C66,S,B1,NH
A!
[[ STARTFROM 16 ZOOM 8 ]]

All four behave the same (and correctly) in LifeViewer Standard.

For some reason, despite specifying b at the end, no time statistics are displayed for the first pattern:

Code: Select all

x = 1, y = 1, rule = B/S0
!
[[ STARTFROM 1000000b ]]

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ STARTFROM 1000000b ]]

For objects that are identified very fast: could Help > Info > Identify display more precision for time elapsed? 0.0s to 0.9s isn't a lot since there are many small objects that run to completion almost immediately to the point where it's hard to get a grip on exactly how long they take (these are unreasonably simple examples, but even some higher-period, low-bounding box items are done in less than a second):

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S0,B
o!
[[ AUTOIDENTIFY ]]

Speaking of more precision and granularity, if the zoom level is further in than -10.0x, but further out than 10.0x, could two digits be displayed after the decimal point rather than just one?

[rowett]

Additionally, if I type Alt+R -> Alt+Left, it automatically leaves the page without prompting me. This could result in data loss.

This should be fixed in build 1344.

The issue was when a browser has a modal dialog up and you try to navigate away from the page (for example Alt+Left to go to previous page) then the web page doesn't get notified so can't put up a prompt to check whether this is OK.

[rowett]

Another LifeViewer Pro exclusive issue: Generations rules with large amounts of states start to behave wrongly.

Fixed in build 1344.

Is there a bias toward higher state numbers when zoomed out beyond one cell per pixel?

Depends on the rule but for RuleLoader rules yes.

For some reason, despite specifying b at the end, no time statistics are displayed for the first pattern:

It's because it has no live cells.

[muzik]

Here's a performance stress test for Pro:

Code: Select all

# large flashing region moved off-screen because that would be unpleasant to view close up
x = 1, y = 1, rule = R500,C2,S,B0,NM
o!
[[ Y 1024 AUTOSTART SHOWTIMING EXTENDEDTIMING ]]

WASM Engine off:

wasmoff144.png (17.31 KiB) Viewed 4213 times

WASM Engine on:

wasmon144.png (17.72 KiB) Viewed 4213 times

In this pattern, if we manually delete the cells at (1,5), (3,5), (21,5) and (23,5), and then Identify the pattern, it will run for over three thousand more generations before detecting the rather low period of the spaceships:

Code: Select all

x = 64, y = 9, rule = B3/S23Super
42.A.A$2.A39.2A$.A33.3A5.A11.3O3.3O$.3A31.A2.A16.O2.O.O2.O$22.2O11.A6.
2A11.O7.O$.A19.O.O11.A3.A.A.A11.O7.O$.2A19.O12.A6.A2.3A7.O7.O$A.A33.A
.A6.A10.O.O.O.O$46.A!
[[ STARTFROM 4096 ]]

In the following pattern, we do not get this effect, and the spaceship is identified much faster:

Code: Select all

x = 64, y = 9, rule = B3/S23Super
42.A.A$2.A39.2A$.A33.3A5.A11.3O3.3O$.3A31.A2.A16.O2.O.O2.O$22.2O11.A6.
2A11.O7.O$.A19.O.O11.A3.A.A.A11.O7.O$.2A19.O12.A6.A2.3A7.O7.O$A.A33.A
.A6.A10.O.O.O.O$46.A!
[[ STARTFROM 4000 ]]

If a rule table includes B0 of some sort, would it be possible to disable the "Life ended at" message and auto-pausing, since nontrivial evolution can happen after this point without the need for editing, pasting and such?

Code: Select all

x = 1, y = 1, rule = horriblestrobe:P16,16
!
[[ AUTOSTART COLOR 1 64 64 64 ]]
@RULE horriblestrobe
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
var a={0,1}
var b=a
var c=a
var d=a
var e=a
var f=a
var g=a
var h=a
0,a,b,c,d,e,f,g,h,1
1,a,b,c,d,e,f,g,h,0

I've also wondered if it'd be possible to implement certain values and statistics as accessible via # substitution.

Yes. Please suggest some items and their #letter.

For cases like this where a warning is needed it may be useful to display a value that displays how many seconds are remaining on the current PAUSE command before playback resumes. Perhaps #K for "Kountdown"?

Code: Select all

x = 1, y = 1, rule = R500,C2,S,B0
o!
[[ ZOOM -8 PAUSE 3 "Epilepsy warning!" AUTOSTART SHOWTIMING EXTENDEDTIMING ]]

Planning on testing other aspects of Pro soon (e.g. hexagonal rule tables) once I can find a good setup.

[muzik]

When turning TRACK on and off are annotations supposed to snap back to their initial position?

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ COLOR POLY Red TRACK -1/4 1/4 POLYFILL 1 -0.5 2 -0.5 2 0.5 1 0.5 1 -0.5 32 STARTFROM 20 ]]

[rowett]

When turning TRACK on and off are annotations supposed to snap back to their initial position?

Yes, see example below.

Code: Select all

x = 9, y = 5, rule = B3/S23
$bo3b3o$b3o2bo$2bo!
#C TRACK on (reset pattern once and run again to see with TRACK OFF)
#C [[ TRACK 0.1 0.02 GRID ZOOM 4 ]]

#C Tracks slower than TRACK speed
#C [[ LABELTRACK 0.05 0.01 LABEL 4 -4 4 FIXED "Tracking Slow" ]]

#C Tracks at the same speed as TRACK speed so will appear static if TRACK is ON
#C [[ LABELTRACK 0.1 0.02 LABEL 4 0 4 FIXED "Tracking Normal" ]]

#C Tracks faster than TRACK speed
#C [[ LABELTRACK 0.15 0.03 LABEL 4 4 4 FIXED "Tracking Fast" ]]

#C Turn LABELTRACK OFF (set it to FIXED)
#C [[ LABELTRACK FIXED ]]

#C Standard label will be relative to TRACK if ON
#C [[ LABEL 4 8 4 "Normal" ]]

#C Fixed position label doesn't move if TRACK is ON
#C [[ LABEL 4 12 4 FIXED "Fixed" ]]

#C Track three gliders from when they are formed
#C [[ COLOR LABEL Yellow ]]

#C Track first NW glider until T=10000
#C [[ LABELT 144 10000 10 LABELTRACK -0.25 -0.25 LABEL -0.5 -12 4 FIXED "Glider" ]]

#C Track second NW glider for its' short lifespan
#C [[ LABELT 216 265 10 LABEL 10 26 4 FIXED "Transient\nGlider" ]]

#C Track NE glider for 200 generations
#C [[ LABELT 268 468 10 LABELTRACK 0.25 -0.25 LABEL 29.5 32 4 FIXED "Another\nGlider" ]]

[muzik]

When turning TRACK on and off are annotations supposed to snap back to their initial position?

Yes, see example below.

Interesting, I've tried recreating the "Normal" versus "Tracking Normal" example on the hexagonal grid, and the labels diverge. In addition, if we turn tracking off, both of the labels will change position rather than only the one without LABELTRACK, and the other one will move in a different trajectory. Is this the correct behaviour, or not?

Code: Select all

x = 5, y = 5, rule = B2/S2H
obobo2$3bo$3b2o$4bo!
[[ AUTOSTART GRID GPS 2 TRACK 0 2/3 LABELTRACK 1/3 0 LABEL 0.5 -3 32 "has labeltrack" LABELTRACK FIXED LABEL 5 6 32 "no labeltrack" ]]

EDIT: the second effect seems to affect the square grid as well:

Code: Select all

x = 3, y = 2, rule = B2ac3ae/S1c2i3i
3o$bo!
[[ AUTOSTART GRID ZOOM 16 GPS 2 TRACK 0 2/3 LABELTRACK 1/3 0 LABEL 0.5 -3 16 "turn off track" ]]

[rowett]

the second effect seems to affect the square grid as well:

Ignoring the hex grid for now...

On the square grid this is correct. The [[ TRACK ]] command controls the camera overall. The [[ LABELTRACK ]] command controls the movement of the labels it is defined for.

You can define labels in three ways:

1. Standard label, moves with the camera if TRACK is ON using the current [[ TRACK ]] settings: [[ LABEL 0 0 8 "Standard" ]], is static if TRACK is OFF.
2. Fixed label, ignores the [[ TRACK ]] definition entirely regardless if TRACK is ON or OFF: [[ LABEL 0 0 8 FIXED "Fixed" ]]
3. Moving label, moves based on the previous [[ LABELTRACK ]] definition. Use [[ LABELTRACK FIXED ]] to remove tracking for subsequent labels.

[rowett]

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:

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.

Fixed in build 1347.

[muzik]

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:

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.

Fixed in build 1347.

Fix confirmed, though I have noticed that the buttons all appear intersecting for about a frame before the menu closes in this case. I don't know if this is possible to fix or worth it if it is.

IMG_2538.jpeg (857.9 KiB) Viewed 4106 times

On a related note: the help shortcut buttons also don't update with respect to a size change. If you have the popup in full screen, open a help topic then go back to the small window mode, the contents will go under the buttons and off the screen:

IMG_2539.jpeg (929.58 KiB) Viewed 4106 times

Conversely, opening help in a smaller window will truncate the list far too early for the amount of space available:

IMG_2540.jpeg (655.73 KiB) Viewed 4106 times

On my ipad (but not on PC) that specific popup (POPUPWIDTH 480 POPUPHEIGHT 300) still appears at twice the size it probably should, with the top bar remaining so even in full screen), but I don't know if that's fixable either. The scale is listed as 1.88, pixel ratio as 2.00 and window zoom as 1.00 (compared to a normal popup where the scale is around 1.11 or 1.21).

[muzik]

Another thing to note. On a 1920x1080 monitor, the following popup looks just about fine:

Code: Select all

x = 29, y = 19, rule = B/S0123HT
4o$b3o$2b2o$3bo2$3b3o$4b2o$5bo3$6b2o$7bo$25bo$18bo5b2o$13bo3b2o4b4o$9b
o2b2o2b4o2b5o$14bo3b2o4b4o$20bo5b2o$28bo!
[[ POPUPWIDTH 1920 ]]

However, for this, the buttons appear very much shrunk, and many display an ellipsis as though text cannot fit inside of them:

Code: Select all

x = 29, y = 19, rule = B/S0123HT
4o$b3o$2b2o$3bo2$3b3o$4b2o$5bo3$6b2o$7bo$25bo$18bo5b2o$13bo3b2o4b4o$9b
o2b2o2b4o2b5o$14bo3b2o4b4o$20bo5b2o$28bo!
[[ POPUPWIDTH 3840 ]]

A comparison in case this looks different on other displays:

popup1920.png (29.96 KiB) Viewed 4098 times

popup3840.png (16.33 KiB) Viewed 4098 times

As mentioned earlier, opening the second will make the first's top bar much thinner until a page refresh occurs.

I don't know if width and height parameters can be capped at the current display window size to minimize effects like this, rather than trying to shrink a very large popup down in an attempt to make it usable, since small unreadable buttons are difficult to work width (though there's probably still a use case for large width and height parameters such as these for 4K and 8K displays).

Another thing to note with respect to popup width and height commands: contents of the main results page will end up going behind buttons and off the screen if the height is low enough. Compare the period/frequency tables, which do not do this, and fit on the screen while making use of the scroll bar. It may be a good idea to enable scrolling for the results table as well since this could help accommodate for potential future additions (e.g. minrule/maxrule, apgcode) if they happen, and the other two screens work well enough anyway at these dimensions:

Code: Select all

x = 44, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
44o!
[[ POPUPWIDTH 480 POPUPHEIGHT 300 AUTOIDENTIFY ]]

Side note: this may be dependent on display as well, but the table of periods/frequencies sometimes has an extra empty element at the bottom for some height value ranges:

Code: Select all

x = 1, y = 25, 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!
[[ POPUPWIDTH 480 POPUPHEIGHT 290 AUTOIDENTIFY THEME Inverse ]]

Code: Select all

x = 1, y = 25, 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!
[[ POPUPWIDTH 480 POPUPHEIGHT 291 AUTOIDENTIFY THEME Inverse ]]

Code: Select all

x = 1, y = 25, 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!
[[ POPUPWIDTH 480 POPUPHEIGHT 302 AUTOIDENTIFY THEME Inverse ]]

Code: Select all

x = 1, y = 25, 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!
[[ POPUPWIDTH 480 POPUPHEIGHT 303 AUTOIDENTIFY THEME Inverse ]]

[muzik]

Code: Select all

x = 9, y = 5, rule = B3/S23
$bo3b3o$b3o2bo$2bo!
#C TRACK on (reset pattern once and run again to see with TRACK OFF)
#C [[ TRACK 0.1 0.02 GRID ZOOM 4 ]]

#C Tracks slower than TRACK speed
#C [[ LABELTRACK 0.05 0.01 LABEL 4 -4 4 FIXED "Tracking Slow" ]]

#C Tracks at the same speed as TRACK speed so will appear static if TRACK is ON
#C [[ LABELTRACK 0.1 0.02 LABEL 4 0 4 FIXED "Tracking Normal" ]]

#C Tracks faster than TRACK speed
#C [[ LABELTRACK 0.15 0.03 LABEL 4 4 4 FIXED "Tracking Fast" ]]

#C Turn LABELTRACK OFF (set it to FIXED)
#C [[ LABELTRACK FIXED ]]

#C Standard label will be relative to TRACK if ON
#C [[ LABEL 4 8 4 "Normal" ]]

#C Fixed position label doesn't move if TRACK is ON
#C [[ LABEL 4 12 4 FIXED "Fixed" ]]

#C Track three gliders from when they are formed
#C [[ COLOR LABEL Yellow ]]

#C Track first NW glider until T=10000
#C [[ LABELT 144 10000 10 LABELTRACK -0.25 -0.25 LABEL -0.5 -12 4 FIXED "Glider" ]]

#C Track second NW glider for its' short lifespan
#C [[ LABELT 216 265 10 LABEL 10 26 4 FIXED "Transient\nGlider" ]]

#C Track NE glider for 200 generations
#C [[ LABELT 268 468 10 LABELTRACK 0.25 -0.25 LABEL 29.5 32 4 FIXED "Another\nGlider" ]]

This pattern has several comments, but for some reason they don't appear in the dedicated "Comments" section in the Help menu.

[rowett]

This pattern has several comments, but for some reason they don't appear in the dedicated "Comments" section in the Help menu.

Because the Comments section ignores comments after the RLE.

[rowett]

the help shortcut buttons also don't update with respect to a size change

Fixed in build 1348.

However, for this, the buttons appear very much shrunk, and many display an ellipsis as though text cannot fit inside of them

I'm not going to change this. The pop up size rarely gets specified.

Side note: this may be dependent on display as well, but the table of periods/frequencies sometimes has an extra empty element at the bottom for some height value ranges

Fixed in build 1348.

[muzik]

Side note: this may be dependent on display as well, but the table of periods/frequencies sometimes has an extra empty element at the bottom for some height value ranges

Fixed in build 1348.

This still appears to happen:

height290.png (64.67 KiB) Viewed 4043 times

height291.png (64.56 KiB) Viewed 4043 times

The buttons also go under the settings button and off the bottom of the screen on the right, but there's probably enough space above to move them up - is this possible for smaller viewer heights? Since the settings button is unusable at these height ranges it may be a good ides to hide it specifically when Identify results are displayed as well.

[rowett]

This still appears to happen:

Fixed in build 1349.

[muzik]

This may also be a display-dependent bug, but some grid boundaries may be invisible at specific zoom levels:

Code: Select all

# top is invisible
x = 1, y = 1, rule = Fredkin_mod3_hexagonal:P2187
A!
[[ ZOOM -3.71 STARTFROM 1093 ]]

Code: Select all

# bottom is invisible
x = 1, y = 1, rule = Fredkin_mod3_hexagonal:P2187
A!
[[ ZOOM -3.75 STARTFROM 1093 ]]

Code: Select all

# bottom is invisible
x = 1, y = 1, rule = Fredkin_mod3_hexagonal:P2187
A!
[[ ZOOM -3.78 STARTFROM 1093 ]]

If these don't work, try manually zooming in and out slowly (always further out than 1.0x) and seeing if the boundaries flicker out of existence at any point.

[rowett]

This may also be a display-dependent bug, but some grid boundaries may be invisible at specific zoom levels

Fixed in build 1350.

[muzik]

Is it at all possible to mitigate the severe performance hit that occurs as the camera gets closer to the grid edge in hexagonal rules? Note how this plays just fine at 5gps when you first click on it, but it slows to an absolute crawl as the grid edge takes up more and more of the screen:

Code: Select all

x = 5, y = 5, rule = B2/S2H
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ZOOM 4 AUTOSTART STARTFROM 240 GPS 5 TRACK 0 2/3 SHOWTIMING EXTENDEDTIMING ]]

[hotdogPi]

Is it at all possible to mitigate the severe performance hit that occurs as the camera gets closer to the grid edge in hexagonal rules? Note how this plays just fine at 5gps when you first click on it, but it slows to an absolute crawl as the grid edge takes up more and more of the screen:

Code: Select all

x = 5, y = 5, rule = B2/S2H
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ZOOM 4 AUTOSTART STARTFROM 240 GPS 5 TRACK 0 2/3 SHOWTIMING EXTENDEDTIMING ]]

It only slows down slightly for me, and to a percentage of where it's supposed to be. It slows down from 5 gps to about 3 gps and stays there, but if I set the slider to 20, it will definitely run faster than 5.

[rowett]

Is it at all possible to mitigate the severe performance hit that occurs as the camera gets closer to the grid edge in hexagonal rules? Note how this plays just fine at 5gps when you first click on it, but it slows to an absolute crawl as the grid edge takes up more and more of the screen:

The performance is mostly related to how many hexagons are being drawn. The grid edge at that zoom is made up of hexagons so you go from drawing 10 (the pattern) to tens of thousands as the off grid cells appear.

The easiest way to improve performance is either:

• Zoom in: at 8x zoom vs 4x zoom only 1/4 as many hexagons will be drawn beyond the grid edge

Code: Select all

x = 5, y = 5, rule = B2/S2H
obobo2$3bo$3b2o$4bo!
[[ MAXGRIDSIZE 9 ZOOM 8 AUTOSTART STARTFROM 310 GPS 5 TRACK 0 2/3 SHOWTIMING EXTENDEDTIMING ]]

Or:

• Switch to the offset square grid as it's significantly faster and not much visually different at 4x zoom

Code: Select all

x = 5, y = 5, rule = B2/S2H
obobo2$3bo$3b2o$4bo!
[[ SQUARECELLS MAXGRIDSIZE 9 ZOOM 4 AUTOSTART STARTFROM 240 GPS 5 TRACK 0 2/3 SHOWTIMING EXTENDEDTIMING ]]

[muzik]

Is it at all possible to mitigate the severe performance hit that occurs as the camera gets closer to the grid edge in hexagonal rules? Note how this plays just fine at 5gps when you first click on it, but it slows to an absolute crawl as the grid edge takes up more and more of the screen:

The performance is mostly related to how many hexagons are being drawn. The grid edge at that zoom is made up of hexagons so you go from drawing 10 (the pattern) to tens of thousands as the off grid cells appear.

Is it necessary that all out-of-bounds areas be drawn out of hexagons, given this performance impact? An identical visual result could presumably be achieved with far less geometry.

For example, here's a demonstration of a system that would use a lot less hexagons. They would only be used for the "boundary" between in-bounds and out-of-bounds, so that it has the correct looking shape when zoomed in. All regions out-of-bounds would be rendered as a continuous solid colour object rather than populated by smaller, individual shapes. Framerates here are demonstrably much better.

Code: Select all

x = 1024, y = 1, rule = B/S0123456HHistory
1024F!
[[ ZOOM 4 POLYSHADOW OFF COLOR POLY 96 96 96 POLYFILL 0 0 1023 0 3072 4095 2048 4095 0 0 4 SHOWTIMING EXTENDEDTIMING ]]

[muzik]

Right clicking on the top bar ("LifeViewer") will (at least on my end) cause an unusual thing to happen: the context menu appears as you'd expect, but moving the cursor will cause the viewer popup to follow it, as though left button is being held down.

afunnystate.png (236.08 KiB) Viewed 3911 times

The "show help topics" button in any help page still uses a caret, despite the "toggle fullscreen" button being changed from this to another character. I don't know if the former should change to match the latter, or if a visually distinct character should be used to emphasize the difference in function.

Using the scroll wheel to zoom in one unit and then zoom out one unit does not put us back at the zoom level we started from. In the opposite order, it seems to work (though it may still be very slightly further in than plain 4.0x).

Code: Select all

x = 3, y = 2, rule = B/S0123LE
3o$3o!
[[ ZOOM 4.0 ]]

For some reason the bottom left and top right of this hexagon appear noticeably thicker and more jagged than the other four edges, despite this pattern having full symmetry (this remains the case for all zoom levels further out than 1.0x):

Code: Select all

x = 1, y = 1, rule = /123456/3H
A!
[[ AUTOSTART ZOOM -4.0 ]]

This artifacting appears to be affecting the other zoomed-out hexagonal patterns on this page and reducing their visual quality.

The fix for icons becoming black appears to have some other strange effects. The icon appearances between these two examples are different in the draw menu and in Help > Info > Pattern. There are also visual oddities which I suspect may be different on PC - from my testing on an iPad, there exists strange visual blobbiness and morphing when moving the camera in the second example, and opening and closing a menu seems to make pixels black, unless there was text in that position in which case those regions become white.

Code: Select all

x = 7, y = 7, rule = monochrome-icons
2A.A.2A$2A.A.2A$2.3A$3A.3A$2.3A$2A.A.2A$2A.A.2A!
[[ ZOOM 8 ICONS ]]
@RULE monochrome-icons
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 192 192 192
1 255 0 0
2 255 0 0
@ICONS
XPM
"7 14 2 1"
"A c #FFFFFF"
". c #000000"
"AA.A.AA"
"AA.A.AA"
"..AAA.."
"AAA.AAA"
"..AAA.."
"AA.A.AA"
"AA.A.AA"
"..A.A.."
"..A.A.."
"AA...AA"
"...A..."
"AA...AA"
"..A.A.."
"..A.A.."

Code: Select all

x = 7, y = 7, rule = multicolor-icons
2A.A.2A$2A.A.2A$2.3A$3A.3A$2.3A$2A.A.2A$2A.A.2A!
[[ ZOOM 8 ICONS ]]
@RULE multicolor-icons
@TABLE
n_states:3
neighborhood:oneDimensional
symmetries:permute
@COLORS
0 192 192 192
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"