Pattern viewer for forum threads

[rowett]

I assume that specifying "circles", "hexagons", etc. in @ICONS is also going to remain unsupported?

It's on the backlog but low priority.

Period maps for triangular rules seem quite blurry to me:

Same for hexagonal rules:

Fixed, thanks!

[muzik]

Could 3-state rules be made to use this colour scheme? I picked this out a while ago for BSFKL rules and general 3-state rules such that it'd thematically fit with the Blues theme while keeping cell states visually distinct enough.

Code: Select all

x = 1, y = 1, rule = W73
o!
[[ STARTFROM 64 AUTOFIT COLOR 1 0 255 192 COLOR 2 0 192 255 ]]

EDIT: I've created a pull request with this change.

I've also noticed that some odd rules use 3-state emulation when 2 states are sufficient, since both cell states behave identically to each other. For example, these two rules behave the same:

Code: Select all

x = 22, y = 1, rule = W51
2o2b6obobo4b2obo!

Code: Select all

x = 22, y = 1, rule = W204
2o2b6obobo4b2obo!

Likewise for these two:

Code: Select all

x = 1, y = 1, rule = W105
o!
[[ STARTFROM 63 ZOOM 4 Y 32 ]]

Code: Select all

x = 1, y = 1, rule = W150
o!
[[ STARTFROM 63 ZOOM 4 Y 32 ]]

If it's possible to detect that both cell states used would behave in the exact same way, then they could be collapsed into a single state and run as a 2-state rule instead of a 3-state rule.

[pifricted]

I've also noticed that some odd rules use 3-state emulation when 2 states are sufficient, since both cell states behave identically to each other. For example, these two rules behave the same:

Because W204 and W150 are self-complementary, so they have strobing dual.

LifeViewer don't let strobing duals become thier original rule

Code: Select all

#You can see the rule name is still "B01245/S0125", but not "Day and Night".
x = 7, y = 3, rule = B01245/S0125
o3b3o$3o2bo$bo!

[muzik]

Because W204 and W150 are self-complementary, so they have strobing dual.

LifeViewer don't let strobing duals become thier original rule

The same goes for standard black white reversals:

Code: Select all

x = 15, y = 15, rule = B0123478/S01234678
7b3o$6bo2bo$7bo3bo$2bo5b3o$3bo5bo$2ob2o$o2bo9bo$obo9bobo$bo9bo2bo$10b2ob2o$5b
o5bo$4b3o5bo$3bo3bo$5bo2bo$5b3o!
[[ SHOWGENSTATS ]]

[rowett]

Could 3-state rules be made to use this colour scheme?
EDIT: I've created a pull request with this change.

Yes, thanks.

If it's possible to detect that both cell states used would behave in the exact same way, then they could be collapsed into a single state and run as a 2-state rule instead of a 3-state rule.

No. I'm not interested in making changes when something already works well. I'd rather spend the time implementing new useful features and fixing bugs.

[confocaloid]

When some part of a pattern is selected, doing "Change Rule" has the unexpected side effect of trimming the pattern to leave only the interior of the selection.

• "Show in viewer" -> "Pattern -> Change Rule -> B3/S23 -> OK": the pattern is unchanged.
• "Show in viewer" -> select the beehive -> "Pattern -> Change Rule -> B3/S23 -> OK" : the pattern is trimmed so that only the beehive remains.

Code: Select all

x = 8, y = 4, rule = B38/S23
6bo$2o3bobo$2o3bobo$6bo!

[rowett]

When some part of a pattern is selected, doing "Change Rule" has the unexpected side effect of trimming the pattern to leave only the interior of the selection.

It's by design. It also happens if you use Save Pattern.

[H. H. P. M. P. Cole]

Ctrl+V does not work properly for HROT rules. Try copypasting something in any HROT or HROT weighted rule in LifeViewer and you'll see what I mean.

Any copypaste will result in a blank pattern being pasted.

[rowett]

Ctrl+V does not work properly for HROT rules. Try copypasting something in any HROT or HROT weighted rule in LifeViewer and you'll see what I mean.

Any copypaste will result in a blank pattern being pasted.

Fixed in build 1179, thanks!

[muzik]

On pages with large embeds such as the home page https://lazyslug.com/, triangular period maps can sometimes appear big enough that they exceed the vertical size of the viewer.

Code: Select all

x = 4, y = 2, rule = B2/SLE
2bo$bobo!
[[ AUTOIDENTIFY ]]

In addition triangular period maps appear to revert to a normal square grid when saved.

[muzik]

Something seems broken about these period maps:

Code: Select all

x = 6, y = 6, rule = B2o3m56/S2-p4oH
bo$3bo$2bo2$o2b3o$bo2bo!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 3, y = 5, rule = B2/S34H
bo$o$obo$2bo$2bo!
[[ AUTOIDENTIFY ]]

[rowett]

Something seems broken about these period maps

Fixed, thanks!

[muzik]

Also, while preparing that above example, something weird I noticed:

Fixed, thanks!

Not sure if the fix for this has caused this issue to resurface, but it's back anyway:

Code: Select all

x = 1, y = 1, rule = B/S0123HT
o!
[[ X 15 GRID ZOOM 16 ]]

We are very much not centered on X 15.

Code: Select all

x = 1, y = 1, rule = B/S0123LE
o!
[[ X 15 GRID ZOOM 16 ]]

Code: Select all

x = 1, y = 1, rule = B/S01234V
o!
[[ X 15 GRID ZOOM 16 ]]

Speaking of using commands to define where the grid is initially centered, I've never understood why there's a limitation forbidding the grid from being centered at an out-of-bounds position via scripts, especially since you can scroll past that point manually. Could this restriction be lifted, or at least relaxed by a lot?

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ MAXGRIDSIZE 9 X 256 ]]

Code: Select all

x = 2, y = 2, rule = B3/S23
2o$2o!
[[ MAXGRIDSIZE 9 X 257 ]]

On backlog.txt does "ability to specify Dying state colours" refer to being able to change their colours by specifying their names? If so, this has been possible for a while now, so the file could be amended to acknowledge this:

Code: Select all

x = 3, y = 4, rule = /2/3
BA$.BA$.BA$BA!
[[ COLOR "dying 1" Blue ]]

It may also be advisable to implement proper state names for odd Wolfram emulation - perhaps "background" for state 0, "even alive" for state 1 and "odd dead" for state 2. We'd call state 0 "background" rather than "dead" in this case due to the background state alternating when this rule is "truly" being run, and the other state names arise due to state 1 representing living cells in even generations and state 2 representing dead cells in odd generations

[muzik]

How exactly do we calculate bounding boxes for spaceships? Nakano says this is 117x117, but LifeViewer gives 122x137:

Code: Select all

x = 41, y = 24, rule = B2k3acijr4ijqy6n8/S2aek3-acey4cit5ej6aci7e
4bo2$o2bo2bo$bobobo$bo2b2o$2b3o$3bo7$37b3o$37bo2bo$36bo$35bobo$35bo$
35b2obo$38bo2$37bo2$38bo!

[confocaloid]

Related discussion: viewtopic.php?f=16&t=6575 "bounding boxes of spaceships [LifeWiki Discussion; infoboxes]"

I think there's no "single best way" to define "the bounding box of a spaceship" (and there's currently no single commonly agreed way).

Even for oscillators, there may be two different phases with two different bounding boxes that have the same area which happens to be the minimum single-phase bounding box area. So it would be misleading to say either "minimum single-phase bounding box 6x10" or "minimum single-phase bounding box 5x12", even though saying "minimum single-phase bounding box area 60" would be correct.

How exactly do we calculate bounding boxes for spaceships? Nakano says this is 117x117, but LifeViewer gives 122x137:

Code: Select all

x = 41, y = 24, rule = B2k3acijr4ijqy6n8/S2aek3-acey4cit5ej6aci7e
4bo2$o2bo2bo$bobobo$bo2b2o$2b3o$3bo7$37b3o$37bo2bo$36bo$35bobo$35bo$
35b2obo$38bo2$37bo2$38bo!

[muzik]

Autofitting history appears to be doing something strange - it works vertically, but not horizontally, for hexagonal patterns.

Code: Select all

x = 10, y = 10, rule = R6,C2,S25-26,31,34,36-38,46-80,95-96,98,101-105,110-111,B47-52,56,63-71
3b5o$2b7o$b9o$4o3b3o$4o3b3o$4o3b3o$b9o$b8o$3b5o$4b3o!
[[ AUTOFIT HISTORYFIT ]]

Code: Select all

x = 5, y = 5, rule = R1,C2,S2-3,6-9,11-15,B5,10-11,14-15,NW410104041H
3bo$ob3o$3o$bobo$b3o!
[[ AUTOFIT HISTORYFIT ]]

[muzik]

For this pattern, manually enable Kill Gliders at T=240 then identify the pattern - the computed bounding box size is much bigger than expected, which also affects the period map.

Code: Select all

x = 47, y = 38, rule = LifeHistory
33.A3.2A$32.A.A.A.3A$32.A.A.A4.A$33.A.A.ABABA$35.A.A.2A4.2A$23.2A9.AB
A4B4.A$21.2B2AB6.3BA2B4.BA.A$21.2B2A6.5B4.B.B2A$21.2B3A4B.6B2.4B$22.B
ABA5B2A10B$22.BA2BA6BA9B$6.A15.2B4A3B2A11B$6.3A8.2A.A5B3A11B.4B$9.A7.
A.2A2.4BAB2A8B3.4B$8.2A14.2BAB2ABA3B2A6.3BA$8.6B10.5BABA2BA4B5.ABA$10.
4B10.8BA4BABA5.2A$8.7B7.A8BABAB2ABABA5.B$5.10B6.ABAB2.3B.4A4B2AB$4.8B
A2B.3B2.A2BA6.2BA7B$5.7BA9B2A7.7B$6.16B10.4B$7.3BABABA7B10.6B$9.B5A7B
14.2A$7.2A4BAB2A6B2.2A.A7.A$6.A4BA2B2ABA7BA.2A8.3A$.B2.13B3A4B15.A$2A
B.2B2A3BA5BA6B$2A8B2A12B$.B.4B2.3A3B.9B$4.2B4.A4B6.4B$8.A2BA2B6.B2A2B
$5.2A3B2A9.2A$5.2B.A.A$4.ABABA.A.A$4.A4.A.A.A$5.3A.A.A.A$7.2A3.A!
[[ STARTFROM 240 ]]

Bounding boxes are also inconsistent between these patterns, despite being behaviourally identical:

Code: Select all

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

Code: Select all

x = 3, y = 5, rule = R1,C2,S2-3,B3
2o$obo$2bo$obo$2o!
[[ PASTEMODE XOR PASTET EVERY 1 1 PASTE o! 3 2 ]]

Code: Select all

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

Pasting like this doesn't appear to work for [R]History or [R]Super, but does for [R]Investigator.

Code: Select all

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

Code: Select all

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

Code: Select all

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

For triangular period maps, horizontal grid lines appear thicker than vertical grid lines; I'd expect uniform thickness in both directions.

Code: Select all

x = 6, y = 3, rule = B139/S2LV
2bobo$bobobo$2bobo!
[[ AUTOIDENTIFY ]]

Could buttons to rotate a selection 180 degrees as well as flip the selection across either of two diagonals be implemented? These actions can be done via combinations of other flip/rotate actions, but (especially in the latter case) it is hard to remember what to actually do in these cases.

[Citation needed]

How should I use waypoints?
Do waypoints work with TRACK, PASTE, COLOR, POLYGON and LABEL?
If so, how does it work?
If not, is there a workaround?

[H. H. P. M. P. Cole]

In https://lazyslug.com/lifeviewer/ the settings button does not seem to be working or showing properly.

This is what it looks like on my desktop:

Screenshot 2024-07-31 095312.png (5.71 KiB) Viewed 1814 times

However, it seems to be working fine on the forum-based LifeViewer.

[pifricted]

In https://lazyslug.com/lifeviewer/ the settings button does not seem to be working or showing properly.

This is what it looks like on my desktop:

Screenshot 2024-07-31 095312.png

Use larger scale.

[dvgrn]

How should I use waypoints?
Do waypoints work with TRACK, PASTE, COLOR, POLYGON and LABEL?
If so, how does it work?
If not, is there a workaround?

It doesn't seem like there's an easy answer for the "how does it work" question. Yes, waypoints work with all of those things, in some sense.

If you want to see examples of how they work, go to the Patterns/Life/Rakes folder in any recent version of Golly. Open each of the rake patterns in turn, and then run the "showinviewer.lua" script. In the various different rake patterns you'll see how TRACK, COLOR, POLYGON, and LABEL work.

For an extended example of the use of waypoints with most of these commands, see the LeapLife timeline.

PASTE and PASTET aren't often mixed with waypoints, but there's no reason they couldn't be. An extended timeline like the LeapLife one would be somewhat easier to build if PASTET were used to drop spaceships and such into the pattern when they're supposed to make an appearance, and maybe PASTET again with XOR to take them out again -- rather than figuring out how to keep a clear path from far away and start everything at T=0.

[Citation needed]

How should I use waypoints?
Do waypoints work with TRACK, PASTE, COLOR, POLYGON and LABEL?
If so, how does it work?
If not, is there a workaround?

LeapLife timeline

Code: Select all

x rule = LifeSuper
.3o$o$o!
[[ GPS 10 ]]
[[ T 1 X 5 Y 5 Z 5 COLOR 2 0 0 255 ]]
[[ T 11 X 15 Y 15 Z 8 COLOR 2 255 128 0 ]]

Unfortunately, the color didn't work.

How should I change the LifeViewer window size?

[muzik]

Perhaps we could refresh the colours used for period maps a bit?

Code: Select all

x = 44, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
44o!

Here's a proposed colour scheme - a set of fixed colours composed of the Nakano colours (excluding #AEAEAE as grayscale is reserved for other annotations), followed by the classic Oscillizer colours (once we run out of defined colours we start generating them algorithmically like LifeViewer currently does):

Code: Select all

#FFFFFF - full period
#1C92CD - highest subperiod
#0AB87B - second highest subperiod
#E86075 - third highest subperiod
#F8F290 - fourth highest subperiod
#BA4117 - fifth highest subperiod
#D91E9B - sixth highest subperiod
#BEF0E9 - seventh highest subperiod
#428C28 - eighth highest subperiod
#6F1044 - ninth highest subperiod
#76ADF4 - tenth highest subperiod
#2D5963 - eleventh highest subperiod
#D9B790 - twelfth highest subperiod
#80FF80 - thirteenth highest subperiod
#9090FF - fourteenth highest subperiod
#C0C000 - fifteenth highest subperiod
#80FFFF - sixteenth highest subperiod
#FFC0FF - seventeenth highest subperiod
#FFC0C0 - eighteenth highest subperiod
#FFFF00 - nineteenth highest subperiod
#FF8000 - twentieth highest subperiod
21st subperiods and lower - use current algorithm for colorisation (HSV round trip with mod-4 darkening)

The grid, boundary, background, stator and deathforcer colours would remain as they currently are.

Here's how this would look in practice:

recoloredMapproposal.png (935 Bytes) Viewed 1777 times

Current colours for comparison - I find that some regions adjacent to each other can be given very similar colors, which can make them difficult to tell apart (also the case for the length-54 oscillator):

currentmaptheme.png (7.08 KiB) Viewed 1777 times

length54map.png (10.97 KiB) Viewed 1777 times

Code: Select all

x = 54, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
54o!

[rowett]

Unfortunately, the color didn't work.

How should I change the LifeViewer window size?

You can't change individual colours at each Waypoint. You can change the [[ THEME ]] for rules that support Themes. [R]Super does not.

To change the LifeViewer windows size use the [[ POPUPWIDTH ]] and [[ POPUPHEIGHT ]] commands. For example:

Code: Select all

x rule = Life
.3o$o$o!
[[ POPUPWIDTH 800 POPUPHEIGHT 600 ]]
[[ GPS 8 ]]
[[ T 1 X 5 Y 5 Z 5 THEME Blues ]]
[[ T 11 X 15 Y 15 Z 8 THEME Mono ]]
[[ T 22 X 10 Y 10 Z 14 THEME Poison ]]
[[ T 33 X 0 Y 0 Z 2 THEME Day ]]
[[ T 44 X 0 Y 0 Z 16 THEME Blues ]]

[rowett]

How exactly do we calculate bounding boxes for spaceships? Nakano says this is 117x117, but LifeViewer gives 122x137:

Code: Select all

x = 41, y = 24, rule = B2k3acijr4ijqy6n8/S2aek3-acey4cit5ej6aci7e
4bo2$o2bo2bo$bobobo$bo2b2o$2b3o$3bo7$37b3o$37bo2bo$36bo$35bobo$35bo$
35b2obo$38bo2$37bo2$38bo!

LifeViewer calculates three things:

• The bounding box that encloses all phases of the spaceship. This is displayed in the results summary as Bounding Box.
• The maximum bounding box for any single phase.
• The minimum bounding box for any single phase.

The latter two are displayed in Help->Info->Identify after Bounding as T Min/Max. In this case LifeViewer shows T Max as 117x117 which is the value Nakano presents.