Pattern viewer for forum threads

[rowett]

The "Icon" button will become permanently enabled instead of grayed out if you enter a rule with a valid icon set, then one that doesn't.

Fixed, thanks!

Also noticing that the width for the period map key is now a constant width where it would previously adjust to fit however wide the biggest number was.

It wasn't fixed width it was just a bit too wide. I've narrowed it.

Something I've noticed that's most likely low priority to fix since I'm yet to reproduce this without paste commands...

Identify with PASTE commands is not supported.

For multistate higher-range rules there is no prompt stating that cells were deleted at the boundary

There won't be. The algo works slightly differently and effectively kills the cells before they hit the boundary.

What's planned next for LifeViewer in terms of features and supported rulespaces?

Still fixing minor issues at the moment so it depends how many of those come up before I think about anything major.

Here is a good place for anyone to make feature requests.

[muzik]

Something I've noticed with respect to period maps: Oscillizer, Oscillizer-Web and Nakano all mark the "initially alive" cells on period maps (optionally in the case of Oscillizer-Web), which is something LifeViewer does not do. Are there any plans to bring over this facet of period maps, or was it left out for a reason?

Example period map from the original Oscillizer:


The oscillator in question, at that specific phase:

Code: Select all

x = 43, y = 33, rule = B3/S23
12b2o$12b2obo15bo$16bo13bobo$8bo4bo11bo$7bobo4bob2o5b3o4bo7b2o$16b2o4b
o7b2o6bobo$9bo12b2o3b5o3b2obobo$8b2o17b2ob2o3bobobo$8b5o17bo6bo$b2o5b
2ob2o22bo2bo$obo6bo28bo$obob2o28bo3bo$bobobo12b3o8bobo2bo3bo$3bo14bobo
8bo2bo5bo$2bo2bo3bobo6b3o8bobo3bo2bo$2bo5bo2bo25bo$2bo3bo2bobo23bobobo
$2bo3bo28b2obobo$2bo28bo6bobo$2bo2bo22b2ob2o5b2o$3bo6bo17b5o$bobobo3b
2ob2o17b2o$obob2o3b5o3b2o12bo$obo6b2o7bo4b2o$b2o7bo4b3o5b2obo4bobo$15b
o11bo4bo$8bobo13bo$9bo15bob2o$27b2o!

[rowett]

Something I've noticed with respect to period maps: Oscillizer, Oscillizer-Web and Nakano all mark the "initially alive" cells on period maps (optionally in the case of Oscillizer-Web), which is something LifeViewer does not do. Are there any plans to bring over this facet of period maps, or was it left out for a reason?

The reason was that you have the pattern already in LifeViewer.

[muzik]

This only appears to affect predefined patterns in things like wiki infoboxes, but I'm noticing things don't always fit into the background for the period map key.
Example: https://conwaylife.com/wiki/P156_Hans_Leo_hassler

bigGap.png (39.31 KiB) Viewed 1874 times

[rowett]

This only appears to affect predefined patterns in things like wiki infoboxes, but I'm noticing things don't always fit into the background for the period map key.

Please try build 1165.

[muzik]

This only appears to affect predefined patterns in things like wiki infoboxes, but I'm noticing things don't always fit into the background for the period map key.

Please try build 1165.

Appears to be fixed for subperiod cells as far as I can see now.

fixedoverflow.png (39.35 KiB) Viewed 1853 times

Deathforcer cells might be slightly over the gap, though:

however.png (42.45 KiB) Viewed 1853 times

Code: Select all

x = 8, y = 5, rule = LifeHistory
2.F2$F3AF2$2.F!

[rowett]

Deathforcer cells might be slightly over the gap, though

Fixed, thanks!

[muzik]

The offset square grid now appears to be visually positioned wrongly, horizontally misaligned such that grid lines bisect cell centers rather than their edges:

Code: Select all

x = 7, y = 7, rule = B/S0123456H
4o$o3bo$o4bo$o5bo$bo4bo$2bo3bo$3b4o!
[[ GRID SQUARECELLS ]]

Could the heights of the offset squares in period maps be decreased so that they're the same proportions as the real offset grid, such that the period map for the following becomes as regular of a hexagon as it can be?

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 AUTOIDENTIFY ]]

There's also a bug that I can only reproduce on an iPad due to the way that scrolling causes the tabs bar to appear/disappear, resulting in the viewer window changing size: when the above period map is open while the viewer window changes size, the period map acts very strange, seemingly duplicating and stretching every time it's recomputed. Resizing browser windows on the desktop does not appear to yield this effect so I don't know how to reproduce it in other environments so far.

IMG_8731.jpeg (891.96 KiB) Viewed 1829 times

IMG_8732.jpeg (835.79 KiB) Viewed 1829 times

If LifeViewer were to implement a dedicated way of selecting cells on a hexagonal grid, what exact properties would you want it to have? I've linked and proposed several ways it could be done in response to this post (1, 2, 3, 4), but none of these have been implemented so far, and I assume this is either due to implementing hexagonal selections no longer being a priority or that these proposed systems were somehow missing a property desirable for hexagonal selection shapes. Given that many potential future features rely on this (according to this post), what exactly would a "good" system for hexagonal selections entail in your opinion, so that I can see if I can devise something workable?

[muzik]

The offset square grid now appears to be visually positioned wrongly, horizontally misaligned such that grid lines bisect cell centers rather than their edges:

Code: Select all

x = 7, y = 7, rule = B/S0123456H
4o$o3bo$o4bo$o5bo$bo4bo$2bo3bo$3b4o!
[[ GRID SQUARECELLS ]]

For reference, this is how it looks on iOS (Safari):

iosrender.jpg (339.76 KiB) Viewed 1792 times

On PC everything looks fine for whatever reason:

pcrender.png (30.41 KiB) Viewed 1792 times

Build 1166 is running in both cases.

[muzik]

Something I've noticed that's most likely low priority to fix since I'm yet to reproduce this without paste commands...

Identify with PASTE commands is not supported.

Identical behaviour without paste commands:

Code: Select all

x = 4, y = 4, rule = R2,C2,S3,12,B4,13,NW01010100000108010000010100000000000000000000000000
2bo$3o$b3o$bo!

Code: Select all

x = 4, y = 4, rule = R2,C0,S10,14,20,22,24,26,28,B7,11,15,21,23,27,29,NW01040000000200100000000800000000000000000000000000
bo$b3o$3o$2bo!

Flip⟍ would be expected here, but is not reported.

[unname4798]

The offset square grid now appears to be visually positioned wrongly, horizontally misaligned such that grid lines bisect cell centers rather than their edges:

Code: Select all

x = 7, y = 7, rule = B/S0123456H
4o$o3bo$o4bo$o5bo$bo4bo$2bo3bo$3b4o!
[[ GRID SQUARECELLS ]]

For reference, this is how it looks on iOS (Safari):
iosrender.jpg

On PC everything looks fine for whatever reason:
pcrender.png

Build 1166 is running in both cases.

This issue also happens on Android:

Screenshot_2024-07-21-14-13-34-194.jpeg (235.56 KiB) Viewed 1770 times

[rowett]

The offset square grid now appears to be visually positioned wrongly, horizontally misaligned such that grid lines bisect cell centers rather than their edges

Very strange. I haven't changed any of the code relating to this. Also I can't reproduce it since it works fine for me on my iPhone, MacBook Pro and Windows PC. I'm mindful just to deprecate the feature - which I probably should have done once the hexagonal grid was implemented.

[muzik]

The offset square grid now appears to be visually positioned wrongly, horizontally misaligned such that grid lines bisect cell centers rather than their edges

Very strange. I haven't changed any of the code relating to this. Also I can't reproduce it since it works fine for me on my iPhone, MacBook Pro and Windows PC. I'm mindful just to deprecate the feature - which I probably should have done once the hexagonal grid was implemented.

I would prefer that the offset square grid wasn't deprecated, largely on the basis that the current hexagonal grid is still considerably more expensive to draw, unless major optimizations are made that close the gap considerably in terms of performance. Likewise for the rectangular substitute for the triangular grid.

[rowett]

I would prefer that the offset square grid wasn't deprecated

Try build 1167.

[muzik]

I would prefer that the offset square grid wasn't deprecated

Try build 1167.

Code: Select all

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

Code: Select all

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

Build 1166:

1166results.png (129.02 KiB) Viewed 1736 times

Build 1167:

1167results.png (128.93 KiB) Viewed 1736 times

Both done on Firefox using an offline copy of LifeViewer - for whatever reason, things run a lot faster on Waterfox when I access the viewer page on lazyslug.com. Could two temporary testing pages be created there (one for 1166 and another for 1167) so I can see how performance compares there? For some reason, Waterfox just doesn't run embedded LifeViewer on an offline document so I wouldn't be able to compare.

[unname4798]

What is LifeViewer Pro?

[rowett]

Both done on Firefox using an offline copy of LifeViewer - for whatever reason, things run a lot faster on Waterfox when I access the viewer page on lazyslug.com. Could two temporary testing pages be created there (one for 1166 and another for 1167) so I can see how performance compares there? For some reason, Waterfox just doesn't run embedded LifeViewer on an offline document so I wouldn't be able to compare.

I didn't change the performance. I put in a potential fix for the offset square grid.

[muzik]

Both done on Firefox using an offline copy of LifeViewer - for whatever reason, things run a lot faster on Waterfox when I access the viewer page on lazyslug.com. Could two temporary testing pages be created there (one for 1166 and another for 1167) so I can see how performance compares there? For some reason, Waterfox just doesn't run embedded LifeViewer on an offline document so I wouldn't be able to compare.

I didn't change the performance. I put in a potential fix for the offset square grid.

In which case the fix does in fact appear to work. (I have noticed that, at least if you use the empty hexagonal pattern posted above, the major grid line positions instantaneously shift once you draw the first cell, but that might not be related.)

[rowett]

What is LifeViewer Pro?

A version of LifeViewer only for serious professionals. It differs in two respects: 1) it's not free. 2) it says "Pro" rather than "Standard".

[rowett]

(I have noticed that, at least if you use the empty hexagonal pattern posted above, the major grid line positions instantaneously shift once you draw the first cell, but that might not be related.)

Major gridlines have been disabled for hexagonal and triangular grids when using rectangular cells. They should never have been available since the hexagonal and triangular grids don't use them (when using hexagonal and triangular cells).

[rowett]

Could the heights of the offset squares in period maps be decreased so that they're the same proportions as the real offset grid, such that the period map for the following becomes as regular of a hexagon as it can be?

Yes, done.

If LifeViewer were to implement a dedicated way of selecting cells on a hexagonal grid, what exact properties would you want it to have? I've linked and proposed several ways it could be done but none of these have been implemented so far, and I assume this is either due to implementing hexagonal selections no longer being a priority or that these proposed systems were somehow missing a property desirable for hexagonal selection shapes.

I quite like the latest hexagonal selection proposal. When I get some time I'll take a more serious look.

In terms of priorities it depends on a number of factors including:

• reach: how many people might benefit from the feature
• impact: what is the quantative value it will deliver
• effort: how much work is involved building, testing and supporting the feature

So for hexagonal selections I'd need to consider how many people want it, how much benefit they would get from having it and how much effort it would be to build, test and support. If the reach and impact are small and the effort is large it becomes a low priority. Conversely if the reach and impact are large and the effort is small, it will be a high priority.
Getting this information takes time and requires research and sometimes some prototyping work which again needs prioritising.

If there are enough high priority items on the backlog then it's entirely possible a low priority item will take a long time to appear (or possibly never appear) given the limited resource on the project (in this case that's me). A recent example would be Icon support which was on the backlog for a long long time and was finally released a few weeks ago.

A great way of increasing the velocity of new features would be for more people to get involved and increase the resource on the project. The project is now open source and I'm happy to help motivated individuals get involved.

I'm always delighted with feedback, feature suggestions and bug reports. LifeViewer has come a long way since it was launched here on February 17th 2015 and this is largely due to the contributions from many in this community for which I am most grateful.

[muzik]

Not sure how much of a help I would be with respect to actually programming things but I've put in what is essentially a test commit to the lifeviewer page on GitHub.

Definitely plan on messing with things in future. For example, where is the 4194304 generation limit for Go To Gen/Identify specified in the code? I've searched for it in both decimal and hexadecimal and can't find anything.

[rowett]

where is the 4194304 generation limit for Go To Gen/Identify specified in the code?

life.js line 85.

[rowett]

Is the Advance Outside button also supposed to be copying the selection to the clipboard?

Yes at the moment it's using one of the internal clipboards. I may change that in the future.

This is now fixed.

[unname4798]

You doubleposted.