Pattern viewer for forum threads

[muzik]

When taking RLEs directly from Mark Niemiec's site and running them in LifeViewer, all living cells become LifeHistory marked cells and the viewer just generally behaves as if the rule is LifeHistory. ...except for the fact that the rule displayed in the T menu as well as Help > Info > Pattern is just given as "Life".

Code: Select all

x = 10, y = 8, rule = B3/S23
4b3x$xx$xbbx$bbxxbbx$bbx3b4x$4bx$bxx$bx!

I'm not sure what is intended here. Golly just converts these to normal two-state patterns. I've seen some patterns that use both "o" and "x" on the site, so I'm not sure if the distinction between the two letters is of any significance.

[confocaloid]

I'm not sure what is intended here. Golly just converts these to normal two-state patterns. I've seen some patterns that use both "o" and "x" on the site, so I'm not sure if the distinction between the two letters is of any significance.

I do not know, but that might be intentional so that copies of objects to be constructed are shown differently:

Code: Select all

#N 20mwmw1.rle
#O Mark D. Niemiec's life synthesis database, Thu Feb 19 02:05:28 2015
x = 64, y = 9, rule = B3/S23
42bobo$bbo39boo$bo33b3o5bo11b3x3b3x$b3o31bobbo16bxbbxbxbbx$22bxx11bo6b
oo11bx7bx$bo19bxbx11bo3bobobo11bx7bx$boo19bx12bo6bobb3o7bx7bx$obo33bob
o6bo10bxbxbxbx$46bo!

[rowett]

When taking RLEs directly from Mark Niemiec's site and running them in LifeViewer, all living cells become LifeHistory marked cells and the viewer just generally behaves as if the rule is LifeHistory. ...except for the fact that the rule displayed in the T menu as well as Help > Info > Pattern is just given as "Life".

This is intended.

Mark uses an extended RLE format with additional alive states which I guess he used to showcase items in a pattern. LifeViewer converts these into LifeHistory marked cells ('x' becomes LifeHistory marked state 3 and 'y' becomes LifeHistory marked state 5). LifeViewer doesn't change the rule name because it's not strictly a LifeHistory rule. However you can tell it is processing the marked states since Help->Info->Display->Type says "History Player" (rather than just "Player").

[muzik]

When will aliases be added to the list of supported aliases in the viewer again? This post from earlier has five of them.

[rowett]

When will aliases be added to the list of supported aliases in the viewer again? This post from earlier has five of them.

As I said here I think we need to come up with a mechanism to ensure all common tools share aliases.

[Anivec]

Is there a way to show which cells will be born next and which ones will die next?

[hotdogPi]

Is there a way to show which cells will be born next and which ones will die next?

The rule SlowLife does that as long as you're using it for its original intended purpose (i.e. no half-generation offsets).

[Anivec]

The rule SlowLife does that as long as you're using it for its original intended purpose (i.e. no half-generation offsets).

What about for other totalistic rules and isotropic-nontotalistic rules?

[wirehead]

The rule SlowLife does that as long as you're using it for its original intended purpose (i.e. no half-generation offsets).

What about for other totalistic rules and isotropic-nontotalistic rules?

I don't know, but the "SlowX" namespace is not really worth working with as opposed to the original rule unless you're deliberately introducing half-generation offsets.

[muzik]

I've seen a few people on Discord complain about a "selection offset" bug over the past few days, and I'm immediately able to reproduce it. I assume this is a known issue?

[dvgrn]

I've seen a few people on Discord complain about a "selection offset" bug over the past few days, and I'm immediately able to reproduce it. I assume this is a known issue?

Yes.

[rowett]

For patterns above the max identifiable period for strict volatility (and maybe also for oscillators in rulespaces unsupported by strict volatility calculation), could something be displayed in the Volatility column to indicate that the period was too high for it to be calculated?
https://catagolue.hatsya.com/object/xp6 ... 4zh/b026s1

The strict volatility value will now be "N/A" for such cases.

[rowett]

Several oscillators with low, but still nonzero, strict volatilities can sometimes be rounded down to 0.00 in the Identify table if the value is low enough: https://catagolue.hatsya.com/object/xp9 ... y3oo/b3s23

I don't like this, as it's rather misleading and implies many oscillators are trivial when they are in fact not.

"0" and "1" are now used when exactly 0 or 1.

[rowett]

Would it be possible for LifeViewer to render periodic cells of identified oscillators in different colors to distinguish their periodicity like the original Oscillizer did?

Yes this can be toggled with the Map button in the Identify results or hotkey D.

[muzik]

Would it be possible for LifeViewer to render periodic cells of identified oscillators in different colors to distinguish their periodicity like the original Oscillizer did?

Yes this can be toggled with the Map button in the Identify results or hotkey D.

Brilliant but can there also be an option to view which color represents which period?

[rowett]

Would it be possible for LifeViewer to render periodic cells of identified oscillators in different colors to distinguish their periodicity like the original Oscillizer did?

Yes this can be toggled with the Map button in the Identify results or hotkey D.

Brilliant but can there also be an option to view which color represents which period?

Yes it's coming...

[rowett]

Brilliant but can there also be an option to view which color represents which period?

Done.

[muzik]

The cell periodicity map for this is oddly offset to the right for some reason:

Code: Select all

x = 1, y = 105, rule = B026/S1
o5$o4$o6$o3$o3$o4$o$o$o4$o4$o3$o3$o4$o4$o$o$o4$o3$o3$o4$o4$o9$o3$o$o$o$o$o$o$
o4$o4$o$o$o$o$o$o$o3$o!

Rotating it 90 degrees gets us something shifted downwards a lot. This is likely due to it being B0, as alternating patterns are also affected:

Code: Select all

x = 3, y = 3, rule = B3678/S23678|B3/S23
o$3o$bo!

Also, would it be possible to make the counts for each cell period accessible via the Identify results table rather than only having them in Help > Info? They could be included alongside the key like in the original Oscillizer, or included separately via a third button on the right of the table.

Minor visual gripe: five-figure period values can overlap the periodicity map slightly:

Code: Select all

x = 156, y = 75, rule = B3/S23
146b2o5b2o$146b2o5b2o16$145b2obo3bob2o$145bo2bo3bo2bo$146b3o3b3o3$31b
2o$33bo$18b2o10b2o2bo$18b2o11bo2bo$32bobo$32b2o119b2o$153b2o$32b2o$32b
obo$18b2o11bo2bo10b2o30b2o$18b2o10b2o2bo10b2o30b2o$b2o4b3o23bo$b2o3bo
3bo20b2o$6b2ob2o$7bobo67bo$53bo2bo19bobo66bo2bo$7bobo21b4o22bo17b2ob2o
69bo$6b2ob2o19bo3bo18bo3bo16bobob3o64bo3bo$6bo3bo4b2o17bo19b4o14bob2o
2b2o66b4o$7b3o4b2o14bo2bo38bobo77b2o$16bo135bobo$154bo$86b2o34bo31b2o$
69b2o15bobo7b2o24b2o$51bo3b3o11b2o17bo7b2o23bobo$36b2o12bobo2b5o26b3o$
36b2o12bo3b2o3b2o$51bo2bo3b2o$3o5b3o41b3o3bo$o2b2ob2o2bo16bo58b3o$b3o
3b3o16b2o24b3o3bo10b2o17bo7b2o$2bo5bo17bobo22bo2bo3b2o9b2o15bobo7b2o$
36b2o12bo3b2o3b2o2b2o21b2o$36b2o12bobo2b5o3b2o$51bo3b3o52b2o$111b2o$
92bo17bo$50b2o38bo2bo$b2o5b2o42bo25b2o10b5o$b2o5b2o39b2o2bo10b2o12b2o
10b3ob2o$31bo18bo2bo10b2o25b2obo15bo3bo$30bo2bo4b2o11bobo38b2o15bo5bo
9b2o$17b2o10b5o3b2o12b2o56bo15b2o$17b2o9b2ob3o5bo52b2o15b2o3bo$29bob2o
18b2o38b2obo16b3o$30b2o19bobo24b2o10b3ob2o$50bo2bo10b2o12b2o10b5o16b3o
$30b2o17b2o2bo10b2o24bo2bo15b2o3bo$29bob2o19bo39bo16bo15b2o$17b2o9b2ob
3o16b2o57bo5bo9b2o$17b2o10b5o76bo3bo$30bo2bo$31bo!

[wirehead]

As much as I'm enjoying these circular questions perhaps I can be a little clearer:

• I am the sole author LifeViewer
• There has never been an open source version
• I have no current plans to release the source code
• If and when that changes I'll announce it on this forum

Thanks for your interest.

I know you said that you would be keeping LifeViewer closed source for now, but I would like to respectfully ask for a reconsideration of this decision. I have some ideas to improve LifeViewer, and I am willing to help add them, but I can't unless the source code is made available. (Things like infinite grids, incremental rule recompilation, graphics improvements, etc.)

Bump

Not trying to spoil anyone's holidays, but I don't see any answer yet. I will respect whatever answer is given, even if it is still no.

[muzik]

Here's another rare but expected edge case: for patterns which have a remarkably high number of differing cell periods, the legend can end up going off the bottom of the viewer rendering some unreadable. This pattern will give this effect when run in the embedded viewer at https://lazyslug.com/lifeview/plugin/viewer.html, as well as potentially some smaller resolutions of the popup viewer:

Code: Select all

x = 83, y = 109, rule = B3/S23
31b2o48b2o$32bo48bo$32bobo44bobo$33b2o8b3o22b2o9b2o$42b2o3bo19bo2b2o$
41b2o2bobo2b2o10b2o2b3o2bo$42bo5bob2o10b2o2bo4bo$43b5o18b5o2$8b2o33b5o
18b5o$9bo32bo5bob2o10b2o2bo4bo$9bobo29b2o2bobo2b2o10b2o2b3o2bo$10b2o
30b2o3bo19bo2b2o$16bo16b2o8b3o22b2o9b2o$15b2o15bobo44bobo$16bo15bo48bo
$31b2o48b2o3$51b2o6b2o$13bo36bo2bo4bo2bo$13b2o35bo2bo4bo2bo$13bo36bo2b
o4bo2bo$18b2o31b2o6b2o$18bobo$20bo$20b3o7b2o15b2o16b2o$23bo6bo17bo16bo
$22b2o4bobo17bob2o10b2obo$28b2o19bo3bo6bo3bo$24b3o27bo4bo$24b3o23bo3bo
4bo3bo$54bo4bo$21b2o26bo3bo6bo3bo$20bobo4b2o19bob2o10b2obo$20bo6bo20bo
16bo$19b2o7b3o16b2o16b2o$13bo16bo16bo$12bobo15bob2o10b2obo$8bo13b2o7bo
3bo6bo3bo$8bo2bo2bo4b2o2bo12bo4bo12b2o$7bob2o7b2ob2o9bo3bo4bo3bo8b2o$
11b2o5b2o16bo4bo$8b2o2bo5b2o11bo3bo6bo3bo14b5o$8b2o3b2o3b2ob2o7bob2o
10b2obo13bo$10bo8b2o2bo6bo16bo14bo2bo$12b3o7b2o5b2o16b2o14b2o$60b2o$
59bo2bo$39b2o22bo$31bo6bobo3b2o13b5o$15b3o13b2o4bo2bo3b2o$5bo12bo4b3o
9bo3bo29b2o$5b2o7bo3bo3bo3bo8bobo31b2o$13bobo2bo2bo5bo$bobo2b3o2bo2bob
o18bobo$b4obo4bo3bo4bo7bo6bo3bo$b2o8bo8bo7bo2b2o4bo2bo3b2o$12b3o16bo6b
obo3b2o$21bo5bo11b2o9b2o24b2o$22bo3bo23b2o24b2o$23b3o32b2o$11b2o44bo2b
o$10bo2bo44b2o$10bobobo$11bob3o46b3o$13b3o15bo2b2o4b2o2bo17bobo$30bo3b
3o2b3o3bo16b3o$31bo2b2o4b2o2bo18b2o$10b2o51b3o$8bo4bo49bobo$7bo6bo48b
3o$6bo8bo3b3o$6bo8bo5bo46b2o$6bo8bo4bo12bobo4b2o25bo2bo$7bo6bo17bob2o
3b3o26b2o$8bo4bo19bob3o12b2o24b2o$10b2o24b2o3bo8b2o24b2o2$12bo2bo19bo
3b2o$15bo19bob2o$11bo4bo18bo$11b2o2bobo$16bob2o3$16bo2bo$16b2o3b2ob2o
9b2o$21b2ob2o9b2o$3bo5bo$2bobo3bobo$4b2ob2o22b2o3bo$3b2o3b2o8bo12b2o2b
obo2b3o$4b2ob2o8bob4o13bo3bo2bo$16bobob3o16bo3bo$15bobo20bobo3bo$16bo
19b2obobobo$16b2o18bo3bo$16b2o18bo$4bo3bo7b2o19b2obo$3bobobobo29bo$4b
2ob2o2$bo9bo$obo7bobo$o3b2ob2o3bo$bo3bobo3bo$2b2obobob2o$4bo3bo!
[[ SHOWTIMING EXTENDEDTIMING ]]

It also seems like LifeViewer isn't reading RLEs properly anymore for triangular patterns:

Code: Select all

x = 4, y = 2, rule = B45/S34L
4o$o2bo!

And on the topic of triangular and hexagonal patterns, those don't interact well with the new map feature. When the map is opened, some extra lines appear which appear to correspond to cell edges, occluding the map. If the grid is enabled, these white lines cover the entire screen. They seem to remain white regardless of theme for some reason. In addition, the map still uses a square grid - it should be changed to a hexagonal or triangular grid accordingly.

Code: Select all

x = 4, y = 3, rule = B2o/S2oH
2b2o$o2bo$2b2o!

Selections also appear to occlude the map, which they probably shouldn't - other menus are rendered on top of them, so the map probably should as well since existing or accidentally made selections will end up covering parts of it.

From my testing on touchscreen and how it assumes where the mouse cursor would be, there appears to be no mouseover info for the "Map" button. Still yet to test this on a desktop, although to be honest this weird mobile behaviour (starting a tap somewhere inside the pattern grid, then releasing the two such that your finger was last over a button without actually using that button, resulting in info being displayed for that button) is probably something that itself should be patched.

Last thing on the topic of period maps, for cases where the map cannot be created (period too high, unsupported rulespace), can the button be present but grayed out for consistency with other buttons?

----

Would it be possible for the "Boundary" color for out-of-bounds regions to vary by theme?

[rowett]

The cell periodicity map for this is oddly offset to the right for some reason

Fixed, thanks.

Rotating it 90 degrees gets us something shifted downwards a lot.

Fixed, thanks.

Minor visual gripe: five-figure period values can overlap the periodicity map slightly

Fixed, thanks.

[rowett]

Here's another rare but expected edge case: for patterns which have a remarkably high number of differing cell periods, the legend can end up going off the bottom of the viewer rendering some unreadable.

Noted, not a priority.

It also seems like LifeViewer isn't reading RLEs properly anymore for triangular patterns:

Code: Select all

x = 4, y = 2, rule = B45/S34L
4o$o2bo!

Fixed, thanks.

And on the topic of triangular and hexagonal patterns, those don't interact well with the new map feature. When the map is opened, some extra lines appear which appear to correspond to cell edges, occluding the map. If the grid is enabled, these white lines cover the entire screen.

Fixed, thanks.

In addition, the map still uses a square grid - it should be changed to a hexagonal or triangular grid accordingly.

On the backlog.

Selections also appear to occlude the map, which they probably shouldn't - other menus are rendered on top of them, so the map probably should as well since existing or accidentally made selections will end up covering parts of it.

Fixed, thanks.

From my testing on touchscreen and how it assumes where the mouse cursor would be, there appears to be no mouseover info for the "Map" button.

There is a mouseover for the Map button.

Would it be possible for the "Boundary" color for out-of-bounds regions to vary by theme?

No.

Thanks again for all the time you spend testing LifeViewer.

[rowett]

I know you said that you would be keeping LifeViewer closed source for now, but I would like to respectfully ask for a reconsideration of this decision. I have some ideas to improve LifeViewer, and I am willing to help add them, but I can't unless the source code is made available. (Things like infinite grids, incremental rule recompilation, graphics improvements, etc.)

I'm delighted you are interested in helping with LifeViewer. I have been developing it over many years now and the source code is fairly large (around 95,000 lines). It's not a simple project and apart from code comments not documented so not simple to learn.

The best approach to get something added to LifeViewer is post the idea here and if it looks useful there is a reasonable chance I'll add it at some stage.

If the idea is something complex then it would be super helpful if you could build a prototype that implements the feature. It would then make adding it to LifeViewer easier (and therefore more likely). However, it's worth validating here first that there is a need for the idea.

Enjoy the holidays.

[rowett]

It's been 3 years and no one yet figured out how to enable secret snow...

Code: Select all

x = 77, y = 48, rule = B/S012345678
5o67b5o$4b5o59b5o$8b5o51b5o16$23bo3bo3b3o3b4o3b4o3bo3bo$23bo3bo2bo3bo
2bo3bo2bo3bo2bo3bo$23bo3bo2bo3bo2bo3bo2bo3bo2bo3bo$23b5o2b5o2b4o3b4o4b
obo$23bo3bo2bo3bo2bo6bo8bo$23bo3bo2bo3bo2bo6bo8bo$23bo3bo2bo3bo2bo6bo
8bo5$13bo3bo3b3o3bo6b3o2b4o4b3o3bo3bo3b4o$13bo3bo2bo3bo2bo7bo3bo3bo2b
o3bo2bo3bo2bo$13bo3bo2bo3bo2bo7bo3bo3bo2bo3bo2bo3bo2bo$13b5o2bo3bo2bo
7bo3bo3bo2b5o3b3o4b3o$13bo3bo2bo3bo2bo7bo3bo3bo2bo3bo4bo8bo$13bo3bo2b
o3bo2bo7bo3bo3bo2bo3bo4bo8bo$13bo3bo3b3o3b5o2b3o2b4o3bo3bo4bo4b4o12$6b
4ob5ob4ob13ob6ob9ob8ob4ob5o!
[[
AUTOSTART GPS 1
COLOR ALIVE 32 200 32 COLOR DEAD 0 0 64
ZOOM 8 Y 5
RLE blank b!
PASTEMODE COPY
PASTET 75 PASTE blank 64 2
PASTET 90 PASTE blank 12 2
PASTET 105 PASTE blank 65 2
PASTET 120 PASTE blank 11 2
PASTET 135 PASTE blank 66 2
PASTET 150 PASTE blank 10 2
PASTET 165 PASTE blank 67 2
PASTET 180 PASTE blank 9 2
]]

[wirehead]

I know you said that you would be keeping LifeViewer closed source for now, but I would like to respectfully ask for a reconsideration of this decision. I have some ideas to improve LifeViewer, and I am willing to help add them, but I can't unless the source code is made available. (Things like infinite grids, incremental rule recompilation, graphics improvements, etc.)

I'm delighted you are interested in helping with LifeViewer. I have been developing it over many years now and the source code is fairly large (around 95,000 lines). It's not a simple project and apart from code comments not documented so not simple to learn.

The best approach to get something added to LifeViewer is post the idea here and if it looks useful there is a reasonable chance I'll add it at some stage.

If the idea is something complex then it would be super helpful if you could build a prototype that implements the feature. It would then make adding it to LifeViewer easier (and therefore more likely). However, it's worth validating here first that there is a need for the idea.

Enjoy the holidays.

Well, here goes.

1) Infinite grids. The first (and probably best) approach would be to use Hashlife. I found this very simple implementation in Python and although it is missing a few key features (editing, multistate support, etc.) it looks pretty easy to port to Javascript once the memoization technique is figured out (which isn't too difficult).

2) Incremental rule recompilation. Previously you mentioned that LifeViewer likes @TREE rules better than ones only with @TABLEs, because @TABLEs are slow. Wouldn't memoizing the rule evaluator function speed it up considerably? I don't know what your calling convention is for the rule function, but evaluating it every time (especially with TABLEs) would ostensibly be slower than evaluating it once and caching the result. An idea would be this:

Code: Select all

function memoze_rule(fun) {
    var cache = {};
    return function memoized(...args) {
        var k = [].join.call(args, "");
        if (k in cache) return cache[k];
        return cache[k] = fun(...args);
    };
}

This could also work for the Hashlife memoization, as long as you implement a custom .toString() on your Node class so that it returns its own hash instead of "[object Object]" which would corrupt the cache.

3) Graphics improvements. Using CSS to lay out and style the buttons, do the animation of the blinking-hover-alert-text thing (whatever it's called), and any non-Canvas-mandatory things would free up processing power and let LifeViewer run faster and less laggy and competely eliminate the "menu" row in the EXTENDEDTIMING debug box. Muzik has also noted a few bugs where stuff unintentionally went off the screen because it was too long. If you just put it inside its own element and use CSS to set "overflow: auto;", the browser will take care of that for you.

Right now, you're basically re-implementing half of the browser's rendering engine in Javascript so you can draw it all on the canvas. But if you do it wil CSS and there are any graphics-glitch errors that are not on the canvas code, you can then just pawn them off as a browser bug, not one of yours!

I hope this helps. If you have an questions, or need me to make an example, feel free to ask.