Pattern viewer for forum threads

[muzik]

The hexagonal and triangular versions of the "none" rule don't report "none" as their neighbourhood when highlighted in the T menu or in Info > Pattern.

Code: Select all

x = 3, y = 3, rule = none
3o$3o$3o!
[[ GRID ]]

Code: Select all

x = 3, y = 3, rule = noneH
2o$3o$b2o!
[[ GRID ]]

Code: Select all

x = 5, y = 3, rule = noneL
b3o$5o$5o!
[[ GRID ]]

A random side effect of this I noticed: if we open a higher-range pattern and then check the neighbourhood of the hexagonal none rule afterwards, it appears to remember the range of that initial pattern.

Code: Select all

x = 3, y = 5, rule = Pigs
bo$obo$obo$bo$bo!

----

For Generations patterns, could a disclaimer of some sort be added to Help > Themes to indicate that the values displayed for "DYING" for each theme are different from what should be defined as "COLOR DYING" in script commands in order to achieve a set of visually identical dying states to said theme?

Code: Select all

x = 33, y = 2, rule = /2/34
pIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$pIpHpGpFpEpDpCpBpAXWVUTSRQ
PONMLKJIHGFEDCBA!

[muzik]

As of the iOS 15.2 update I also seem to be getting much, much slower frame rates, which I'm not sure is fixable - it's not common to get anything above 30fps anymore.

Some further testing now implies that, aside from rather infrequent cases which are hard to reliably reproduce and simple to mitigate, this may have been due to Low Power Mode being active. This is a bit more surprising than it probably sounds, since Low Power Mode explicitly states that it cancels background processes, which LifeViewer is not.

[rowett]

For PCA, random fills don't seem to accurately randomly fill a region with the density selected on the slider.

Fixed, thanks.

[rowett]

For Generations patterns, could a disclaimer of some sort be added to Help > Themes to indicate that the values displayed for "DYING" for each theme are different from what should be defined as "COLOR DYING" in script commands in order to achieve a set of visually identical dying states to said theme?

Code: Select all

x = 33, y = 2, rule = /2/34
pIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$pIpHpGpFpEpDpCpBpAXWVUTSRQ
PONMLKJIHGFEDCBA!
[[
COLOR ALIVE Yellow COLOR BACKGROUND Black
COLOR DYING 255 247 0 COLOR DYINGRAMP Red
COLOR DEAD Maroon COLOR DEADRAMP 64 0 0
]]

What am I missing?

[rowett]

The hexagonal and triangular versions of the "none" rule don't report "none" as their neighbourhood when highlighted in the T menu or in Info > Pattern.

Fixed, thanks.

[muzik]

Code: Select all

x = 33, y = 2, rule = /2/34
pIpHpGpFpEpDpCpBpAXWVUTSRQPONMLKJIHGFEDCBA$pIpHpGpFpEpDpCpBpAXWVUTSRQ
PONMLKJIHGFEDCBA!
[[
COLOR ALIVE Yellow COLOR BACKGROUND Black
COLOR DYING 255 247 0 COLOR DYINGRAMP Red
COLOR DEAD Maroon COLOR DEADRAMP 64 0 0
]]

What am I missing?

Interesting - so it seems that the DYING colors were correct all along, and are calculated on the fly per theme depending on the number of dying states within a rule?

In this case, the MCell theme will probably need some minor changes, since unlike other themes, its color for DYING is identical to the color it has defined for ALIVE, regardless of how many states are present.

The way Mirek's Cellebration actually handles multistate cell colors is considerably different (what color each state uses is fixed; the color that a cell with state 5 uses will be the same regardless of whether the rule in use has 7 states or 23 states), but I'm not sure if it'd be possible to implement such a system for Generations-type rules. If it is possible, I can provide the colors for each state.

----

Another theme-related thing: if we go to Help > Themes and check out the definitions for the Caterer theme, for example, no values are displayed for ALIVERAMP or DEADRAMP since the Caterer theme doesn't utilise state aging. However, a color value is in fact displayed for GRIDMAJOR, despite the fact that for this specific theme, the major grid interval is set to 0, which outright blocks major grid lines from being turned on, and resulting in a color value being displayed for a nonexistent element.

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ GRID THEME Caterer ]]

For the sake of consistency, could GRIDMAJOR's definition for the Caterer theme and other themes with a zero GRIDMAJOR interval be omitted, either by not being listed in the first place, or by having (none) be displayed as the value similarly to what is done in Help > Info > Colors for themes without alive and dead ramping (in which case, (none) should also be displayed for ALIVERAMP and DEADRAMP in Help > Themes for themes without it)?

[muzik]

How exactly is B0 handled by Identify, exactly? I've heard that for strobing cases, only every second generation is accounted for, which makes sense in some contexts, but for others the results it produces don't seem correct to me. This pattern, for example, is one such case:

Code: Select all

x = 10, y = 9, rule = B012345678/S
4b2o$3b4o$2b5o$2b5o$b7o$4o2b3o$4o2b4o$2o4b4o$6b3o!

The rule B012345678/S is essentially "every dead cell must be replaced with an alive cell, and every alive cell is to be replaced with a dead cell". This is, of course, not what is shown due to strobing being visually undesirable, and the pattern is emulated. So, in reality, the above pattern must necessarily be a period-2 oscillator, however Identify considers it a still life. This lines up with the behaviour we see, but not what is expected.

I'd also expect the following pattern to be considered a period-2 oscillator for similar reasons, since the cells that "stay alive" due to emulation would be oscillating with period 2 in a proper B0 environment:

Code: Select all

x = 9, y = 9, rule = B0/S
9o$9o$2o5b2o$2o5b2o$2o5b2o$2o5b2o$2o5b2o$9o$9o!

Here's another example case:

Code: Select all

x = 2, y = 2, rule = B0/S3
2o$2o!

For this pattern, being identified as a still life is expected; in "true B0", the entire universe would be flashing with a period 2 around the central 2x2 block, while the block itself would be staying put. Of course, emulation reverses this, so the block itself appears to be p2 in playback and the surrounding universe constant.

----

I also don't think that B0's Identify rules should be applied to non-B0 alternating rules, since they're not "emulating" any existing rules that can't be run normally, and are instead two existing rules put together intentionally. If they use the same sort of engine or algorithm to run as B0 rules, however, I can understand how separating them could be tricky.

[rowett]

so it seems that the DYING colors were correct all along, and are calculated on the fly per theme depending on the number of dying states within a rule?

True.

In this case, the MCell theme will probably need some minor changes, since unlike other themes, its color for DYING is identical to the color it has defined for ALIVE, regardless of how many states are present.

Feel free to propose the minor changes.

The way Mirek's Cellebration actually handles multistate cell colors is considerably different (what color each state uses is fixed; the color that a cell with state 5 uses will be the same regardless of whether the rule in use has 7 states or 23 states), but I'm not sure if it'd be possible to implement such a system for Generations-type rules.

I'm not looking to emulate how Mirek's Celebration handles multistate cell colours.

[rowett]

How exactly is B0 handled by Identify, exactly?

For any alternating rule (including the B0-strobe-avoidance emulation and Margolus rules) Identify only considers even generations.

[muzik]

In this case, the MCell theme will probably need some minor changes, since unlike other themes, its color for DYING is identical to the color it has defined for ALIVE, regardless of how many states are present.

Feel free to propose the minor changes.

For themes like Generations, Golly, Blues and so on, would I be correct in assuming that there is no explicitly-defined color for DYING, and that the gradient is calculated from ALIVE to DYINGRAMP with the first color after the alive color set to be DYING? If so, it'd probably be sufficient to delete the color defined for DYING in the MCell theme so that LifeViewer can calculate it like the other themes do.

If it doesn't work that way, let me know how it does and I can try to come up with a solution.

[muzik]

For patterns that die during STARTFROM or Go To Gen, the "Life ended at" notification appears to be cancelled prematurely:

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ STARTFROM 5 ]]

Generations patterns appear to misbehave somewhat when approaching the grid boundary. Births and deaths counters start to report 0 when they shouldn't, and dying states appear to decay four times faster which can result in major changes in behaviour for rules that don't have a lot of them.

Code: Select all

x = 9, y = 7, rule = 23/3/7
4.A.B.F$2.3ACB.F$2A2D$ABDF$A2B2F$.5AED$3.A.A.D!
[[ ZOOM 6 MAXGRIDSIZE 9 STARTFROM 430 X -215 SHOWGENSTATS ]]

Code: Select all

x = 9, y = 7, rule = 23/3/20
4.A.B.F$2.3ACB.F$2A2D$ABDF$A2B2F$.5AED$3.A.A.D!
[[ ZOOM 6 MAXGRIDSIZE 9 STARTFROM 430 X -215 SHOWGENSTATS ]]

Would it be possible to test how downloading images (period maps, as well as Save Image) works on iOS? On my end, when pressing Save Image or the period map download button, a prompt appears asking whether the file should be viewed or downloaded. Pressing View does nothing, and selecting Download has the image saved to Files rather than Photos. I don't know of any way to transfer images from Files to Photos other than "Save Image", which appears to make the period maps especially appear considerably more blurry than how they looked in the viewer:


Having the image be opened in a new tab, if possible, would be great since that would allow for the image to be easily downloaded from there, but I'm not sure if that's possible.

I've also tested image saving on a Samsung Galaxy A20e, where the images are correctly saved into the Gallery application.

Finally, no New Pattern message appears for [R]Super if the starting pattern contains no alive cells:

Code: Select all

x = 2, y = 10, rule = LifeHistory
2B$2B$2B$2B$2B$2B3$2B$2B!

Code: Select all

x = 2, y = 10, rule = LifeSuper
2B$2B$2B$2B$2B$2B3$2B$2B!

[rowett]

For patterns that die during STARTFROM or Go To Gen, the "Life ended at" notification appears to be cancelled prematurely

Fixed, thanks.

Generations patterns appear to misbehave somewhat when approaching the grid boundary.

Fixed, thanks.

Would it be possible to test how downloading images (period maps, as well as Save Image) works on iOS?

On my iPhone it works as you described. View does nothing and Download puts it in Files. I have no plans to change this functionality since I don't want platform specific differences.

Finally, no New Pattern message appears for [R]Super if the starting pattern contains no alive cells

I actually went the other way with this and removed the "New Pattern" message from the LifeHistory one. I decided that "New Pattern" is only relevant if there are no cells in the pattern, rather than no alive cells.

[rowett]

For themes like Generations, Golly, Blues and so on, would I be correct in assuming that there is no explicitly-defined color for DYING, and that the gradient is calculated from ALIVE to DYINGRAMP with the first color after the alive color set to be DYING? If so, it'd probably be sufficient to delete the color defined for DYING in the MCell theme so that LifeViewer can calculate it like the other themes do.

Yes, and done.

[muzik]

The Gaussian neighbourhood doesn't appear to be listed among the neighbourhoods in Help > Info > Engine. It does, however, appear listed under "Rules", but I'm not sure if this is correct since Gaussian isn't a rulespace. The same could be said for "Weighted", since custom weighted neighbourhoods are neighbourhoods and a subset of LtL/HROT. This placement could be intentional though; if so, what exactly dictates what goes where?

Also, for the two Generations boundary behaviour examples I posted earlier, the "Life ended at" message states the pattern dies at generation 504, but running it stepwise reveals all cells die at T=503.

[muzik]

Finally, no New Pattern message appears for [R]Super if the starting pattern contains no alive cells

I actually went the other way with this and removed the "New Pattern" message from the LifeHistory one. I decided that "New Pattern" is only relevant if there are no cells in the pattern, rather than no alive cells.

I think I prefer this solution since the message also appeared for patterns containing exclusively gray cells, which have functionality outside of acting as "marker" states.

The update notes for build 872 seem to be incorrect, since they appear to imply that the message should only appear if alive states are present, as opposed to only if they aren't.

[muzik]

When advancing a Margolus pattern an odd number of generations and then using Save Pattern, and opening the code box again, the pattern's behaviour changes completely. This spaceship, for example, becomes a period-4 oscillator:

Code: Select all

x = 3, y = 3, rule = M0,2,8,3,1,5,6,7,4,9,10,11,12,13,14,15
bo$2bo$2o!

Manually moving the configuration a cell diagonally to the bottom left appears to restore the original behaviour.

[rowett]

The Gaussian neighbourhood doesn't appear to be listed among the neighbourhoods in Help > Info > Engine.

Fixed, thanks.

Also, for the two Generations boundary behaviour examples I posted earlier, the "Life ended at" message states the pattern dies at generation 504, but running it stepwise reveals all cells die at T=503.

Fixed, thanks.

[Citation needed]

How do I put snow into the viewer?
EDIT: I can't draw in the "none" rule.

[muzik]

Some more PCA Identify edge cases:

The following period-4 oscillator is classified as RotCCW, however this doesn't seem correct as it reverses direction halfway through its evolution cycle rather than continuing in the same direction.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,1,4,3,2,5,6,7,8,9,10,11,12,13,14,15
A!

A more accurate result for this would be a mod of 2 and transform of RotCWFlipX, since the configuration is flipped across a diagonal line (top- left to bottom-right), as the N cell becomes a W cell and the E cell becomes a S cell halfway through its evolution cycle depending on where you start from. This specific PCA rule preserves pattern behaviour upon this kind of diagonal reflection anyway. Here's a period-4, mod-2 RotCWFlipX pattern in Life for comparison:

Code: Select all

x = 8, y = 9, rule = B3/S23
5b2o$6bo$b3obo$3bo$b4obo$o2bob2o$2o5bo$4b4o$6b2o!

A second case of interest is the following spaceship in another rule. Identify states that this spaceship has a mod of 1, which is correct, however it also states that its transformation is RotCCW, which is a completely invalid transformation type for spaceships in 2D, and RotCCW can also only apply to objects with a period which is a nonzero multiple of 4, which this is not either.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,8,4,3,2,5,6,7,1,9,10,11,12,13,14,15
A!

Here's a Life glider going in the same direction (at half the speed, but that doesn't matter). Identify labels this as RotCWFlipY, which I think should also be the case for the above c/2d spaceship since it too is "reflected" across a diagonal line halfway through its evolution cycle, as the N cell becomes an E cell.

Code: Select all

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

Finally, here's an oscillator which Identify claims has a mod half of its period and a transformation of RotCCW. RotCW and RotCCW oscillators must necessarily have a mod a quarter of their period, not a half. However, each of the phases of this oscillator at T=4, 5, 6 and 7 are indeed the same as the phase of the oscillator at T=0, 1, 2 and 3, respectively, but rotated anti-clockwise. I'm genuinely not sure what this should be classified as, since it doesn't fit any of the recorded square grid kinetic symmetries (likely due to PCA rules inherently being less isotropic than Life-like rules), so it might be worth leaving out a mod transform for this one if at all possible. Do as you see fit.

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,2,4,12,8,10,6,7,1,9,5,11,3,13,14,15
C!

[muzik]

For Margolus rules, GRIDMAJOR is set to 2 regardless of whatever theme is currently in use, which causes a couple of oddities:

Firstly, all of the GRIDMAJOR values displayed for each non-Margolus theme in Help > Themes remain at their usual values, despite these intervals not actually being used in these situations. (Help > Info > Gridlines displays the correct information for what the GRIDMAJOR currently in use is.)

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID ]]

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID THEME MCell ]]

Secondly, Major GridLines becomes toggleable for Themes that are usually specifically designed to not have major grid lines, such as the Catagolue and Caterer themes.

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID THEME Catagolue ]]

There are multiple possible solutions for this: if the current rule is a Margolus rule, all of the values for GRIDMAJOR in Help > Themes could be overwritten with 2 for each theme (with the possible exception of the GRIDMAJOR 0 themes). Alternatively, GRIDMAJOR could simply be not set to 2 automatically for Margolus patterns, and GRIDMAJOR 2 could be made exclusive to the Margolus theme and custom themes, such that changing the theme currently in use does not result in this odd behaviour and would set the major grid interval to whatever that theme's is even if a Margolus rule is in use.

----

I've also wondered for a while if the GRID and GRIDMAJOR colors for the Margolus theme are the wrong way round. The darker blue (32 32 255) always seemed like the "important" grid to me, whereas the paler blue (64 64 128) seemed more like it was in the background.

Code: Select all

x = 15, y = 2, rule = M0,2,8,3,1,5,6,11,4,9,10,14,12,7,13,15
bo2bo3b2o2b2o$2o2b2o2bo4bo!
[[ GRID ]]

Here are those same colors used with a GRIDMAJOR set to the default value of 10:

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ ZOOM 16 GRID COLOR GRID 32 32 255 COLOR GRIDMAJOR 64 64 128 ]]

This, of course, is likely just a matter of personal opinion, but in the above example, the "major" grid lines definitely appear to blend into the background far more than the "minor" grid lines.

Here's a pattern with those colors reversed, and in this example the major grid lines definitely feel more "major":

Code: Select all

x = 5, y = 4, rule = B3/S23
bo2bo$o$o3bo$4o!
[[ ZOOM 16 GRID COLOR GRID 64 64 128 COLOR GRIDMAJOR 32 32 255 ]]

[rowett]

How do I put snow into the viewer?

Snow was an Easter Egg that muzik mostly worked out. The formula to enable it is here (if you can read code).

I can't draw in the "none" rule.

Correct, drawing is not allowed in the "none" rule.

[GUYTU6J]

When there are more than one randomized patterns generated by script command, as was described in this post, does LifeViewer use one or more random seed?

I am requesting for the feature that LifeViewer display the seed(s) for randomization under Help - Info - Pattern so that the random pattern can be remade consistently by specifying RANDSEED.

[muzik]

If a change is made to a pattern through selections, such as making a random fill somewhere or clearing one of the following two shapes, and then the viewer is hard-reset via the Reset button, the ability to undo those changes becomes impossible as the Undo button becomes locked. Contrast this behaviour with changes made to a pattern via drawing - even after a hard reset, the Undo option remains available and those changes can be reverted.

Code: Select all

x = 21, y = 8, rule = B3/S23
8o8b2o$8o8b2o$8o7b4o$8o7b4o$8o6b6o$8o6b6o$8o5b8o$8o5b8o!

I've been caught out by this behaviour a few times when isolating a certain pattern from a stamp collection for identification purposes, then reverting to T=0 with intent to undo the isolation and check the next pattern, which is impossible without reopening the code box in question to get the initial configuration again. This effect ultimately seems to be mitigated if the selection modification is done first and a drawing change is done afterwards, since the Undo button remains usable for the selection operation after the fact.

Also, a much more minor thing about Undo: if a drawing is done over a region of dead cells, and this drawing is undone using the Undo button, those dead cells end up being replaced by background colored cells (or, in the case of [R]History, they return to dead cells but lose their age data). While this is the behaviour I'd expect for getting rid of those cells by manually drawing on them to take them back out of existence, I'd assume that Undo would work differently since it's resetting the viewer to a prior state rather than making further changes. I'm not sure if this is fixable or worth fixing though.

Code: Select all

x = 21, y = 8, rule = B3/S23
8o8b2o$8o8b2o$8o7b4o$8o7b4o$8o6b6o$8o6b6o$8o5b8o$8o5b8o!
[[ GRID ZOOM 20 STARTFROM 20 LAYERS 3 COLOR BACKGROUND Black COLOR DEAD 128 128 0 COLOR DEADRAMP 0 128 128 ]]

Code: Select all

x = 21, y = 8, rule = B3/S23History
8o8b2o$8o8b2o$8o7b4o$8o7b4o$8o6b6o$8o6b6o$8o5b8o$8o5b8o!
[[ GRID ZOOM 20 STARTFROM 20 LAYERS 3 COLOR BACKGROUND Black COLOR DEAD 128 128 0 COLOR DEADRAMP 0 128 128 ]]

And an unrelated question: in Help > Info, would it be possible to move the information for Stars somewhere above Randomize so it can be closer to other elements with configurable colors?

[rowett]

When there are more than one randomized patterns generated by script command, as was described in this post, does LifeViewer use one or more random seed?

I am requesting for the feature that LifeViewer display the seed(s) for randomization under Help - Info - Pattern so that the random pattern can be remade consistently by specifying RANDSEED.

The random seed is displayed in Help->Info->Randomize.

[muzik]

Sorry I didn't post this one sooner -- @ICON support.

This is already planned. The @ICONS section parser was written long ago. The renderer is on the backlog.
If you load a rule with an @ICONS section then you'll see info about the icons in Help->Info->Pattern.

Code: Select all

x = 1, y = 1, rule = Langtons-Ant
E!

I've checked this a couple times in recent builds and Help > Info > Pattern doesn't seem to include anything about icons. Has this been removed, or has it simply broken within the past month?

I'm going to load up Build 811 (the most recent build at the time of this post) just to check if it worked then.

EDIT: 811 still has this information. It stopped being there at some point between builds 811 and 842 and I'm trying to find out which one exactly.

EDIT2: Seems like build 818 is our culprit - the info is displayed just fine in build 817, bit is absent from 818 onwards. 818's file size is also considerably smaller than build 817, so perhaps the code for processing the icons was simply removed for the time being due to not being used for anything yet? We may never know.