Pattern viewer for forum threads

[rowett]

Flip⟋orRot180 oscillators appear to be misidentified as Flip⟍orRot180

Fixed, thanks.

These two once again don't seem to be giving a mod of 1 like they used to.

Fixed, thanks.

Shouldn't the following two patterns evolve identically? For a plane, all cells outside are treated as dead. For an emulated B0/S8 rule, the roles of alive and dead are swapped, meaning everything outside of a plane would technically be alive and cause births into the grid.

This is an existential question about whether there are cells outside a finite plane. If so, how should they be treated, and if not, how should the cells in the plane adjacent to the border be treated.

LifeViewer sees this as indeterminate, and so as not to discover any dead cats doesn't look.

I hope that's cleared it up.

[muzik]

Shouldn't the following two patterns evolve identically? For a plane, all cells outside are treated as dead. For an emulated B0/S8 rule, the roles of alive and dead are swapped, meaning everything outside of a plane would technically be alive and cause births into the grid.

This is an existential question about whether there are cells outside a finite plane. If so, how should they be treated, and if not, how should the cells in the plane adjacent to the border be treated.

LifeViewer sees this as indeterminate, and so as not to discover any dead cats doesn't look.

I hope that's cleared it up.

I assume this also applies to the previously reported case where state-6 cells weren't technically "killing" surrounding cells in AntiLife and other B0/Smax rules?

These two once again don't seem to be giving a mod of 1 like they used to.

Fixed, thanks.

They appear to be reported as FlipDiag now, but only one flip can be valid at a time for a 2D spaceship.

[rowett]

I assume this also applies to the previously reported case where state-6 cells weren't technically "killing" surrounding cells in AntiLife and other B0/Smax rules?

Yes

They appear to be reported as FlipDiag now, but only one flip can be valid at a time for a 2D spaceship.

Fixed again, thanks.

[muzik]

Should patterns that die out still pause playback themselves if there is a STOP command scheduled for execution after the pattern dies? I know that there were recent changes to allow for LOOP commands to still work and override automatic pausing, so it feels like the same logic should apply for STOP (and possibly some other commands).

Code: Select all

x = 3, y = 5, rule = B3/S23
3o$bo$bo$bo$3o!
[[ ZOOM 8 AUTOSTART STOP 100 ]]

Code: Select all

x = 3, y = 5, rule = B3/S23
3o$bo$bo$bo$3o!
[[ ZOOM 8 AUTOSTART LOOP 100 ]]

Also, on the topic of B0 handling, a low-priority question: could Margolus rules with n0 = 15 and n15 = 15 be supported/emulated? To my understanding, these are functionally equivalent to B0/Smax rules, so it'd be sufficient to find the inverse rule and just run with that instead. No alternation would be needed as there would be no strobing.

It also doesn't appear to be possible to draw to the left of this cell. I assume this is a result of the fix for the cells-near-the-edge crash issue, but this seems extreme for low ranges since from my testing the bug never happened there. The normal range-1 algorithm is unaffected.

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B
!
[[ MAXGRIDSIZE 9 RLE cell o! PASTET 0 PASTE cell -192 0 ]]

Code: Select all

x = 1, y = 1, rule = B/S
!
[[ MAXGRIDSIZE 9 RLE cell o! PASTET 0 PASTE cell -192 0 ]]

Command pasting doesn't work outside of this range either, and if we play a pattern where this is attempted it pauses at T=1:

Code: Select all

x = 1, y = 1, rule = R1,C2,S,B
!
[[ MAXGRIDSIZE 9 RLE cell o! PASTET 0 PASTE cell -193 0 ]]

Is it intended that we still can't Identify patterns consisting solely of deathforcer cells? There may be no living cells, but such configurations still have a valid bounding box and such since they're now counted as "integral" cells.

Code: Select all

x = 5, y = 2, rule = LifeHistory
2A.2F$2A.2F!

Code: Select all

x = 2, y = 2, rule = LifeHistory
2F$2F!

Could we get some more contrast with the Identify period map colors - maybe by making the darkening modulo 4 or modulo 3 instead of 2? (For example: normal brightness, medially darkened, slightly darkened, very darkened, and then back to normal brightness again. The current system is normal brightness, medially darkened, then back to normal brightness.) In the following pattern, the two large adjacent blue and purple regions are slightly tricky to tell apart, as are two of the smaller light green regions to the left.

Code: Select all

x = 48, y = 1, rule = MAPAAD//zAwPz8AAP//MDA/PwAA//8AAP//AAD//wAA//8AAD8/AAD//wAAPz8AAP//wMD//wAA///AwP//AAD//w
48o!
[[ Y 24 ]]

If we Select All and then Cut/Copy this configuration, and then paste it, the paste preview seems very misshapen. The actually pasted pattern is still correct.

Code: Select all

x = 8, y = 5, rule = B/S0123LE
$b7o$2b5o$3b3o$4bo!

And finally, are hexagonal/triangular selection shapes a necessary prerequisite for the implementation of rotating selections by 60 or 120 degrees and Mod being calculated on these grids? I've been thinking about this for a while but don't know enough about how Identify works behind the scenes to really know. To my understanding, the idea of such selection shapes would require a redefinition of what a "bounding box" is on these grids.

[muzik]

KILLGLIDERS seems to work different for the following otherwise functionally identical patterns

KILLGLIDERS is only supported for standard 2-state patterns. I've disabled it in the next build for other rules types (including 2-state HROT).

The button appears to be toggleable again for unsupported rulespaces, although it doesn't actually attempt to kill gliders like it did previously:

Code: Select all

x = 3, y = 3, rule = R1,C2,S2-3,B3
o$obo$2o!

[rowett]

Should patterns that die out still pause playback themselves if there is a STOP command scheduled for execution after the pattern dies?

Yes, it's only LOOP that needs an exemption.

Also, on the topic of B0 handling, a low-priority question: could Margolus rules with n0 = 15 and n15 = 15 be supported/emulated?

No plans at the moment. If someone provides the mapping I might take a look.

It also doesn't appear to be possible to draw to the left of this cell.

Fixed, thanks.

Is it intended that we still can't Identify patterns consisting solely of deathforcer cells?

Yes, there's no value in it.

Could we get some more contrast with the Identify period map colors - maybe by making the darkening modulo 4 or modulo 3 instead of 2?

Yes, done.

If we Select All and then Cut/Copy this configuration, and then paste it, the paste preview seems very misshapen. The actually pasted pattern is still correct.

Fixed, thanks.

And finally, are hexagonal/triangular selection shapes a necessary prerequisite for the implementation of rotating selections by 60 or 120 degrees and Mod being calculated on these grids?

Yes to both.

[rowett]

The button appears to be toggleable again for unsupported rulespaces, although it doesn't actually attempt to kill gliders like it did previously:

Fixed, thanks.

[muzik]

A minor pattern fitting quirk: the first pattern will smoothly zoom in if we press "Auto" at the top left. The second will immediately zoom in to the maximum level (but the zoom bar up at the top will still animate smoothly).

Code: Select all

x = 1, y = 1, rule = B/S012345678
o!
[[ ZOOM 1 ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
o!
[[ STEP 2 ]]
[[ ZOOM 1 T 0 "Press Auto at top left" ]]

Another two:
- If we advance these patterns by one generation, causing them to die at T=1, and then press either the AutoFit or Fit Pattern buttons at the top left, the square and triangular grid patterns will correctly zoom into the area where the cell used to be. However, the hexagonal grid pattern will zoom into a region very far to the left of the initial cell.
- If, instead of causing these patterns to die by advancing one generation, we do so by using Identify on them, and then use "AutoFit" or "Fit Pattern", LifeViewer will zoom very far out instead of in.

Code: Select all

x = 1, y = 1, rule = B/S
o!

Code: Select all

x = 1, y = 1, rule = B/SH
o!

Code: Select all

x = 1, y = 1, rule = B/SL
o!

On the topic of Identify and fitting dead patterns, if a pattern dies out while being checked by Identify, could it be made to fit the entire envelope of the pattern to the screen such that the end result of identifying a pattern that dies out is the same as running it with AUTOFIT and HISTORYFIT enabled?

Code: Select all

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

Code: Select all

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

Finally, is it intended that when fitting the pattern without HISTORYFIT that the viewer zooms/focuses on the regions where the last alive cells existed?

----

The new period map colors are definitely a considerable improvement for distinguishing the aforementioned regions. I'd recommend making the "darkest" shades slightly brighter as they blend into the background a bit too much in some cases, but otherwise it looks great so far.

[rowett]

A minor pattern fitting quirk: the first pattern will smoothly zoom in if we press "Auto" at the top left. The second will immediately zoom in to the maximum level (but the zoom bar up at the top will still animate smoothly).

Fixed, thanks.

Note: AutoFit now disables user Pan and Zoom when enabled.

If we advance these patterns by one generation, causing them to die at T=1, and then press either the AutoFit or Fit Pattern buttons at the top left, the square and triangular grid patterns will correctly zoom into the area where the cell used to be. However, the hexagonal grid pattern will zoom into a region very far to the left of the initial cell.
If, instead of causing these patterns to die by advancing one generation, we do so by using Identify on them, and then use "AutoFit" or "Fit Pattern", LifeViewer will zoom very far out instead of in.

Fixed, thanks.

On the topic of Identify and fitting dead patterns, if a pattern dies out while being checked by Identify, could it be made to fit the entire envelope of the pattern to the screen such that the end result of identifying a pattern that dies out is the same as running it with AUTOFIT and HISTORYFIT enabled?

No.

The new period map colors are definitely a considerable improvement for distinguishing the aforementioned regions. I'd recommend making the "darkest" shades slightly brighter as they blend into the background a bit too much in some cases, but otherwise it looks great so far.

I've adjusted them a little. After several experiments I think it's about as good as it's going to get now.

[muzik]

KILLGLIDERS can still replace marked cells with normal trail cells if those marked cells came from mark2:

Code: Select all

x = 21, y = 21, rule = LifeHistory
3.2A$3.2A12.A$17.A.A$17.2A7$2.C2.C2.C$2.C2.C2.C$11C$2.7C$2.7C$11C$2.7C
10.2A$2.7C10.2A$11C$2.C2.C2.C$2.C2.C2.C!
[[ KILLGLIDERS ]]

Code: Select all

x = 21, y = 21, rule = LifeHistory
3.2A$3.2A12.A$17.A.A$17.2A7$2.E2.E2.E$2.E2.E2.E$11E$2.7E$2.7E$11E$2.7E
10.2A$2.7E10.2A$11E$2.E2.E2.E$2.E2.E2.E!
[[ KILLGLIDERS ]]

Could Rainbow be enabled for [R]History? From what I remember from a couple of months ago it worked just about perfectly (likely due to [R]History's engine and rendering being pretty much the same as that of [R]Standard), with the only issue being that states 3-6 had their colors changed when they shouldn't.

Inverting selections doesn't seem to work right in [R]Super for the following example. It works as expected for [R]History (dead becomes alive, alive becomes dead), but for [R]Super we get the hidden state as well as no-trail alive cells. I'd expect [R]Super to behave identically to [R]History here.

Code: Select all

x = 21, y = 21, rule = LifeHistory
3.2A$3.2A15$19.2A$19.2A!
[[ COLOR BACKGROUND Gray ]]

Code: Select all

x = 21, y = 21, rule = LifeSuper
3.2A$3.2A15$19.2A$19.2A!
[[ COLOR BACKGROUND Gray ]]

If no rule name is specified, patterns with Niemiec states default to LifeHistory instead of Life according to the T menu, when saving patterns and so on. Is this intended? Since the default rule is Life (and Life patterns which are not explicitly declared as [R]History in the RLE will still use the history player as discussed earlier if Niemiec cells are detected) I'm not sure which rule it should "use".

Code: Select all

100x$200o!

There are also some weird things I've noticed when trying to run patterns containing Niemiec cells using the input box at the viewer page https://lazyslug.com/lifeview/plugin/viewer.html:

- A single o works as expected: one alive cell.
- A single b works as expected: one dead cell.
- A single y works as expected: one mark2 cell.
- A single z will result in an empty pattern which is maximally zoomed out. According to this post the pattern should probably not be empty since it explicitly mentions a "z state". In addition, it starting at max zoom out shouldn't happen either - it should be at the default zoom level for a pattern with only one cell.
- A single x will put the viewer into a glitched state where it will not update until you tap on it/mouse over it. The pattern inside of the viewer will generally be the last one you loaded.

[muzik]

How are Heat and Temperature intended to work for multistate rule tables? For patterns like the following, we get 0 across the board.

Code: Select all

x = 23, y = 23, rule = WireWorld
9.A4C$6.2CB5.3C$4.2C11.2C$3.C15.C$2.C17.C$2.C17.C$.C19.C$.C19.C$.C19.
C$C21.C$C21.C$C21.C$C21.C$C21.C$.C19.C$.C19.C$.C19.C$2.C17.C$2.C17.C$
3.C15.C$4.2C11.2C$6.3C5.3C$9.5C!

I assume this is due to it only counting cases where a state 0 cell changes to a non-state 0 cell, and non-state 0 cells becoming state 0, and ignoring any changes from a non-state 0 cell to a different non-0 state. The wiki page on temperature describes it as the "average percentage of active cells that change state per generation", so I'd expect that (for rule tables) all state changes would be counted when performing temperature and heat calculations. I could be wrong, though, since it doesn't explicitly state that this should remain the case for rules with higher state counts. So it might mean that for ruletables with 3 states or higher, Heat and Temperature will be removed (in this case, it should be kept for 2-state rules since it works fine there).

----

Speaking of Identify: could identified oscillators be made to have LifeViewer fit their total bounding box to the view (including all active cells, but ignoring any distant fading junk not produced by the oscillator's normal evolution)?

Code: Select all

x = 33, y = 10, rule = R2,C6,M0,S2..3,B3..3,NN
30.A.A2$30.A.A2$11.4A$11.ACEB$11.2A2E$A.A8.2AE$12.D2E$A.A!

[rowett]

KILLGLIDERS can still replace marked cells with normal trail cells if those marked cells came from mark2:

Fixed, thanks.

Could Rainbow be enabled for [R]History?

No.

Inverting selections doesn't seem to work right in [R]Super for the following example.

There's a backlog item to review the edit operations for the different rule types.

If no rule name is specified, patterns with Niemiec states default to LifeHistory instead of Life.

There's a backlog item for Niemec support too (include earlier reports around saving patterns).

There are also some weird things I've noticed when trying to run patterns containing Niemiec cells using the input box at the viewer page https://lazyslug.com/lifeview/plugin/viewer.html

A single z will result in an empty pattern which is maximally zoomed out.

The Niemiec "z" state is no longer supported since there's no unique [R]History state to map it to.

A single x will put the viewer into a glitched state where it will not update until you tap on it/mouse over it.

Fixed, thanks.

[rowett]

How are Heat and Temperature intended to work for multistate rule tables?

They are not intended to work. I've hidden them in the results.

Speaking of Identify: could identified oscillators be made to have LifeViewer fit their total bounding box to the view (including all active cells, but ignoring any distant fading junk not produced by the oscillator's normal evolution)?

No.

[muzik]

How are Heat and Temperature intended to work for multistate rule tables?

They are not intended to work. I've hidden them in the results.

From my testing beforehand, heat worked just fine for PCA: this oscillator gave a heat of 2, which makes sense since one cell dies per generation and one cell is born per generation. There are four active cells in total, and dividing 2 by 4 gives 0.5, which was the result produced by build 971. Build 972 appears to have removed heat and temperature for the PCA rulespace. Could it be returned (since PCA rules are 2-state rules using a 16-state implementation)?

Code: Select all

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

They also appear to have been removed from [R]Super (although not [R]History).

Code: Select all

x = 3, y = 1, rule = LifeSuper
3o!

I don't know if heat and temperature should be returned to Generations rules: they have a clear distinction between "alive" states and "not alive" states, so heat could be defined based on cells becoming alive and stopping being alive, ignoring dying cell transitions.

[muzik]

There are also some weird things I've noticed when trying to run patterns containing Niemiec cells using the input box at the viewer page https://lazyslug.com/lifeview/plugin/viewer.html

A single z will result in an empty pattern which is maximally zoomed out.

The Niemiec "z" state is no longer supported since there's no unique [R]History state to map it to.

It did work for [R]Super though: the "z" state was converted to the state-7 "marked on no-trail" state. However, this would only happen when defining the rule as an [R]Super rule in the RLE itself.

Code: Select all

x = 3, y = 1, rule = B3/S23Super
xyz!

As of build 972, the z state is no longer accepted even if the RLE is explicitly defined to be an [R]Super pattern.

Having the prior functionality of state z returned (it becomes state 7 in [R]Super) is something I'd probably prefer, as well as having the presence of z in the RLE change the rule used to [R]Super instead of [R]History as to preserve compatibility with Niemiec's patterns and give z its own unique state. This is your decision, however.

There is a minor oddity that has arrived with z being unsupported, however: running this pattern in viewer.html (it won't work in the forums due to SHOW PATTERN ERROR) will display a "New Pattern" message, which is atypical for invalid pattern errors.

Code: Select all

x = 1, y = 1, rule = B3/S23Super
z!

[rowett]

Could it be returned (since PCA rules are 2-state rules using a 16-state implementation)?

They also appear to have been removed from [R]Super (although not [R]History).

Yes, done.

[rowett]

It did work for [R]Super though: the "z" state was converted to the state-7 "marked on no-trail" state.

Niemiec states "x", "y", and "z" are now supported and create [R]Super patterns. When those patterns are saved the states will be converted to regular [R]Super states so as to maintain compatibility with other tools.

[muzik]

I did a bit of thinking about the handling of x, y and z cells and how they're used in practice. Here's one of the patterns from Niemiec's database which uses the x state to display synthesis stages:

Code: Select all

#N 28coelw.rle
#O Mark D. Niemiec's life synthesis database, Thu Feb 19 02:05:31 2015
x = 113, y = 48, rule = B3/S23
41bobo$42boo$42bo3$4bo32bo$4bobo17bxx12boo4boo$3oboo17bxbbx10boo4bobbo
$bbo20bxbx17bobo5bo12b3x4bx$bo22bx19bo5b3o11bxbbxbb3x$49boobo11bx4bxxb
x$49b3o12bx3b4x$50boo12bx5bxx$38boo24bxbbx$39boo24bxx$38bo26bx$66bx$
66bx19$43bobo$5bo38boo$6bo37bo6bo12b3x4bx5bobo4b3o4bo12b3x4bx$4b3o43b
3o11bxbbxbb3x5boo4bobbobb3o11bxbbxbb3x$24bxx18boo3boobo11bx4bxxbx5bo5b
o4boobo11bx4bxxbx$6bo17bxbx17bobobb3o12bx3b4x12bo3b4o12bx3b4x$5boo18bx
14b3obbo4boo12bx5bxx12bo5boo12bx5bxx$5bobo34bo22bxbx17bobo16bxbbx$41bo
37bo25bxx$79boo24bx$78bobo25bx$106bx!

At T=0 everything is clear, but then all of the cells become normal "alive" cells when we play it and stationary marked cells are left behind. Since we're dealing with a pattern that shows an incremental spaceship synthesis, having the marked cells remain stationary doesn't make much sense.

Here's the same pattern after I've swapped out the special states for no-trail alive cells:

Code: Select all

x = 113, y = 48, rule = B3/S23Super
41.A.A$42.2A$42.A3$4.A32.A$4.A.A17.2O12.2A4.2A$3A.2A17.O2.O10.2A4.A2.
A$2.A20.O.O17.A.A5.A12.3O4.O$.A22.O19.A5.3A11.O2.O2.3O$49.2A.A11.O4.2O
.O$49.3A12.O3.4O$50.2A12.O5.2O$38.2A24.O2.O$39.2A24.2O$38.A26.O$66.O$
66.O19$43.A.A$5.A38.2A$6.A37.A6.A12.3O4.O5.A.A4.3A4.A12.3O4.O$4.3A43.
3A11.O2.O2.3O5.2A4.A2.A2.3A11.O2.O2.3O$24.2O18.2A3.2A.A11.O4.2O.O5.A5.
A4.2A.A11.O4.2O.O$6.A17.O.O17.A.A2.3A12.O3.4O12.A3.4A12.O3.4O$5.2A18.
O14.3A2.A4.2A12.O5.2O12.A5.2A12.O5.2O$5.A.A34.A22.O.O17.A.A16.O2.O$41.
A37.A25.2O$79.2A24.O$78.A.A25.O$106.O!

We can still distinguish between the "synthesis step" and "result" copies of the pattern at T=0 like before, but since we're now using a different type of on state this "cell markedness" also carries over to the pattern as we play it. No marked stationary cells are left behind, either.

This change would be beneficial for showcasing syntheses of spaceships since the differentness of the states moves with the spaceships themselves. It's also likely better for oscillator syntheses as well since that way you don't have a bunch of extra, unneccessary colors in one place causing confusion.

"x" cells would map to state 15, "y" cells to state 17 and "z" cells to state 19. (x is 15 rather than 13 as 13, despite also being a no-mark trail, has distinct functionality from the other no-trail cells due to its relationship with states 7 and 8, which is not the case for higher no-trail states.)

I'd assume that this new proposed system would probably be more true to whatever Mark was going for with "distinct" alive cells. Opinions?

[toroidalet]

Certain patterns on Klein bottles don't seem to work properly:

Code: Select all

x = 10, y = 10, rule = B3/S23:K10*+1,10
9$7b3o!

[muzik]

Another old bug that seems to have resurfaced recently: changing the colors of grids correctly sets a custom theme, but the Themes menu still has the custom button locked.

Code: Select all

x = 12, y = 6, rule = B3/S23
o$o8bo$o7b3o$o6b5o$o$o!
[[ GRID COLOR GRID Yellow ]]

Code: Select all

x = 12, y = 6, rule = B3/S23
o$o8bo$o7b3o$o6b5o$o$o!
[[ GRID COLOR GRIDMAJOR Yellow ]]

Also, for this test case from earlier today, there still appear to be minor differences when we click the "Auto" button at the top left: for the first, it zooms in smoothly, but for the second, a keen eye reveals that it immediately zooms in to a higher zoom level than it started out with, and then from that point smoothly zooms in to the target zoom level.

Code: Select all

x = 1, y = 1, rule = B/S012345678
o!
[[ ZOOM 1 ]]

Code: Select all

x = 1, y = 1, rule = B/S012345678
o!
[[ STEP 2 ZOOM 1 T 0 "Press Auto at top left" ]]

Also, why exactly are so many functionalities such as rotating the grid, tilting the grid, drawing, pasting and so on disabled for the none rule? For the square-grid version in particular, I don't see why rotating and tilting should be disabled since every other rule on the square grid permits it (unless there's a pattern error - and even then I don't see why they should be disabled in those situations if we can still zoom and pan). Also, the ability to draw with any of the 256 states is something I'd find very useful for setting up test cases.

Code: Select all

x = 1, y = 1, rule = none
b!
[[ STARTFROM 1 ]]

Code: Select all

x = 1, y = 1, rule = none
o!
[[ STARTFROM 1 ]]

[rowett]

"x" cells would map to state 15, "y" cells to state 17 and "z" cells to state 19.

Done, thanks.

[rowett]

Certain patterns on Klein bottles don't seem to work properly

I still haven't released a fix.

[rowett]

changing the colors of grids correctly sets a custom theme, but the Themes menu still has the custom button locked.

Fixed, thanks.

Also, for this test case from earlier today, there still appear to be minor differences when we click the "Auto" button at the top left

Clearly not a priority.

Also, why exactly are so many functionalities such as rotating the grid, tilting the grid, drawing, pasting and so on disabled for the none rule?

Because the none rule is not interesting. It was added just to allow static images to be displayed. I've got many useful things to be working on.

[muzik]

I assume Kill Gliders support doesn't exist/isn't planned for ruletables? Like with the general-range example from earlier, the button isn't disabled, but pressing it has no effect on the evolution of the pattern:

Code: Select all

x = 3, y = 3, rule = Life-RuleLoader
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = Life-RuleTree
o$obo$2o!

It can also be enabled in [R]Super, where it also still has no effect. I distinctly remember the button being disabled for [R]Super not too long ago, so I'm starting to think that disabling the glider killing functionality on bounded grids might have affected the rulespaces in which it's prohibited.

Code: Select all

x = 3, y = 3, rule = B3/S23Super
A$A.A$2A!

And for PCA, the button is toggleable, but once again has no effect:

Code: Select all

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

It can also be turned on for patterns in the Margolus rulespace, and in this case it can have an effect on objects which assume the shape of the glider in one phase. No rule I know of supports the conventional glider, but this spaceship is eventually killed by it if we turn it on. I assume that the glider killing functionality is designed strictly with the usual glider evolution sequence in mind, and therefore using it in rules that don't support the conventional glider is unsupported by definition (I've seen it killing the rotating glider oscillator from B368/S245, for example)

Code: Select all

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

[rowett]

I assume Kill Gliders support doesn't exist/isn't planned for ruletables? Like with the general-range example from earlier, the button isn't disabled, but pressing it has no effect on the evolution of the pattern

Fixed, thanks.