Suggested LifeWiki edits

[Sokwe]

“Every finite phoenix evolves into an oscillator”

But the domino and dot do not do this?

According to the wiki

A phoenix is a pattern all of whose cells die in every generation, but that never dies as a whole.

Since the domino and dot reach population 0, they do not qualify under this definition.

[DroneBetter]

as shown in User:DroneBetter/userspace rule pages#Spaceship_Search_Status_Page-style_pages, there are a few pages alike the LifeWiki:Spaceship Search Status Page for other rules, of which 2×2, HighLife, Day & Night, LeapLife and (in User:DroneBetter/qfind results) the sqrt replicator rule, Flock, HighFlock, Pedestrian Flock and Holstein have pages. Should these status pages be moved from their respective userspaces to subpages of their subject rules? (I have contributed mainly to my own userspace ones and 2×2 as of late, and have been treating the edit logs themselves as sufficient citation, and including longest partials for selected results in the footnotes, neither of which are done in the mainspace Life one)

also, I added an option for one to specify style=raw in {{LinkForumThread}}, to allow the appending of " (discussion thread) at the ConwayLife.com forums" to be omitted like {{LinkCatagolue}}, and currently used it in the 2×2 and qfind results pages, in order to add descriptions of what they contain (since the usual "Re:" titles are not very helpful), should this be employed on the mainspace? The default appendiing is not very useful when repeated many dozens of times in very long pages and looks somewhat ugly, perhaps forum citations could be separated off from others in their own subsection with "ConwayLife.com forums" as the header? (the current consensus seems to be to have them appear in order of invocation, not chronology, so it wouldn't violate any existing conventions)

[confocaloid]

[...] Also: you should've quote me.

[...] Should these status pages be moved from their respective userspaces to subpages of their subject rules? [...]

Only if the initial contributor(s) explicitly agree to the idea. Some userpages may not be up-to-date. Some userpages may go against formatting/style guidelines. Some userpages were not intended to be moved into mainspace to begin with.

No matter what is the current state of the page, it should be the decision of the initial contributor(s) whether or not the page can be moved.

(I have contributed mainly to my own userspace ones and 2×2 as of late, and have been treating the edit logs themselves as sufficient citation, and including longest partials for selected results in the footnotes, neither of which are done in the mainspace Life one)

Edit logs don't provide a sufficient citation for a page, either in the main namespace or in the OCA namespace. A citation should lead to a place that is external to the wiki page. E.g. that might be a webpage, a book, an external article, a forum post.

also, I added an option for one to specify style=raw in {{LinkForumThread}}, to allow the appending of " (discussion thread) at the ConwayLife.com forums" to be omitted like {{LinkCatagolue}}, and currently used it in the 2×2 and qfind results pages, in order to add descriptions of what they contain (since the usual "Re:" titles are not very helpful), should this be employed on the mainspace? The default appendiing is not very useful when repeated many dozens of times in very long pages and looks somewhat ugly, perhaps forum citations could be separated off from others in their own subsection with "ConwayLife.com forums" as the header? (the current consensus seems to be to have them appear in order of invocation, not chronology, so it wouldn't violate any existing conventions)

I don't have an issue with repeating similar titles in footnotes. As long as the link leads from a footnote to the correct source (which does support the claims made on the wiki), and as long as the footnote text doesn't somehow mislead or misrepresent the source, any consistent formatting should work fine.

Adding new values for template parameters or adding new template parameters usually creates more problems with consistency (and/or maintainability of the resulting template infrastructure) than it could solve. Hence my preference would be to avoid using the newly added "style=raw" and remove it from the template.

If it is desirable to have a different formatting for some situations, then I think there should be a discussion opened here in the "LifeWiki Discussion" subforum, with a detailed outline of what is suggested, and when exactly the new formatting would be used (vs. when the old formatting would be used). If that discussion reaches some consensus, perhaps the end result could be a separate dedicated template (as opposed to overloading an existing template with too many special cases).

[wwei47]

Is it time to move the 754P7 page to 563P7? I have a draft in my namespace ready to go.

[hotdogPi]

I would support a move.

[Haycat2009]

Nah. It is a reduction. For the same reason 51P384 was not moved to 49P384, I do not support it.

[Sokwe]

Is it time to move the 754P7 page to 563P7? I have a draft in my namespace ready to go.

I support the move, as the 563-cell form is currently the most notable form.

Nah. It is a reduction.

The page was moved once before after a reduction. Another example is 54P23, which was moved from 55P23.

For the same reason 51P384 was not moved to 49P384, I do not support it.

51P384 was moved to 49P384 (by C28, without discussion) but then moved back (by Confocal, without discussion). I don't think that case should be used as precedent.

[hotcrystal0]

Is it time to move the 754P7 page to 563P7? I have a draft in my namespace ready to go.

I support the move, as the 563-cell form is currently the most notable form.

When 678P7 was found, the 754P7 page was not moved to 678P7, so I disagree with the move.

[wwei47]

Is it time to move the 754P7 page to 563P7? I have a draft in my namespace ready to go.

I support the move, as the 563-cell form is currently the most notable form.

When 678P7 was found, the 754P7 page was not moved to 678P7, so I disagree with the move.

This feels ambiguous; it could also be argued that the page was moved from 1320P7 to 1308P7 and from 1308P7 to 754P7, meaning that it should be moved a second (EDIT: 3rd) time.

EDIT 2: Correction: The page was moved directly from 1320P7 to 754P7. This would actually be the second move.

[dvgrn]

I support the move, as the 563-cell form is currently the most notable form.
...
51P384 was moved to 49P384 (by C28, without discussion) but then moved back (by Confocal, without discussion). I don't think that case should be used as precedent.

It does seem like we have a good number of precedents where a page was moved to document a reduced and now-more-notable form. Maybe there are just as many cases where a page was not moved, and the new form was documented in the gallery section instead. Not sure about the relative counts of moved vs. not-moved. Pretty clearly there are a good number of examples in both categories.

That being the case, it seems to me that arguing from precedent just plain isn't a useful way to decide this issue. How about looking at what form of the article will best document ... whatever people might want to know?

I'm somewhat convinced by the idea that it works well to have the article be about the current most notable / most used form of the pattern. If there's a variant that everyone would use for new constructions if they knew about it, and if someone is willing to do the work to make the article be about that variant, then what's wrong with having the article document that variant, with previous variants shown and documented in the gallery section?

Before we have the same arguments all over again, I'd suggest that anyone who wants to discuss this might want to read through this previous discussion on the 54P23 move that Sokwe mentioned, starting with confocaloid's statement of the "don't-move" case, and I think ending with Sokwe's ideas about when a move is warranted.

(Side note, the "heavyweight volcano" article is still stuck saying that it was discovered by Dean Hickerson; there wasn't any more discussion about whether it should be changed to say that Scot Ellison discovered that form of the sparker in 2007. I think maybe it should be changed -- the history with Dean Hickerson's original 1995 variant will still be plainly visible at the top of the gallery.)

[wwei47]

Unrelated but is this P5 toad worth adding to the toad reaction page? It trades clearance for size compared to the one on the page.

Code: Select all

x = 17, y = 15, rule = B3/S23
11bo$10bobo$10bobo$8b2obob2o$8bo2bobo$9bobobo$8b2obobob2o$7bo2b2obo2b
o$b2o5bo5bo$bobo5b5o$3bo$ob2o5b2ob2o$2o8bobo$10bobo$11bo!

[confocaloid]

https://conwaylife.com/w/index.php?titl ... did=141528
In the oscillator 94P48, I do not see a phase where the hassled reaction would consist of some instances of I-heptomino. Can anyone double-check whether or not the oscillator is a I-heptomino hassler (as claimed in the text added in the linked edit)?

Code: Select all

x = 28, y = 20, rule = B3/S23
9b2o$10bo$b2o7bobo12b2o$obo8b2o12bobo$obob2o16b2obobo$bobobo11b2o3bob
obo$3bo12b2o6bo$2b2o13bo3bo2b2o$b3o17bo2b3o$b3o20b3o$b3o20b3o$b3o2bo17b
3o$2b2o2bo3bo13b2o$3bo6b2o12bo$bobobo3b2o11bobobo$obob2o16b2obobo$obo
12b2o8bobo$b2o12bobo7b2o$17bo$17b2o!

[Bullet51]

The Eater 4 page states:

Examples of its use include the pre-pulsar hassler in p29 pentadecathlon hassler, the p30 honey farm hassler shown below

but there is no Eater 4 in the p30 honey farm hassler contained in the page.

The same problem arises on P30 honey farm hasslers. The problem could be caused by the original p30 honey farm hassler (dimer, containing an Eater 4) being replaced by the monomerized version (without an Eater 4).

[confocaloid]

The Eater 4 page states:

Examples of its use include the pre-pulsar hassler in p29 pentadecathlon hassler, the p30 honey farm hassler shown below

but there is no Eater 4 in the p30 honey farm hassler contained in the page.

The same problem arises on P30 honey farm hasslers. The problem could be caused by the original p30 honey farm hassler (dimer, containing an Eater 4) being replaced by the monomerized version (without an Eater 4).

Both pages use the file RLE:p30honeyfarmhassler1 (the "Eater 4" page uses it since May 2022, and the "Period-30 honey farm hasslers" page uses it since November 2022 when it was split from "Honey farm hasslers#p30").

The file was changed in March 2024 ( https://conwaylife.com/w/index.php?diff ... did=105066 ), which led to the problem. The old version is the following:

Code: Select all

x = 29, y = 22, rule = B3/S23
17b2o$17bobo$19bo$15b4ob2o$15bo2bobobo$20bobo$20bo2b2o$4bo14b2o4bo$4ob
o15b5o$3obobo14bo4b2o$5bobo16b2o2bo$6bo18bob2o$5b2o7b2ob3o5bo$5b2o7b2o
8b2o$5b2o4$18b2o$18bo$19b3o$21bo!

Note that there are no other uses of the same file (Special:WhatLinksHere/RLE:p30honeyfarmhassler1), which means the straightforward way to solve the problem is to restore the older revision of the file.
If one needs to have the reduced version shown somewhere on the wiki, that would involve more than one edit, and it would make sense to have the reduced version in a different file (instead of changing an existing file already used in some contexts).

[Vort]

Filter page states that "A filter is an oscillator used to delete some but not all of the spaceships in a stream", but when I tried to delete gliders from the stream with P10 filter, the only outcome was destruction of filter.
Maybe it is better to replace pattern from wiki with slightly modified one, which does not collide with the stream?

Code: Select all

x = 46, y = 48, rule = LifeHistory
13.2A4.2A$13.A.A2.A.A$15.A2BA$13.BA4BAB$13.BA4BAB$14.A4BA$8.2A6.2A$9.
A6.B$9.A.AB2.2B$7.2A.2AB.3B2A$8.A3.7BA3B16.2A$6.A.A3.5B2ABA4B6.A2.A4.
A$5.A.A.2A.8BA5B5.4A5.A$5.A.A.A.A.8BA3BAB8.2A2.2A$3.2A2.A.2AB5.2B2A5B
2A2.A.2A.A.A3.2A$2.A4.2A2B7.4B3.2A2B.2A.ABA.2A.A2.A$3.4A.2B16.4B4.BA
2B3.3A$3A3.AB2.A16.4B3.2AB4A$A2.3A2B.A.A16.11B.A.2A$3.A.AB.A.A18.3BA
2B.A2BAB.A.A$4.AB3.A20.3BA3.2A2B.A.A$31.3AB3.B2.2A.2A5$13.2A4.2A$13.A
.A2.A.A$15.A2BA$13.BA4BAB$13.BA4BAB$14.A4BA$8.2A6.2A$9.A6.B$9.A.AB2.
2B$7.2A.2AB.3B2A14.2A$8.A3.7BA3B10.A5.2A$6.A.A3.5B2ABA4B9.A4.A$5.A.A.
2A.8BA5B5.4A5.A$5.A.A.A.A.8BA3BAB3.A4.2A2.2A$3.2A2.A.2AB5.2B2A5B2A3.
3A.A.A3.2A$2.A4.2A2B7.4B3.2A2B4.ABA.2A.A2.A$3.4A.2B16.4B4.BA2B3.3A$3A
3.AB2.A16.4B3.2AB4A$A2.3A2B.A.A16.11B.A.2A$3.A.AB.A.A18.3BA2B.A2BAB.A
.A$4.AB3.A20.3BA3.2A2B.A.A$31.3AB3.B2.2A.2A!

EDIT by dvgrn: Done (52P10 instead of 51P10). It looks like the insufficient-clearance version has been in there since the sparker page was created. The caption says "This is not its only use". I don't know offhand what the other uses are -- is there maybe a reason to document them on a 51P10 page?

[hotdogPi]

I was probably thinking of this p20 R-pentomino hassler when I write that it wasn't its only use.

Code: Select all

x = 24, y = 18, rule = B3/S23
8b2o$8b2o4$9b2o$8b2o9b2ob2o$2b2o5bo5b2o3bobo$bobo11b2o3bobo$bo13bo2bob
2o$2o11bob4o$12b2o5b3o$8b2obobob2obo2bo$8bob2obobo3b2o$13b2o2b2o$9b4o
5bo$9bo2bo4bo$17b2o!

[Vort]

(Maybe this is more more question than suggestion, but I don't know where else to put it anyway)
If I understand correctly, many sparkers with even periods can be used as filters.
So to what extent Filter article should be expanded?
For example, should Jason's p22 be added to "List of filters" section?
I optimized several guns with its help, so its usefulness as period doubler has been proven not only theoretically, but also practically.

[unname4798]

Please, remove User:Unname4798/common.js

[wwei47]

https://conwaylife.com/wiki/Period-24_l ... k_hasslers Can't we just replace two of the molds with ships?

Code: Select all

x = 66, y = 41, rule = B3/S23
58b2o$58bobo$60bo$53b2o4b2ob2obo$53bobo3bo2bob2o$42b2o12bo3bo$41bobo
10bo3bob2o$6b2o33b2o3bo7bo3b4o$5bobo23b2o12b3o6b3obo$5bo14b2o9bo12bobo
bo5b2o3bobo$ob2ob2o4b2o6bo2bo9b3o8b3ob3o4b3obo$2obo2bo3bobo6bobo2bo2b
2o5bo9bobobo5bo3b4o$5bo3bo10bo7bo16b3o6bo3bob2o$4b2obo3bo9b2obo3bobo
15bo9bo3bo$4b4o3bo11bo5b2o4b2o16bobo3bo2bob2o$7bob3o6bo15bobo11bo4b2o
4b2ob2obo$4bobo3b2o5bo2bo13bobo10bobo10bo$7bob3o4b3ob3o11b2o11bobo10bo
$4b4o3bo5bobobo26bo4b2o4b2ob2obo$4b2obo3bo6b3o32bobo3bo2bob2o$5bo3bo9b
o26bo9bo3bo$2obo2bo3bobo32b3o6bo3bob2o$ob2ob2o4b2o4bo26bobobo5bo3b4o$
5bo10bobo11b2o11b3ob3o4b3obo$5bo10bobo10bobo13bo2bo5b2o3bobo$ob2ob2o4b
2o4bo11bobo15bo6b3obo$2obo2bo3bobo16b2o4b2o5bo11bo3b4o$5bo3bo9bo15bobo
3bob2o9bo3bob2o$4b2obo3bo6b3o16bo7bo10bo3bo$4b4o3bo5bobobo9bo5b2o2bo2b
obo6bobo3bo2bob2o$7bob3o4b3ob3o8b3o9bo2bo6b2o4b2ob2obo$4bobo3b2o5bobob
o12bo9b2o14bo$7bob3o6b3o12b2o23bobo$4b4o3bo7bo3b2o33b2o$4b2obo3bo10bob
o$5bo3bo12b2o$2obo2bo3bobo$ob2ob2o4b2o$5bo$5bobo$6b2o!

[PHPBB12345]

Add double beehive push catalyst to beehive push catalyst page

Code: Select all

x = 17, y = 13, rule = B3/S23
4bo3bo3bo$3bobobobobobo$2bo2bobobobo2bo$2b3o2bobo2b3o$7bobo$2b5o3b5o$
bo13bo$2b3o7b3o$4bo7bo$2b2o4bo4b2o$2bo4bobo4bo$obo4bobo4bobo$2o6bo6b2o
!

[confocaloid]

The edit https://conwaylife.com/w/index.php?diff ... did=132033 looks like an attempt to combine two different pieces of information in a single sentence. (Note that the dart was previously compared with the turtle in that sentence, and that they are both bilaterally symmetric, but in two different ways.) I suggest to move the added information into a separate sentence.

EDIT by dvgrn: Done (here).

[Vort]

I think it is important to mention that timing of trombone slide can be adjusted by +5 mod 8 by replacing Snark with Snark64.
Less important detail: adding two Bandersnatches (+4 mod 8 ) allows full mod 8 range to be tuned.
However, I don't know how exactly trombone slide article should be modified.

[confocaloid]

I think it is important to mention that timing of trombone slide can be adjusted by +5 mod 8 by replacing Snark with Snark64.
Less important detail: adding two Bandersnatches (+4 mod 8 ) allows full mod 8 range to be tuned.
However, I don't know how exactly trombone slide article should be modified.

There are also some other possibilities involving a colour-preserving glider shifter:

Code: Select all

x = 29, y = 32, rule = B3/S23
2bobo16b2o$3b2o16b2o$3bo11b2o$14bobo2b4o$14bobobo4bo$15bobobobobo$17b
obob2o4b2o$16bobo8bo$17bo7bobo$2bo22b2o$bobo$o2bo$2ob2o$bo4bo$o2b4o5b
2ob2o$b2o9b2ob2o$3b2o$3bo$4bo$b3o$bo4$8b2o$8bo2bob2o$9b3obobo$13bobo2b
o$11b3ob4o$10bo3bo$10b2o2bobo$15b2o!

Code: Select all

x = 26, y = 46, rule = B3/S23
16b2obo$12b2obo2b2o$12bo3bo$14b2ob2obo$6b2o2b4obobob2o$6bo2bobo$7bobo$
8bobo9b2o$9bo4b2o4bo$14b2o6bo$18b5o$18bo$21b2o$21bo$19bobo$19b2o$25bo$
23b3o$22bo$22b2o$2o$2o$12bo$13bo$11b3o3$12b2o$12b2o14$16b2o$17bo$14b3o
$14bo!

Inserting one or more of these in some sequence/orientation allows to fine-tune the timing and the geometry of the glider track.

[iddi01]

I noticed that there's literally a 1.5 month gap in the news. I think it's impossible for this community to not have a notable discovery for so long. Can anyone fill in the gap?

[rattlesnake]

https://conwaylife.com/patterns/eater2variant2.rle and https://conwaylife.com/patterns/eater2variant2.cells look like:

Code: Select all

#C [[ GRID VIEWONLY ]]
x = 5, y = 10, rule = B3/S23
2o$bo$bo$2ob2o$3b2o2$2ob2o$bobo$bobo$2bo!

It should be

Code: Select all

#C [[ GRID VIEWONLY ]]
x = 5, y = 9, rule = B3/S23
2o$bo$bob2o$2ob2o2$2ob2o$bobo$bobo$2bo!

EDIT by dvgrn: Fixed (and then re-fixed, since the above is a still life but not an eater2 variant, as PHPBB12345 and confocaloid point out below).