Pattern viewer for forum threads

[muzik]

What exactly is "Temperature", and should it ever be able to output values exceeding 1?

Temperature

The temperature of an oscillator is the average percentage

Right, so it's a percentage. I assume that the following pattern's rotor temperature of 7.94 (i.e. 794%) is incorrect then? (The heat seems excessively high as well, given only eight cells are changing.)

Code: Select all

x = 10, y = 10, rule = B12345678/S012345678History:T10
10A$10A$9AF$10A$10A$10A$10A$10A$10A$10A!

----

In Help > Identify as well as the period map legend, could "State6" and "St.6" be renamed to "Off DF" (for "off deathforcer")? "State 6" could mean anything, since any given rule or rule table could define state 6 to be something completely different. I think that communicating the behaviour of these cells in a similarly short acronym would be far better.

While we're at it, low-period oscillators containing these cells will have their name escape the period map legend slightly:

Code: Select all

x = 3, y = 4, rule = LifeHistory
.2A$.A$.2F!
[[ COLOR UIBACKGROUND DeepSkyBlue ]]

I also think it would be a good idea to rename state 6 in [R]Super as well. Currently its name is "boundary", which is problematic since LifeViewer already defines "boundary" to be the regions outside of unbounded grids. Having these two things share a name (and default color, for that matter) causes unneccessary confusion. I've done a quick search of the forums and haven't seen anyone changing the color of the boundary state in [R]Super patterns yet, so it's probably safe to change to something else (again, preferably "off deathforcer").

----

For the following two patterns on square Klein bottles, if we use Save Pattern, the first's bounded grid definition stays as is, but the second's becomes "K20*". I find this behaviour to be problematic: Klein bottles are the only supported type of bounded grid where the two axes will always have different behaviour by definition (planes, tori and cross surfaces always have the same two types of boundary, and spheres must be square at all times), so collapsing down one of these definitions to a single number and having the other remain unchanged doesn't make sense to me.

Code: Select all

x = 3, y = 3, rule = B3/S23:K20,20*
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:K20*,20
o$obo$2o!

[muzik]

There's a few other mod oddities for rule table and natively supported 2-state rules.

The spaceship's mod is not recognised here:

Code: Select all

x = 2, y = 3, rule = B2ac/S:T0,13
bo2$2o!
#C [[ GRID ]]

Code: Select all

x = 2, y = 3, rule = RuleB2AC:T0,13
bo2$2o!
#C [[ GRID ]]
@RULE RuleB2AC
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect
1,0,0,0,0,0,0,0,0,0
1,1,0,0,0,0,0,0,0,0
1,1,1,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,0,0,0
1,1,1,1,1,1,1,1,0,0
1,1,1,1,1,1,1,1,1,0
0,1,1,0,0,0,0,0,0,1
0,0,1,0,1,0,0,0,0,1

In the following example, the top is recognised as a spaceship (with the wrong speed and opposite direction) but the bottom is recognised as an oscillator, despite the patterns behaving the same:

Code: Select all

x = 3, y = 8, rule = B2ac/S:T0,13
bo2$2o3$bo2$b2o!

Code: Select all

x = 3, y = 8, rule = RuleB2AC:T0,13
bo2$2o3$bo2$b2o!
#C [[ GRID ]]
@RULE RuleB2AC
@TABLE
n_states:2
neighborhood:Moore
symmetries:rotate4reflect
1,0,0,0,0,0,0,0,0,0
1,1,0,0,0,0,0,0,0,0
1,1,1,0,0,0,0,0,0,0
1,1,1,1,0,0,0,0,0,0
1,1,1,1,1,0,0,0,0,0
1,1,1,1,1,1,0,0,0,0
1,1,1,1,1,1,1,0,0,0
1,1,1,1,1,1,1,1,0,0
1,1,1,1,1,1,1,1,1,0
0,1,1,0,0,0,0,0,0,1
0,0,1,0,1,0,0,0,0,1

----

The wrong error seems to be displayed for the second code box: the issue that the cell state is unsupported, not the rule.

Code: Select all

x = 1, y = 1, rule = NotEnoughStates
A!
#C [[ GRID ]]
@RULE NotEnoughStates
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute

Code: Select all

x = 1, y = 1, rule = NotEnoughStates
B!
#C [[ GRID ]]
@RULE NotEnoughStates
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute

----

The following patterns, seemingly all Rot180, don't have their mod recognised:

Code: Select all

x = 5, y = 5, rule = extendedlife
4.C$4.F$2.F.A$F.A$C!

Code: Select all

x = 20, y = 25, rule = extendedlife
14.2A$14.2A$8.FA$8.2A$4.F4$19.E5$8.A$7.A.A$6.A3.A$E5.A3.A$6.A3.A$7.A.
A$8.A$15.F$10.2A$10.AF$4.2A$4.2A!

Code: Select all

x = 6, y = 10, rule = extendedlife
2.2F$4.A2$5.C$.A.A$2.2A$C.A2$2.2A$2.2F!

Code: Select all

x = 7, y = 11, rule = extendedlife
2.2F$4.A3$.A.A2.C$2.2A$C.A3$3.2A$3.2F!

Code: Select all

x = 14, y = 14, rule = extendedlife
2.C5.C2$5.E$13.C$2.A5.A$.2A5.2A$2.A5.A4$C$8.E2$5.C5.C!

Code: Select all

x = 29, y = 16, rule = extendedlife
10.E3$6.3A3.3A7.C$6.A.A3.A.A3.E$6.3A3.3A$27.AF$27.AF$FA$FA2$10.E$6.C
3$18.E!

Code: Select all

x = 38, y = 31, rule = extendedlife
9.E3$16.E5$35.A2$.C.2F28.A.D.A$3.2A$30.A4.A$20.C10.A$9.E19.3A2$27.E$
16.C2$3A29.2A$ADA29.2F.C$3A6$20.E3$27.E!

----

Layers are handled inconsistently across themes where there are no distinct AGESTATES cells. Compare the following two patterns - it'd be expected the central cell stays the same but in one it rises and in the other it does not:

Code: Select all

x = 3, y = 1, rule = B3/S23
3o!
[[ AUTOSTART THEME Inverse LAYERS 10 X 5 Y 5 ]]

Code: Select all

x = 3, y = 1, rule = B3/S23
3o!
[[ AUTOSTART THEME Book LAYERS 10 X 5 Y 5 ]]

Also, in the first pattern below, the background is white, but in the second it darkens.

Code: Select all

x = 4, y = 4, rule = 23/3/2
2o$o$3bo$2b2o!
[[ THEME Inverse LAYERS 2 ]]

Code: Select all

x = 4, y = 4, rule = 23/3/3
2o$o$3bo$2b2o!
[[ THEME Inverse LAYERS 2 ]]

[rowett]

I assume that the following pattern's rotor temperature of 7.94 (i.e. 794%) is incorrect then?

Indeed. It's because births and deaths are not computed for patterns in Bounded Grids and so Heat and Temperature are incorrect.

I've disabled Heat and Temperature in the results for Bounded Grid patterns.

In Help > Identify as well as the period map legend, could "State6" and "St.6" be renamed to "Off DF" (for "off deathforcer")? "State 6" could mean anything, since any given rule or rule table could define state 6 to be something completely different. I think that communicating the behaviour of these cells in a similarly short acronym would be far better.

No. This is specific to [R]History and [R]Super patterns where state 6 is well understood and documented.

While we're at it, low-period oscillators containing these cells will have their name escape the period map legend slightly

Fixed, thanks.

I also think it would be a good idea to rename state 6 in [R]Super as well.

I didn't name it in the first place so I'm not the one to make that decision.

For the following two patterns on square Klein bottles, if we use Save Pattern, the first's bounded grid definition stays as is, but the second's becomes "K20*". I find this behaviour to be problematic

Agreed, fixed.

[rowett]

There's a few other mod oddities for rule table and natively supported 2-state rules.

These are all related to Bounded Grids with an infinte dimension. It's likely that I'll disable spaceship search for these cases.

The following patterns, seemingly all Rot180, don't have their mod recognised

Fixed, thanks.

[muzik]

Another bounded-grids-with-zeros case: if the side that does not have a twist is set to 0, the pattern is still considered invalid. I don't think it should be - the twisted edge is infinitely far away from the pattern and so can never be encountered, which means that the grid would just work the same as an infinite cylinder (T0,10). The first one should still be considered Invalid.

Code: Select all

x = 3, y = 3, rule = B3/S23:K0*,10
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:K0,10*
o$obo$2o!

Here's some finite cases for comparison, where 0 is replaced with 50. In the first one, the long edge is flipped. In the second one, the short edge is flipped, so before we reach it it acts identically to a torus. When we change 50 to 0, that edge is at infinity and therefore will never matter.

Code: Select all

x = 3, y = 3, rule = B3/S23:K50*,10
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23:K50,10*
o$obo$2o!

----

This spaceship dies when trying to cross this boundary:

Code: Select all

x = 5, y = 6, rule = B3/S23:K20*+5,20
2b3o$bo2bo$4bo$o3bo$4bo$bobo!

It also, like many other spaceships on bounded grids, gives incorrect results when we try to identify it, but that's not relevant.

----

If we move the mouse over "boundary" cells which are also outside of a bounded grid, "[bounded]" is displayed instead of "[boundary]".

Code: Select all

x = 9, y = 5, rule = B3/S23:P10
$bo3b3o$b3o2bo$2bo!
[[ MAXGRIDSIZE 9 X -250 ]]

----

If "Save Pattern" is used when a selection is present, can "Selection Saved" be displayed instead of "Saved"? There's been many times where I've accidentally saved the contents of a selection instead of the entire pattern and lost that pattern as a result, so a visual prompt to remind me it's a selection should help to mitigate that.

Also: if an empty pattern is saved, the bounding box size in the RLE is given as 1x1, but the lack of any "o" or "b" cells before the exclamation mark mean it'd actually be 0x0. This might be intentional but I'd prefer to ask.

[Book]

I apologize if this has already been raised. Looks like you cannot LOOP a pattern that dies in gen 0, e.g. Dot. Any workaround?

[rowett]

Another bounded-grids-with-zeros case: if the side that does not have a twist is set to 0, the pattern is still considered invalid. I don't think it should be - the twisted edge is infinitely far away from the pattern and so can never be encountered, which means that the grid would just work the same as an infinite cylinder (T0,10).

I don't like this since it's not intuitive. If you want an infinite cylinder specify one.

This spaceship dies when trying to cross this boundary

Fixed, thanks.

If we move the mouse over "boundary" cells which are also outside of a bounded grid, "[bounded]" is displayed instead of "[boundary]".

Fixed, thanks.

If "Save Pattern" is used when a selection is present, can "Selection Saved" be displayed instead of "Saved"?

Yes, done.

[rowett]

I apologize if this has already been raised. Looks like you cannot LOOP a pattern that dies in gen 0, e.g. Dot. Any workaround?

Fixed, thanks. LifeViewer will now not pause when all cells die if LOOP is enabled.

[muzik]

Why is this pattern rejected as invalid even though the previous shifted Klein bottle example is accepted (and is now handled fine)?:

Code: Select all

x = 6, y = 5, rule = B3/S23:K20*,20+5
2bo$o3bo$5bo$o4bo$b5o!

I also think that cells outside of bounded grids which are beyond the cells that mark the edges of the bounded grid, but before the actual "boundary" cells, should be displayed as something along the lines of "[out of bounds]", or possibly "[background]". They're not boundary cells, so one of these two other names would make more sense.

Also, this pattern automatically pauses at generation 6. It should not: automatic pausing without explicit script commands for pausing/stopping a pattern should only happen when a pattern that once had alive cells ends up being in a state of having no alive cells (with edge cases such as LOOP or pending paste commands ignoring this pause). Since alive cells never exist in the following pattern, pausing should not happen without user input.

If we step to T=1 and then play it, we get "Life ended at generation 6", which, due to the lack of any alive cells at any point, is unwanted as well.

Code: Select all

x = 7, y = 7, rule = 23/3/4
7C$7C$7C$7C$7C$7C$7C!
[[ GPS 2 PASTET 5 PASTE 7B$7B$7B$7B$7B$7B$7B! 0 0 ]]

Can the normal (no selection present) message for Save Pattern be changed from "Saved" to "Pattern Saved"?

[rowett]

Why is this pattern rejected as invalid even though the previous shifted Klein bottle example is accepted (and is now handled fine)?:

See the bounded grid documentation. Golly rejects this pattern also.

Can the normal (no selection present) message for Save Pattern be changed from "Saved" to "Pattern Saved"?

Yes, done.

[rowett]

Identify now considers all cells when identifying patterns in Bounded Grids.

This means that the first pattern has a different Mod symmetry than the second and also that the Bounding Box reported is the Bounded Grid size.

Code: Select all

x=3,y=1,rule=B3/S23:T5
3o!

Code: Select all

x=3,y=1,rule=B3/S23:T6
3o!

Additionally, Identify is not supported on Bounded Grids with an infinite dimension.

[muzik]

Could the edges of bounded grids be visually marked on the oscillator period map with their own color?

Code: Select all

x = 3, y = 3, rule = B3/S23:S20
5bo$5bobo$5b2o!

Among other things such as making it easier to see where connections are, this would make it clear why the generated period maps for things like the following are seemingly unnecessarily large.

Code: Select all

x = 7, y = 17, rule = B3/S23:P20,20
13$5b2o$6bo$3bo$3b2o!

For bounded grids, calling things like the glider above "Oscillator" doesn't seem right since we're technically dealing with an infinite pattern. Could the header text be changed to just "Period 160", or "Periodic with period 160", if the grid is bounded?

[rowett]

Could the edges of bounded grids be visually marked on the oscillator period map with their own color?

Yes, done.

For bounded grids, calling things like the glider above "Oscillator" doesn't seem right since we're technically dealing with an infinite pattern.

I prefer it as is: the Bounded Grid is an Oscillator or Still Life.

[muzik]

There appears to be an issue with selections when used in unloaded tiles: for the second pattern, if we try to make a selection in the in-bounds region, no selection visually renders and it renders as out-of-bounds when we release the mouse. Afterwards, the selection appears incredibly visually offset if we zoom all the way out and try to figure out what's going on. I was also previously able to encounter a bug in which selections wouldn't happen if outside of loaded tiles and would be made at the limit of loaded tiles, which is probably related to this.

Code: Select all

x = 1, y = 1, rule = B3/S23
o!
[[ MAXGRIDSIZE 14 X -8192 Y -8192 ]]

Code: Select all

x = 1, y = 1, rule = R1,C2,S2-3,B3
o!
[[ MAXGRIDSIZE 14 X -8192 Y -8192 ]]

Using Select All while in the glitched state may cause several buttons to disappear, strangely including the "reverse playback" button for some reason. This glitched state appears to carry on into other viewers to some extent.

Here's a bounded grid parity issue with Golly: in Golly, if we click to start drawing cells inside of the bounded grid, then, while still holding down the mouse, drag the cursor outside of the bounded grid, cells will continue to be drawn at the very edge of the bounded grid. In LifeViewer, nothing ends up being drawn. Can this functionality be changed in LifeViewer to match Golly? The ability to easily draw straight lines in such a manner is something I find very convenient.

Code: Select all

x = 4, y = 4, rule = B3/S23:T30,30
4o$o2bo$o2bo$4o!

Low-priority feature request: would it be possible to natively support the old "Historical Life" rule from 2001? We'd just need three states: the background state, the alive state, and the historical trail state (as well as all of the internal states for visual fading). It'd differ from [R]History due to there being no marked states or deathforcer cells and would also differ from standard 2-state rules since in Historical Life you'd be able to draw with the historical cells and manipulate said cells with selections.

And another low-priority feature request: could the cells that mark the bounded grid be added to the period map legend as well?

[rowett]

for the second pattern, if we try to make a selection in the in-bounds region, no selection visually renders and it renders as out-of-bounds when we release the mouse

I can't reproduce this. Selecting in the in-bounds region works identically for both patterns for me. Which device are you using?

Low-priority feature request: would it be possible to natively support the old "Historical Life" rule from 2001?

No. It's a lot of work for little gain and realistically it'll never make it to the top of the backlog.

And another low-priority feature request: could the cells that mark the bounded grid be added to the period map legend as well?

No. It adds no useful information.

[muzik]

for the second pattern, if we try to make a selection in the in-bounds region, no selection visually renders and it renders as out-of-bounds when we release the mouse

I can't reproduce this. Selecting in the in-bounds region works identically for both patterns for me. Which device are you using?

I checked this on PC, and can't seem to reproduce it there either, so it's probably another one of those mobile-exclusive memory issues (iPad Air 4th gen).

----

The fourth pattern causes a non canonical, invalid bounded grid notation to be produced if we use Save Pattern:

Code: Select all

x = 9, y = 9, rule = B3/S23:K20,20*+1
b2o2bob2o$o2bo2b2o$bobo$2bo$8bo$6b3o$5bo$6bo$7b2o!

Code: Select all

x = 9, y = 9, rule = B3/S23:K20,20*-1
b2o2bob2o$o2bo2b2o$bobo$2bo$8bo$6b3o$5bo$6bo$7b2o!

Code: Select all

x = 9, y = 9, rule = B3/S23:K20*+1,20
b2o2bob2o$o2bo2b2o$bobo$2bo$8bo$6b3o$5bo$6bo$7b2o!

Code: Select all

x = 9, y = 9, rule = B3/S23:K20*-1,20
b2o2bob2o$o2bo2b2o$bobo$2bo$8bo$6b3o$5bo$6bo$7b2o!

The custom theme defined for the following patterns will show all of the cells that died in that generation in red. For cells that die as a result of natural evolution, via deathforcer cells or via KILLGLIDERS, the amount of red cells that can be seen will always match the number given for "Deaths", but for those killed by the boundary, not enough of them will be displayed and the "Deaths" counter will almost always be higher. I think that there might be some dead cells that don't get displayed when patterns hit the boundary and remain in the background color, at least for the range-1 algorithm.

Code: Select all

x = 14, y = 18, rule = B3/S23
b2o6bo$b2o6bobo$9b2o14$2o10b2o$2o10b2o!
[[ COLOR ALIVE 255 255 128 COLOR ALIVERAMP 255 255 128 HISTORYSTATES 2 COLOR BACKGROUND 0 0 0 COLOR DEAD 192 0 0 COLOR DEADRAMP 0 0 0 SHOWGENSTATS KILLGLIDERS ]]

Code: Select all

x = 13, y = 4, rule = LifeHistory
9.A2.A$8.A$8.A3.A$F7.4A!
[[ COLOR ALIVE 255 255 128 COLOR ALIVERAMP 255 255 128 HISTORYSTATES 2 COLOR BACKGROUND 0 0 0 COLOR DEAD 192 0 0 COLOR DEADRAMP 0 0 0 SHOWGENSTATS ]]

Code: Select all

x = 7, y = 4, rule = B3/S23
b2o$2ob4o$b6o$2b4o!
[[ COLOR ALIVE 255 255 128 COLOR ALIVERAMP 255 255 128 HISTORYSTATES 2 COLOR BACKGROUND 0 0 0 COLOR DEAD 192 0 0 COLOR DEADRAMP 0 0 0 SHOWGENSTATS MAXGRIDSIZE 9 X -256 STARTFROM 500 GRID GPS 2 ZOOM 16 ]]

[rowett]

The fourth pattern causes a non canonical, invalid bounded grid notation to be produced if we use Save Pattern

Fixed, thanks.

for those killed by the boundary, not enough of them will be displayed and the "Deaths" counter will almost always be higher

Fixed, thanks.

[muzik]

For bounded grids, it turns out that AUTOFIT also causes them to become discentered, and that it isn't solely a first load issue. Is it known?

Code: Select all

x = 2, y = 2, rule = B3/S23:T6
2o$2o!
[[ GRID AUTOFIT ]]

I'm not sure if this is intended, but CXRLE doesn't appear to be able to offset Margolus patterns by an odd number of cells:

Code: Select all

x = 2, y = 2, rule = MargSingRot:T6
2o$2o!
[[ GRID AUTOFIT ]]

Code: Select all

#CXRLE Pos=-1,-1
x = 2, y = 2, rule = MargSingRot:T6
2o$2o!
[[ GRID AUTOFIT ]]

Code: Select all

#CXRLE Pos=-1,-2
x = 2, y = 2, rule = MargSingRot:T6
2o$2o!
[[ GRID AUTOFIT ]]

Code: Select all

#CXRLE Pos=-2,-1
x = 2, y = 2, rule = MargSingRot:T6
2o$2o!
[[ GRID AUTOFIT ]]

Code: Select all

#CXRLE Pos=-2,-2
x = 2, y = 2, rule = MargSingRot:T6
2o$2o!
[[ GRID AUTOFIT ]]

KILLGLIDERS does not work on bounded grids. I think it should be disabled, as since the grid is bounded there is no concept of an "escaping glider" (and is why we no longer identify spaceships on them).

Code: Select all

x = 3, y = 3, rule = B3/S23:C30,30
o$obo$2o!
[[ KILLGLIDERS ]]

Code: Select all

x = 12, y = 8, rule = B3/S23:C30,30
o$obo$2o3$11bo$9bobo$10b2o!
[[ KILLGLIDERS ]]

If we apply a shift of +0 or -0 to a cross surface, the pattern is rejected, despite the fact that shifting it by 0 does nothing.

Code: Select all

x = 2, y = 2, rule = B3/S23:C20,10+0
2o$2o!

Code: Select all

x = 2, y = 2, rule = B3/S23:C20+0,10
2o$2o!

Code: Select all

x = 2, y = 2, rule = B3/S23:C20+0,10+0
2o$2o!

I think they should be accepted and the shifts discarded, since the following patterns also have shifts of 0 and are processed as expected:

Code: Select all

x = 2, y = 2, rule = B3/S23:K20*,10+0
2o$2o!

Code: Select all

x = 2, y = 2, rule = B3/S23:K20*+0,10+0
2o$2o!

Code: Select all

x = 2, y = 2, rule = B3/S23:K20*+1,10-0
2o$2o!

Also, if we save a pattern with a -1 Klein bottle shift, it gets saved as -1, which is inconsistent with Golly which changes it to +1. I'm not sure if parity with Golly is to be expected here.

Code: Select all

x = 2, y = 2, rule = B3/S23:K20*-1,10
2o$2o!

[rowett]

For bounded grids, it turns out that AUTOFIT also causes them to become discentered

Fixed, thanks.

KILLGLIDERS does not work on bounded grids. I think it should be disabled, as since the grid is bounded there is no concept of an "escaping glider" (and is why we no longer identify spaceships on them).

Disabled, thanks.

If we apply a shift of +0 or -0 to a cross surface, the pattern is rejected, despite the fact that shifting it by 0 does nothing.

Cross-surface does not support a shift so the behaviour is correct.

Also, if we save a pattern with a -1 Klein bottle shift, it gets saved as -1, which is inconsistent with Golly which changes it to +1. I'm not sure if parity with Golly is to be expected here.

Fixed, thanks. Yes, parity with Golly is a good goal.

[muzik]

It's not possible to see stars through the cell borders effect when using a hexagonal or triangular grid, even though you can see it when using a square grid. Try moving around on these - for the square grid, stars are clear to see if you get the right position, but on the other two they are entirely occluded even when they should not be.

Code: Select all

#C [[ ZOOM 4 CELLBORDERS STARS ]]
x = 80, y = 80, rule = B/S012345678
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o!

Code: Select all

#C [[ ZOOM 4 CELLBORDERS STARS ]]
x = 80, y = 80, rule = B/S0123456H
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o!

Code: Select all

#C [[ ZOOM 4 CELLBORDERS STARS ]]
x = 80, y = 80, rule = B/S0123456789XYZL
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o
$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$80o$
80o$80o$80o$80o$80o$80o$80o$80o$80o$80o!

This pattern appears to lose mirror symmetry as it evolves, which should not happen (it doesn't in Golly). It can be first seen at T=20.

Code: Select all

x = 20, y = 10, rule = B3/S23:K20*+1,10
5bo$5bo$5bo$5bo7bo$5bo7bo$5bo7bo$5bo7bo$5bo$5bo$5bo!

A random idea I had a while ago: would it be possible to visually indicate which bounded grid edges are what? All of them are currently rendered the same, but I think it'd be helpful if for example twisted boundaries were given a slightly different color from non-twisted boundaries, so that it'd be immediately obvious which two sides of a Klein bottle are twisted and which two aren't. Or for spheres, two of the sides that are connected to each other could be given one color and the other two could be given a second color so you know which direction the pole goes in.

Also, another low priority feature request: would it be possible to make the triangular grid's bounded grid edges look nicer? Currently it's just a direct conversion of the square cells to the triangular grid, but this causes sharp edges which I don't think look particularly nice. Some extra cells could be added to make a more robust, less jagged looking boundary.

Current appearence:

Code: Select all

x = 20, y = 20, rule = B/S0123456789XYZL
20o$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo
$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$o18bo$20o!

How they could look:

Code: Select all

x = 23, y = 20, rule = B/S0123456789XYZL
b21o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b
2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o$b2o18b2o
$b2o18b2o$b2o18b2o$b2o18b2o$b21o!

[muzik]

It seems like the antialiasing applied to hexagonal and triangular cells is just generally a bit too extreme, resulting in a visible green halo for these examples which is absent for square cells:

Code: Select all

x = 1, y = 1, rule = B/S0
o!
[[ ZOOM 4 THEME Yellow CELLBORDERS ]]

Code: Select all

x = 1, y = 1, rule = B/S0H
o!
[[ ZOOM 4 THEME Yellow CELLBORDERS ]]

Code: Select all

x = 1, y = 1, rule = B/S0L
o!
[[ ZOOM 4 THEME Yellow CELLBORDERS ]]

The second pattern should probably be accepted as valid, since the edge which is shifted is infinitely far away from the center and therefore has no effect, meaning that it should just be handled as "T0,10".

Code: Select all

x = 5, y = 4, rule = B3/S23:T50,10+5
bo2bo$o$o3bo$4o!

Code: Select all

x = 5, y = 4, rule = B3/S23:T0,10+5
bo2bo$o$o3bo$4o!

Could error messages for invalid bounded grid definitions be made to be more specific about what is invalid?

In Help > Info > Identify, could "Bounded" be moved to somewhere above "Grid"? It's a cell type, so it should be grouped with other cell types. Preferably, it would be placed either directly above or directly below Back.

Code: Select all

x = 4, y = 2, rule = LifeHistory:P4,2
F2A$F.A!

Could a count of state 6 cells also be displayed in the table of periods in Identify? Having it in Help > Info > Identify is good, but it'd also be beneficial to have it in the table since it's more convenient to access.

I also noticed that in the Grid help section, the maximum grid size is still 8192x8192 by default, even though bounded grids can never expand beyond what is specified. Would there be any performance benefit for automatically downscaling the maximum grid size to the smallest possible value that accommodates the bounded grid?

I'm not sure if the PASTE behaviour shown here is correct. The RLE that gets pasted does not contain alive cells, but alive cells are generated as a result of the pasting. In addition, historical dead cells are replaced with background cells.

Code: Select all

x = 18, y = 7, rule = 8//6
18A$18A$18A$18A$18A$18A$18A!
[[ GPS 4 RLE addition 4.2B$4.2B$4.2B$4.2B$10B$10B$4.2B$4.2B$4.2B$4.2B! PASTET 6 PASTE addition 0 0 ]]

Code: Select all

x = 18, y = 7, rule = R1,C6,S8,B
18A$18A$18A$18A$18A$18A$18A!
[[ GPS 4 RLE addition 4.2B$4.2B$4.2B$4.2B$10B$10B$4.2B$4.2B$4.2B$4.2B! PASTET 6 PASTE addition 0 0 ]]

This pattern appears to be behaving wrong. There seems to be a chaotic, immortal wick of some sort spanning the origin and causing eternal chaos.

Code: Select all

x = 17, y = 16, rule = B3/S23:C50,0
obo3bobobo3bo$bo3bo3bo3b4o$b3obo2bob2o2bobo$4o3bobo5b2o$2b2obo3bob2ob
3o$o3b2ob3o2b2o$ob2obo2bob3o2bo$4obo2b5ob3o$o2b7o$2obobobob2obobobo$2o
bob3ob2o3bobo$2bobob2o2b2obo2bo$4bo6b2o3bo$obo2b4ob3o3bo$b7obo3bobo$o
4bob2o2bo2bo!

Code: Select all

x = 4, y = 5, rule = B3/S23:C50,0
3o$3bo$3bo$3bo$3o!

Patterns on partially bounded grids do not appear to be centered correctly, neither when loading the pattern nor when using AUTOFIT.

Code: Select all

x = 9, y = 10, rule = B3/S23:T0,10
8bo$o2bo2b3o$4bo3bo$6b3o$ob2obo2bo$2bo3b3o$ob2obo2bo$6b3o$4bo3bo$o2bo
2b3o!

Finally, will Identify support ever return for partially bounded grids? I found it useful for identifying wicks and waves like the above pattern.

[rowett]

It seems like the antialiasing applied to hexagonal and triangular cells is just generally a bit too extreme, resulting in a visible green halo for these examples which is absent for square cells

Any antialiasing is done by the browser.

The second pattern should probably be accepted as valid

No. I don't want to add anything that doesn't work in Golly.

In Help > Info > Identify, could "Bounded" be moved to somewhere above "Grid"?

Yes, done.

Could a count of state 6 cells also be displayed in the table of periods in Identify?

No. I don't like it because it's a different data type than the rest of the table.

I also noticed that in the Grid help section, the maximum grid size is still 8192x8192 by default, even though bounded grids can never expand beyond what is specified. Would there be any performance benefit for automatically downscaling the maximum grid size to the smallest possible value that accommodates the bounded grid?

No.

Finally, will Identify support ever return for partially bounded grids? I found it useful for identifying wicks and waves like the above pattern.

Unlikely. It creates too many edge cases.

[rowett]

in Golly, if we click to start drawing cells inside of the bounded grid, then, while still holding down the mouse, drag the cursor outside of the bounded grid, cells will continue to be drawn at the very edge of the bounded grid. In LifeViewer, nothing ends up being drawn. Can this functionality be changed in LifeViewer to match Golly?

Yes, done.

[muzik]

The "Life ended at" message ignores starting generations specified by CXRLE. However, it accepts reversible generations. This seems inconsistent to me.

Code: Select all

#CXRLE Gen=-200
x = 8, y = 3, rule = B3/S23
bo$6b2o$3o3b2o!

Code: Select all

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

Could it be made to either accept CXRLE generations as well, or only count the number of elapsed generations, being rephrased to something along the lines of "Life ended after n generations"?

----

There's also still a few [R]Super boundary kill edge cases. For the other trail states, the wrong trail color is used:

Code: Select all

x = 5, y = 4, rule = B3/S23Super
.I2.I$I$I3.I$4I!
[[ MAXGRIDSIZE 9 X -250 STARTFROM 500 ]]

Code: Select all

x = 5, y = 4, rule = B3/S23Super
.K2.K$K$K3.K$4K!
[[ MAXGRIDSIZE 9 X -250 STARTFROM 500 ]]

No-trail states produce trails when hitting the boundary even though they should produce nothing at all:

Code: Select all

x = 5, y = 4, rule = B3/S23Super
.M2.M$M$M3.M$4M!
[[ MAXGRIDSIZE 9 X -250 STARTFROM 500 ]]

And stationary marked states (4 and 8) are replaced with dead trail states instead of remaining as they are.

----

This still evolves different in Golly, again diverging at generation 20. The dot sparks at the far left in generation 20 do not appear in Golly.

Code: Select all

x = 20, y = 10, rule = B3/S23:K20*+1,10
5bo$5bo$5bo$5bo7bo$5bo7bo$5bo7bo$5bo7bo$5bo$5bo$5bo!

[rowett]

The "Life ended at" message ignores starting generations specified by CXRLE.

Fixed, thanks.

There's also still a few [R]Super boundary kill edge cases.

Fixed, thanks.

This still evolves different in Golly, again diverging at generation 20.

That's because I haven't published a fix yet.