Pattern viewer for forum threads

[muzik]

Is this pattern (and their similar such patterns) meant to be classed as FlipXY by Identify given they're invariant under horizontal reflection?

Code: Select all

x = 7, y = 5, rule = B3/S23
3ob3o$o5bo$2bobo$b2ob2o$o5bo!

[rowett]

Is this pattern (and their similar such patterns) meant to be classed as FlipXY by Identify given they're invariant under horizontal reflection?

Fixed, thanks!

[muzik]

Fixed, thanks!

And again thank you for all the fixes you've done lately!

[muzik]

A bunch of things I noticed in relation to PCA:

- It seems as though completely dead history states in PCA are duplicated across layers, like with that old Generations bug, to the point of being coplanar with alive cells:

Code: Select all

x = 10, y = 2, rule = PCA_4
.ED2B$BL!
[[ LAYERS 10 ]]

- Also, on the topic of layers, could PCA cells appear to be taller depending on how many cells are "inside" them, instead of their numerical state value? Currently they increase linearly from left to right on the following pattern:

Code: Select all

x = 15, y = 1, rule = PCA_4
ABCDEFGHIJKLMNO!
[[ LAYERS 10 ]]

whereas they should instead increase linearly left to right for these states (with every cell that shares a column having identical height):

Code: Select all

x = 4, y = 6, rule = PCA_4
.C$.E$AFG$BIK$DJM$HLNO!
[[ LAYERS 10 ]]

- I tried using Pattern > Change Rule to change the rule to Life on the very top pattern, and it put me in viewonly mode, which doesn't seem right.

- The invert function doesn't seem to be working correctly for PCA patterns either. The block below, which is composed of E cells, should (to my understanding) be turned into NSW cells when selected and inverted, but is instead turned into only N cells:

Code: Select all

x = 10, y = 10, rule = PCA_4
10B$10B$10B$10B$10B$10B$10B$10B$10B$10B!

- On the topic of selection, the 2-state random fill should probably be removed for PCA, since PCA are technically already 2-state rules and as such 2-state fill doesn't really have much use. (Although, if PCA are 2-state, why are we simulating them with multistate anyway - wouldn't it have been a better idea to just implement a tetrakis square tiling instead for them to be run on?)

- This pattern has a population of 3 during generation 0 and 4 in all subsequent generations, which seems odd given that generation 180 looks identical to generation 0 minus the dead history cells. The births and deaths counters in the T menu also don't seem to be making much sense, as they are sometimes different values from each other despite there being no change in overall population. It doesn't help that the reverse pattern button overlaps these counts, either.

Code: Select all

x = 2, y = 3, rule = PCA_4
.A$D$.C!

The pattern also has a mod of 4 according to Identify, which I'm not sure is right.

[rowett]

It seems as though completely dead history states in PCA are duplicated across layers, like with that old Generations bug, to the point of being coplanar with alive cells

This is on the backlog.

Also, on the topic of layers, could PCA cells appear to be taller depending on how many cells are "inside" them, instead of their numerical state value?

I'll have a think about this one.

I tried using Pattern > Change Rule to change the rule to Life on the very top pattern, and it put me in viewonly mode

Fixed.

The invert function doesn't seem to be working correctly for PCA patterns

Fixed.

... the 2-state random fill should probably be removed for PCA

Done.

This pattern has a population of 3 during generation 0 and 4 in all subsequent generations

Fixed.

The births and deaths counters in the T menu also don't seem to be making much sense

They make more sense now.

It doesn't help that the reverse pattern button overlaps these counts

They no longer overlap in Select mode with no Selection.

The pattern also has a mod of 4 according to Identify, which I'm not sure is right.

No it was wrong. Also fixed, thanks!

[muzik]

That's amazing. I think that in itself deserves a dedicated thank you.

I've found a few more quirks in the meantime, such as this oscillator being identified as a photon by identify:

Code: Select all

 x = 1, y = 1, rule = MargSingRot
o!

and a useless close button being generated when using identify on dying patterns:

Code: Select all

x = 8, y = 3, rule = B3/S23
bo$3o3b2o$6b2o!

EDIT: noticed that this is classed as a p2 oscillator, intended? EDIT2: probably not, since it has NaN temperature

Code: Select all

 x = 3, y = 2, rule = MargSingRot
b2o$b2o!

[muzik]

I'm now noticing some weird behaviour on the post with all the PCA reports on it. If you reload the page then check the mod of the spaceship of the bottom, it is identical to the period. If you then identify the big block of E cells, it shows mod 1 but then says it has a flip symmetry, which is wrong and it should instead have rotational symmetry. If then after this the spaceship at the bottom is identified, it goes back to saying the wrong mod from before build 504. Then if you go back to the big block, identify shows a more correct looking mod symmetry value.

[muzik]

A few more things to look at:

- PCA cells change colour when the theme is changed to one outside of the PCA theme, which I don't find is helpful, as the colours don't end up making much sense. I may suggest some theme-specific palettes for PCA sometime in the future but for now I think the best idea would be to simply make PCA cells not change colour when changing themes. The history states could stay theme affected, though.

Code: Select all

x = 3, y = 3, rule = PCA_4
O2$2.O!
[[ THEME Blues ]]

- For oblique ships, their Speed in Identify has the displacement values arranged differently depending on their orientation. As far as I'm aware, the correct formatting is that the bigger value should always come before the smaller value. Also is it supposed to be missing brackets?

Code: Select all

x = 3, y = 5, rule = B012ai3-ciy4aceqryz5cenqr6n/S1e2aik3acjkq4jnqrtwy5cjnr6e
2bo$2o$b2o$bo$2o!

Code: Select all

x = 5, y = 3, rule = B012ai3-ciy4aceqryz5cenqr6n/S1e2aik3acjkq4jnqrtwy5cjnr6e
o2bo$4o$2bobo!

- Using the draw tool to set cells to state 0 causes them to become history cells for PCA but completely black cells in normal 2 state rules, compare the patterns above.

- For non-reversible rules, when initially loaded, the step back button is lit up and looks like a functional buttons even though pressing it won't actually do anything. Shouldn't it be greyed out during generation 0 and only light up and become white when there are prior generations it can step back to? A similar such thing happens with the nostepback command - it showing a functional button which displays an error message isn't consistent with other functions.

Code: Select all

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

Code: Select all

x = 3, y = 3, rule = B3/S23
o$obo$2o!
[[ AUTOSTART STOP 3 NOSTEPBACK ]]

- The play backwards button in reversible rules still overlaps the T menu's population counts, and so do the options in the select menu.

- The generation counter in the T menu behaves inconsistently when playing a reversible pattern in reverse depending on whether the rule is Margolus or PCA:

Code: Select all

x = 3, y = 3, rule = PCA_4
O2$2.O!

Code: Select all

 x = 3, y = 3, rule = MargSingRot
bo$b2o$b2o!

I'd like to see this fixed by having two generation counters in the T menu: one for the way PCA currently behaves (which is identical to what is shown on the T button, but does not become truncated beyond 100K generations, allowing for us to see the true amount of generations), and one for the way Margolus currently behaves (which can never be negative, and shows the total amount of generations elapsed since the start).

[rowett]

...this oscillator being identified as a photon by identify

I'll put this on the backlog.

,,, a useless close button being generated when using identify on dying patterns

Fixed.

... noticed that this is classed as a p2 oscillator, intended?

Fixed, thanks!

[rowett]

I'm now noticing some weird behaviour on the post with all the PCA reports on it.

This should be fixed now, thanks!

[muzik]

A few thoughts on LifeViewer's custom ruletable support:

- There should be some way to specify the population value for certain states in a given rule. Currently every non-0 cell state in a custom ruletable is counted towards the total population with a value of 1, but this can prove problematic in certain cases. Example: this rule, which uses seven different dead states for different death conditions, having the Alive counter in the T menu reach and stay at 471 and never decreasing, as well as no "Life ended at generation" message showing as all cells which are intended to be considered alive dying:

Code: Select all

x = 7, y = 3, rule = LifeNoted
bo3bo$2obob2o$bo3bo!

Thus, it would be beneficial if there was some way to specify in a rule table which cell states contribute to the population counter with what value. This value could be any integer, not just 0 or 1, since for example PCA cells can have values of up to 4.

- Another thing that could be added: naming states. When selecting states for drawing for a Generations, [R]History or PCA rule, the name of the selected state is displayed. These are also the names used when specifying their colours through scripts. However in the case of ruletables, all of these states are completely nameless and are only referred to by number. It might be better if there was also a way to name states through the rule: pages on the wiki.

- States that are flipped or rotated variants of other states. This is another thing that affects the PCA rule family but is not accounted for in the case of ruletables. In certain non-isotropic multistate rules, some states may be effective mirror images/rotated forms of other states but otherwise functionally identical. LifeViewer does not currently recognise any such relationships, which can be seen in the following pattern - try rotating it and note how it evolves completely differently:

Code: Select all

 x = 15, y = 7, rule = HPP
3.P7.P3$P10.N2.P3$3.P7.P!

A way to specify the relationships between these in the rule table somehow would also be handy, and would take effect when flipping or rotating patterns in the Select menu as well as during mod calculations.

- On a similar road to the first suggestion here it should be possible to specify if a certain cell state is considered a "history" state or not. This would he helpful for specifying what gets deleted by the history clear option in selection settings, alongside stopping spaceships from being considered wickstretchers when using Identify in rules such as the LifeNoted above or the new swanky SuperLH with new history cell types.

- Some kind of option to define what cells are considered "inverses" of others, like with what was recently implemented for PCA, so the invert selection option works properly with them.

[dvgrn]

A few thoughts on LifeViewer's custom ruletable support:
...
It might be better if there was also a way to name states through the rule: pages on the wiki.

It turns out somebody on the Golly Gang thought of that a decade ago when the single-file .rule format was just coming into existence. So, e.g., WireWorld actually has an official @NAMES section:

Code: Select all

@NAMES

# these state names are not yet used by Golly
0 empty
1 electron tail
2 electron head
3 copper wire

... but it's never been used for anything. I seem to remember the vague plan was to have a label area in Golly's Editor toolbar giving the friendly name of the currently chosen state. But very few rules ever ended up with named states.

Meanwhile, @NAMES sections, like any other @LABELed section that Golly or LifeViewer is not looking for, just gets silently ignored. Which means that it should be safe to add sections to rule files along the lines of this old @NAMES example, and then if they get common enough and/or useful-looking enough, it's possible that support might be added for them in some future Golly or LifeViewer. Notice I'm not promising anything.

There should be some way to specify the population value for certain states in a given rule.
...
Thus, it would be beneficial if there was some way to specify in a rule table which cell states contribute to the population counter with what value. ...
States that are flipped or rotated variants of other states.
...
A way to specify the relationships between these in the rule table somehow would also be handy, and would take effect when flipping or rotating patterns in the Select menu as well as during mod calculations.
...
it should be possible to specify if a certain cell state is considered a "history" state or not.
...
Some kind of option to define what cells are considered "inverses" of others, like with what was recently implemented for PCA, so the invert selection option works properly with them.

Seems like the first step is to come up with a specific @POPCOUNTS format and an @XFORMS format that can store all this information, and add those sections to some of the rules that need them. It then may (or may not) become irresistible to write code that takes advantage of all that conveniently organized information.

[rowett]

PCA cells change colour when the theme is changed to one outside of the PCA theme, which I don't find is helpful, as the colours don't end up making much sense.

I don't mind the different colours but I'm happy for you to provide some better Themes if you wish.

For oblique ships, their Speed in Identify has the displacement values arranged differently depending on their orientation.

Fixed.

Using the draw tool to set cells to state 0 causes them to become history cells for PCA

Fixed.

For non-reversible rules, when initially loaded, the step back button is lit up and looks like a functional buttons

Fixed.

The play backwards button in reversible rules still overlaps the T menu's population counts

I switched the labels round so you can now see the counts.

...and so do the options in the select menu.

I'm not going to change this. The options only appear when there is a selection so it's easy to remove them.

The generation counter in the T menu behaves inconsistently when playing a reversible pattern

This is on the backlog, thanks!

[muzik]

Thank you again for all these fixes.

I doubt this is intended behaviour: the reverse button doesn't seem to respect alternating rules and you can use it to make cells dance around by spamming it, instead of having the rule run backwards to its initial starting generation and looking identical to it. Can also easily be reproduced by simply pressing the step back button then the step forward button, which doesn't return you to the starting pattern.

Code: Select all

x = 16, y = 16, rule = M0,2,8,3,1,5,6,14,4,9,10,13,12,11,7,15|M0,4,1,5,8,3,9,7,2,6,12,11,10,13,14,15
14$31bobobo2bobob2o$28b2ob2o3bobo2b2o$30b2ob3o3b2o$30b2obo3bo2b3o$28b
2o4bo3b2o$30b3o2bobo4b2o$28bob3o3bobo3bo$28b2o4b2o3bobo$28bo2bobo3bo2b
4o$28b3o5b2ob2obo$31b2o5bo2bo$28bob5obobob4o$29b2o3b2o3b2o$28bob2obo4b
2o3bo$29b3ob2o3bo3bo$28bo3b2o5b2o2bo!

Also, that big block of E cells in an above post seems to be showing a mod of 4 in Identify now, claiming to have simultaneously 2 stator cells and a volatility of 1.00...

[muzik]

There's this bug that I've noticed on touchscreen devices in general (both iOS and Android): sometimes, with a popup viewer active, when scrolling and doing stuff, there's a chance that the viewer will instantly jump to the area last tapped. This gets quite annoying and it also appears to disable the ability to drag the window so you can't correct it again.

Also, is there any plans to return support for alt margolus rules in the future?

The following four patterns return different values for Mod. From my limited understanding of PCA I'd think that 1 and 3 get it right and the remaining ones are wrong, but I may be wrong on this one.

Code: Select all

x = 1, y = 1, rule = PCA_4
B!

Code: Select all

x = 2, y = 2, rule = PCA_4
2B$2B!

Code: Select all

x = 3, y = 3, rule = PCA_4
3B$3B$3B!

Code: Select all

x = 4, y = 4, rule = PCA_4
4B$4B$4B$4B!

[rowett]

There's this bug that I've noticed on touchscreen devices in general (both iOS and Android)

I can't reproduce this.

Also, is there any plans to return support for alt margolus rules in the future?

I haven't removed support for Alternate Margolus rules.

[muzik]

Also, is there any plans to return support for alt margolus rules in the future?

I haven't removed support for Alternate Margolus rules.

Meant to say reversing them.

[muzik]

Hotkey suggestion: middle clicking on a cell, or having your mouse over it and pressing ', should select this cell as the one to be drawn with.

Is there a hotkey for random fill? I would suggest using Ctrl and 5 for this like with golly, but that's already taken by an entire system of select draw state hotkeys. Perhaps hotkeys could mean different things depending on the mode you're in but that might complicate things a bit too much.

[muzik]

This appears to rotate, not flip, and has a mod a quarter of its period, so FlipXY doesnt seem correct.

Code: Select all

x = 0, y = 0, rule = B3_S2-i3-a4cake
b2o$2o$bo!

[muzik]

This merge request just got accepted in, and it has some subsequently added aliases, so these should probably be added to lifeviewer's list as well.

[rowett]

Is there a hotkey for random fill?

Yes, see Help->Keys->Edit or the hotkey map.

[Hunting]

Wish Identify can recognize puffer & "spaceship + SL" constellations.

[rowett]

Hotkey suggestion: middle clicking on a cell, or having your mouse over it and pressing ', should select this cell as the one to be drawn with.

Press F3 and then click on the cell.

[rowett]

Wish Identify can recognize puffer & "spaceship + SL" constellations.

It's not a priority at the moment but thanks for the suggestion. I'll put it on the backlog.

[muzik]

Script commands for defining cell colours for ruletable rules only seem to work on the very last cell state

Code: Select all

 x = 1, y = 1, rule = Fredkin_mod7_Moore
A!
[[ COLOR 1 0 0 255 COLOR 2 0 255 255 COLOR 3 0 255 0 COLOR 4 255 255 0 COLOR 5 255 0 0 COLOR 6 255 0 255 ]]

Also can we have the ability to specify colours for dying generations states by name since we can do so for [R]History and PCA?

Code: Select all

 x = 2, y = 2, rule = /2/4
.A$2A!
[[ COLOR ALIVE 0 255 255 COLOR DYING_1 0 192 255 COLOR DYING_2 0 128 255 COLOR DEAD 0 0 0 ]]