Pattern viewer for forum threads

[rowett]

Triangular bounded grids seem to be flawed.

Fixed, thanks.

[muzik]

I'm also considering having 2-state LtL, HROT (and possibly Generations) allow the full LifeViewer Theme processing (decaying dead cells etc.). In which case they would default to THEME 1 as for the other 2-state rules.

Would it be possible to support history/theme processing for 2-state ruletables as well?

Code: Select all

x = 4, y = 6, rule = B3/S23
2bo$2obo$3bo$bobo$o$b3o!

Code: Select all

x = 4, y = 6, rule = Life-RuleLoader
2bo$2obo$3bo$bobo$o$b3o!

[rowett]

... can the following triangular neighbourhood (possibly "LA" for Triangular All) also be added?

No need since this can be done with a custom neighbourhood.

[rowett]

Would it be possible to support history/theme processing for 2-state ruletables as well?

No need. Either add history to the RuleTable or use an equivalent MAP rule.

[rowett]

Can the "select drawing state" bar found in Draw mode also be added to Select mode, such that the 2-state random fill state can be selected from there without having to go to Draw and then back to Select?

No it creates too much clutter for something that is rarely used.

[muzik]

Would it be possible to support history/theme processing for 2-state ruletables as well?

No need. Either add history to the RuleTable or use an equivalent MAP rule.

For ruletables in their current state I can agree. However Golly's rule table repository roadmap details some other 2D neighbourhood types that could end up being supported by Golly and/or LifeViewer in future, and the rulespaces these cover may be too vast for rulestring coverage. Isotropic range-2 Moore rules, for example, have millions of distinct 2-state transitions, and there doesn't appear to be any standard isotropic non-totalistic notation for range-1 triangular rules devised so far. So could this be reconsidered in the event that these rule families receive support from rule tables?

[rowett]

For embedded viewers, would it make sense for the "shrink viewer" button at the bottom right of Settings to be present, but grayed out, like how other buttons behave?

Shrink is only relevant to Thumbnails and works in the same way as the Close button for popup Viewers.

[muzik]

Can all themes be made to display their grid and gridmajor values in Help > Themes? Currently only the themes that stray from the default settings display such values, but it'd be preferable if every theme displayed the values it used for consistency's sake.

[rowett]

Can all themes be made to display their grid and gridmajor values in Help > Themes? Currently only the themes that stray from the default settings display such values, but it'd be preferable if every theme displayed the values it used for consistency's sake.

I prefer the current approach since it shows the setting required in each case. Also it keeps the list shorter.

[muzik]

I prefer the current approach since it shows the setting required in each case. Also it keeps the list shorter.

Another possible solution: Help > Themes could have the "grid" section hold info relating to grid definitions per theme, instead of them being held in the 2-state section (which would make them easier to find as well, since having them hidden in that section doesn't make much sense to me, and it also kind of implies multistate rules don't have grid definitions).

----

A theme-related suggestion: would it be possible to have some sort of script command that allows for a "base theme" to be used when configuring certain theme-related values, instead of everything becoming black and white? For example, say I wanted to use a theme identical to the Poison Theme except for the fact that newly born cells are orange. Currently, to achieve that effect, I'd have to define everything relating to that theme with commands, but it'd be better if there was a command that basically said "use the Poison theme, but with everything defined afterwards added on top". This could be something like "BASETHEME Poison", where Poison can be replaced with any valid theme, or just a binary setting like "USEBASETHEME", where the base theme would be either defined via other script commands or the default would be used.

[muzik]

This is hard to see without custom themes, but when opening a viewer popup for the first time after page load, a large rectangle (actually two rectangles) appear at the bottom left of the viewer, which are the "mouse is currently over" and "current selection size" text boxes with no contents. If the popup viewer is closed and then reopened, only the latter will be visible. Furthermore, if a selection is made before the viewer is closed and the popup is opened again, the viewer remembers and displays the last selection's size for some reason, and if a cell was highlighted previously, the "currently highlighted cell" box will remain present in future openings rather that not doing so.

Expected behaviour here would be for these boxes to simply not appear while the pattern is loading - there's no need for them to be here in this situation.

Code: Select all

x = 16, y = 16, rule = B2-a5/S1e2-a35678
2bobobob4obobo$bob2obo2bo2b2o$2bobo4b3ob3o$3obo5bob2o$3o4b2o4b3o$2o5b
8o$bo2bo5b3o$o2b2o4bo2b2o$o2bobob3o4bo$2o2b4o3b3o$3o2b2obo3b4o$3bo5bob
2ob2o$o4b6o2b2o$4ob3obob2o$2b4ob2o3bobo$ob2o4b4ob2o!
[[ COLOR UIBACKGROUND Pink ]]

Reiterating a bug from a page or two ago: selections on this grid visually appear to be a pixel higher than they should be.

Code: Select all

#CXRLE Pos=192,192
x = 5, y = 4, rule = B3/S23:T192,192
24o!
[[ MAXGRIDSIZE 9 ZOOM 32 GRID ]]

Bounded grid patterns do not appear to be centered correctly. Compare with the equivalent arrangement of only living cells in an unbounded grid:

Code: Select all

x = 0, y = 0, rule = B3/S23
10o$o8bo$o8bo$o8bo$o3b2o3bo$o3b2o3bo$o8bo$o8bo$o8bo$10o!
[[ GRID ]]

Code: Select all

x = 0, y = 0, rule = B3/S23:T8,8
2o$2o!
[[ GRID ]]

Currently the tilt slider has a minimum value of 0. Would it be possible to make the tilt slider be able to go into the negatives, in which case the screen would tilt in the opposite direction?

Code: Select all

x = 0, y = 0, rule = B3/S23
2o$2o!
[[ GRID TILT 5 ]]

Code: Select all

x = 0, y = 0, rule = B3/S23
2o$2o!
[[ GRID TILT -5 ]]

Selections/paste/advance still appear to ignore grid tilting, as does drawing, the "what cell is currently under the cursor" functionality and related things.

Could the farthest zoom out level be increased to -64 for symmetry's sake, since the farthest in is +64?

And is there any way in which I can help to improve the performance of LifeViewer? Performance seems to be getting considerably worse lately, which is probably more on Apple than anything else but I've recently upgraded to a much more modern device (Air 4th generation) and am therefore considerably more displeased with them for the poor FPS I seem to be getting lately. I also have several more devices on which I can perform tests if a diverse set of samples would be of any use.

[rowett]

This is hard to see without custom themes, but when opening a viewer popup for the first time after page load, a large rectangle (actually two rectangles) appear at the bottom left of the viewer

Fixed, thanks.

Reiterating a bug from a page or two ago: selections on this grid visually appear to be a pixel higher than they should be.

It's on the list.

Currently the tilt slider has a minimum value of 0. Would it be possible to make the tilt slider be able to go into the negatives, in which case the screen would tilt in the opposite direction?

Yes, done. Also hotkey @ will reset Tilt to 0.

Selections/paste/advance still appear to ignore grid tilting, as does drawing, the "what cell is currently under the cursor" functionality and related things.

Known and not a priority.

And is there any way in which I can help to improve the performance of LifeViewer? Performance seems to be getting considerably worse lately, which is probably more on Apple than anything else but I've recently upgraded to a much more modern device (Air 4th generation) and am therefore considerably more displeased with them for the poor FPS I seem to be getting lately. I also have several more devices on which I can perform tests if a diverse set of samples would be of any use.

From LifeViewer's side performance hasn't changed - in fact in some cases it's slightly improved. So it's likely to be the wonders of Safari. I have no easy way to test or debug this since the only Apple device I own is an iPhone.
Something that might be helpful is try LifeViewer on other browsers on your Apple device to see if it is indeed a Safari issue or not.

[muzik]

Could dead zones be added to the 0 region of the tilt slider, as well as all 45 degree increments of the angle slider, to make these exact values easier to manually select?

Also, could another tilt slider be added that tilts the viewer in the opposite axis to the current one?

And I'm not sure if this is intended, but pasting every n amount of generations does not appear to work for negative values of n:

Code: Select all

x = 10, y = 5, rule = Critters
#C [[ RLE input o$bo$bo$o! ]]
#C [[ PASTET EVERY 32 ]]
#C [[ PASTE input -11 0 ]]
#C [[ ZOOM 8 ]]
$bo$2bo6bo$2bo6bo$bo!

Code: Select all

x = 10, y = 5, rule = Critters
#C [[ RLE input o$bo$bo$o! ]]
#C [[ PASTET EVERY 32 ]]
#C [[ PASTE input -11 0 ]]
#C [[ ZOOM 8 ]]
#C [[ REVERSESTART ]]
$bo$2bo6bo$2bo6bo$bo!

[rowett]

Could dead zones be added to the 0 region of the tilt slider, as well as all 45 degree increments of the angle slider, to make these exact values easier to manually select?

I'll investigate the tilt request. No to the angle slider.

Also, could another tilt slider be added that tilts the viewer in the opposite axis to the current one?

No.

And I'm not sure if this is intended, but pasting every n amount of generations does not appear to work for negative values of n

Yes this is intentional.

[muzik]

Select All counts cells that have died for RHistory and RSuper rules if the pattern also contains live cells:

Code: Select all

x = 22, y = 11, rule = B3/S23
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo11bo$2b2o3b2o9bobo$2bo4b2o10bobo$6obo
11bo$2bob6o$2bo4bo$7bo!
[[ STARTFROM 2 ]]

Code: Select all

x = 22, y = 11, rule = B3/S23History
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo11bo$2b2o3b2o9bobo$2bo4b2o10bobo$6obo
11bo$2bob6o$2bo4bo$7bo!
[[ STARTFROM 2 ]]

Code: Select all

x = 22, y = 11, rule = B3/S23Super
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo11bo$2b2o3b2o9bobo$2bo4b2o10bobo$6obo
11bo$2bob6o$2bo4bo$7bo!
[[ STARTFROM 2 ]]

Code: Select all

x = 22, y = 11, rule = R1,C2,S2-3,B3
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo11bo$2b2o3b2o9bobo$2bo4b2o10bobo$6obo
11bo$2bob6o$2bo4bo$7bo!
[[ STARTFROM 2 ]]

Code: Select all

x = 22, y = 11, rule = 23/3/2
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo11bo$2b2o3b2o9bobo$2bo4b2o10bobo$6obo
11bo$2bob6o$2bo4bo$7bo!
[[ STARTFROM 2 ]]

This does not happen if all of the cells in the pattern are dead.

Code: Select all

x = 11, y = 11, rule = B3/S23
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo$2b2o3b2o$2bo4b2o$6obo$2bob6o$2bo4bo$7b
o!
[[ STARTFROM 2 ]]

Code: Select all

x = 11, y = 11, rule = B3/S23History
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo$2b2o3b2o$2bo4b2o$6obo$2bob6o$2bo4bo$7b
o!
[[ STARTFROM 2 ]]

Code: Select all

x = 11, y = 11, rule = B3/S23Super
3bo$3bo4bo$b6obo$3bob6o$2b2o4bo$2b2o3b2o$2bo4b2o$6obo$2bob6o$2bo4bo$7b
o!
[[ STARTFROM 2 ]]

In addition, manual selections containing the dead cells can be shrunk in RHistory and RSuper, but cannot in normal 2-state rules.

[rowett]

Select All counts cells that have died for RHistory and RSuper rules if the pattern also contains live cells:

True. History cells have a state in [R]History and [R]Super rules but they don't for 2-state rules since the latter only has... 2 states.

Select All does not select cells if the pattern is dead (has no live cells). However if you wish you can manually select history cells in [R]History or [R]Super. You can't in 2-state rules since the history cells don't exist on the grid as above.

[muzik]

Would it be possible to have BSFKL and Extended Generations patterns be validated and decoded like how Larger than Life patterns were from 2017-18? Currently, visiting the pattern pages for these on Catagolue results in the viewer undesirably returning an error:

https://catagolue.hatsya.com/object/xq4 ... 34567l0346
https://catagolue.hatsya.com/object/xp1 ... 78d2-3-1-1

The viewer in these cases is not an expandable thumbnail viewer even though it should be, the pattern is not displayed at all inside the viewer, the viewer is far wider than it should be which makes the page look awkward, and the default golly theme is used which clashes with how Catagolue should look.

If LifeViewer were to simply understand the rulestrings as part of a new rulespace, even if the runtime for the rulespace is incomplete, the pattern would still be viewable and there would be no ugly errors.

[rowett]

Could dead zones be added to the 0 region of the tilt slider,

Yes, done.

[rowett]

Would it be possible to have BSFKL and Extended Generations patterns be validated and decoded like how Larger than Life patterns were from 2017-18?

No. However I have improved LifeViewer's handling of invalid rules. This should fix several of the cosmetic issues on Catalogue. Note I believe Catagolue only updates LifeViewer once a day so you may need to wait until tomorrow to see the improvements (look for build 743).

[muzik]

In both cases these are Margolus patterns. Because of the alternating grid the Margolus Identify only looks at every other generation, so odd Mods are not detected.

In that case shouldn't the rotating oscillator at least have a mod of half its period be detected, since it occurs on an even generation?

[rowett]

In that case shouldn't the rotating oscillator at least have a mod of half its period be detected, since it occurs on an even generation?

Actually it makes more sense to disable Mod output for these rules since it won’t be accurate.

[muzik]

In that case shouldn't the rotating oscillator at least have a mod of half its period be detected, since it occurs on an even generation?

Actually it makes more sense to disable Mod
output for these rules since it won’t be accurate.

I'd much prefer it if it were kept, but a notice was put in place stating that Identify is flawed for Margolus rules, since it usually does produce useful information. An asterisk after the mod output which would show the disclaimer when moused over would be good enough.

[rowett]

I'd much prefer it if it were kept, but a notice was put in place stating that Identify is flawed for Margolus rules, since it usually does produce useful information. An asterisk after the mod output which would show the disclaimer when moused over would be good enough.

I meant just for Margolus and other alternating rules. I'll keep it for rules where it's valid.

[GUYTU6J]

What is the command that creates a random state-1 pattern in a certain Generations/HROT rule? I see the random 2-state fill button but forget its scripting equivalent.

---

What HROT neighbourhoods do ND, NF, NG, NW stand for respectively? They are not recorded here.

[rowett]

What is the command that creates a random state-1 pattern in a certain Generations/HROT rule? I see the random 2-state fill button but forget its scripting equivalent.

[[ RANDOMIZE2 ]]

What HROT neighbourhoods do ND, NF, NG, NW stand for respectively? They are not recorded here.

ND - Aligned Checkerboard (added to here)

NF - Far Corners/Edges

• rule R parameter sets the default range for Corners and Edges
• override R by specifying C<number> and/or E<number>
• example: FarCorners rule would be: R2,C2,S2-3,B3,NFE1 (i.e. corners 2, edges 1)

NG - Gaussian details

NW - Weighted details