Reviewing Special:RecentChanges

[dvgrn]

If it is historically interesting, that is enough to put it in a visible place.

Otherwise, one could even avoid having any infobox at all on the page, and instead put all relevant information in plain text with embedded viewers/galleries and explanatory captions. Infoboxes are very limited.

Yup, totally agree.

Re: "historically interesting" and "visible place", I wouldn't have ventured to move 55P23 to 54P23 without also adding an embedded LifeViewer showing the original version.

Re: infoboxes -- they are indeed very limited, and occasionally confusing -- and yet they're also very helpful and unambiguous about 99% of the time, so they're very likely going to be sticking around on the LifeWiki for a long time to come. The trick is going to be finding something more or less reasonable to do about the rare 1% of somewhat confusing cases, without anyone having to worry too much about any specific case.

We can't make the confusion go away -- all options are potentially somewhat confusing, for the heavyweight-volcano case. All we can do is pick which minor confusion we collectively most want to live with.

[confocaloid]

We can't make the confusion go away -- all options are potentially somewhat confusing, for the heavyweight-volcano case. All we can do is pick which minor confusion we collectively most want to live with.

For the heavyweight volcano page, I don't see how the option "show and describe the 1995 pattern in the infobox" is confusing.
I would prefer that, instead of showing one pattern but describing a different pattern.

Another possibility (for the same page) is to discard the infobox, and put all relevant information in the main part of the article, arranged in a reasonable way, with surrounding explanatory text and captions for embedded viewers. Again, that would be objectively less confusing than "show A but describe B".

[hotcrystal0]

55P23

I agree the page and the infobox should stay at "55P23". From the viewpoint of documenting it on LifeWiki, the reduction from 55 cells to 54 cells does not make a new article topic. The oscillator was discovered in 2022 and it is best to show and describe the original version in the infobox, with details about reductions and variants going to the text.

Why I'm posting here is that the apgcode in the embedded viewer and the footnote are missing.
The apgcode in the embedded viewer in section "54P23" should be xp23_02egoy1ca23zy4sgox4acga6zgs26y01y239czy3ey06a8o
The footnote should be added at the end:

Code: Select all

<ref name="post179639">{{LinkForumThread
|format = ref
|p      = 179639
|title  = Re: Oscillator Discussion Thread
|author = Carson Cheng
|date   = March 4, 2024
}}</ref>

Added later: unfortunately later edits by User:Dvgrn ignored the above.

I agree with Confocaloid, but I don't want to get into an edit war with a moderator, so I'm leaving 54P23 as it is unless a resolution ia reached. How about do a poll on where to leave the article?

[confocaloid]

I think a productive answer should be systematic. It's not just about this particular page. Guidelines should be applicable across the wiki.

Infoboxes are really confusing, in several different ways. I think there are many cases when one could do better without an infobox.

[dvgrn]

I think a productive answer should be systematic. It's not just about this particular page. Guidelines should be applicable across the wiki.

Infoboxes are really confusing, in several different ways. I think there are many cases when one could do better without an infobox.

There are definitely "category" articles -- like semi-Snark, for example -- where no one particular pattern is more important than any other, so there's nothing that can lay claim to being "THE semi-Snark".

This "heavyweight volcano" issue might not be one of those cases where taking out the infobox is the best option, though. There are a lot of possible options, and it's not clear that they've all been thought of yet.

- Sokwe's contention is that "The information in the infobox, including discoverer and date, should always match the pattern in the infobox."

- My contention is that when people look up "heavyweight volcano" on the LifeWiki, they should find Scot Ellison's 2007 heavyweight volcano prominently displayed -- because that's what people are generally thinking of these days when they say "heavyweight volcano". They aren't referring to the huge original 1995 discovery -- it's an important historical footnote, but nobody is ever going to be copying that pattern out and using it for anything.

- confocaloid's contention is that Dean Hickerson's original pattern should go in the infobox for the article about Hickerson's heavyweight volcano.

Here's one option that technically satisfies all of these various contentions:

• The "heavyweight volcano" article's discoverer and date can get updated to say "Scot Ellison" and "2007". A note can be added at the top of the article saying "For the original, much larger p5 domino sparker from 1995, see [[Hickerson's heavyweight volcano]]." A new article can get created for "Hickerson's heavyweight volcano", with a description of the origins and an infobox that shows that pattern.

Might that be a good compromise? They say a good compromise can be recognized by the fact that nobody is quite happy with it, but everybody thinks it's better than not getting anything that they want. I'm not quite happy with this option, but I'm certainly willing to live with it. Thoughts?

[Sokwe]

Infoboxes are really confusing, in several different ways. I think there are many cases when one could do better without an infobox.

Pattern infoboxes work great for unambiguous individual patterns that aren't subject to change, like loafer or mazing. They work less well with patterns that can be reduced (without fundamental changes), but I think their use is still a net benefit in such cases. And then there are the gun pages that try to cover a whole class of essentially different patterns, where I wonder if the infoboxes might actually be a detriment.

The following is my opinion on what should be included in infoboxes:

In the case of patterns with variants (that are fundamentally the same pattern), I think the most notable form should be used for the infobox, with interesting variants going in the gallery or somewhere else on the page. I would prefer not to have a more notable pattern "hidden" down in the gallery of a less notable pattern. In such cases, the discoverer list should at least be updated to include those involved in the reduction, but I don't know the best way to do this. It might be nice to have a separate designation for people who reduced the pattern, rather than contributed to its original discovery.

The most notable form of some patterns will inevitably change over time, and that could necessitate an infobox change or even a page move. I don't see this as too much of a problem, as the actually notable patterns that improved seem few and far between. Some patterns in fact need to be changed to their older forms. For example, the p26 pre-pulsar shuttle and p49 bouncer loop were first added to the wiki in slightly reduced forms, as those were the smallest oscillators of their respective periods. Now that they are no longer the smallest, they should be changed to their original forms, since their status as the first oscillators of their respective periods is now clearly their most notable quality.

For the gun pages, I think we need some other system. Either a new type of infobox like the one used on the various speed pages (generated by template:speed), or no infobox at all and a standardized way to structure the pages, including where to put the first and the smallest guns. Of course, specific gun pattern pages, such as Gosper glider gun and Medusa would still exist and use infoboxes.

Edit:

Here's one option that technically satisfies all of these various contentions:

• The "heavyweight volcano" article's discoverer and date can get updated to say "Scot Ellison" and "2007". A note can be added at the top of the article saying "For the original, much larger p5 domino sparker from 1995, see [[Hickerson's heavyweight volcano]]." A new article can get created for "Hickerson's heavyweight volcano", with a description of the origins and an infobox that shows that pattern.

Might that be a good compromise? They say a good compromise can be recognized by the fact that nobody is quite happy with it, but everybody thinks it's better than not getting anything that they want. I'm not quite happy with this option, but I'm certainly willing to live with it. Thoughts?

I personally think there shouldn't be two pages for different heavyweight volcanoes. That seems excessive. However, it is preferable to having mismatching pattern and discovery information in the infobox.

I would prefer an option to simply void the discovery information in the infobox (as in, remove it entirely, since it currently says "unknown" if you leave out the discoverer and year). Then the "best" example can go in the infobox, and discovery information and variants can then go in the article body or gallery.

[dvgrn]

This was an interesting question, and I didn't want to leave it accidentally unanswered:

How about do a poll on where to leave the article?

Here's my perspective on polls. I tried running a poll a while back.

It seemed like a good experiment to try at the time, and it produced some information that I personally thought was useful. So it worked out fine from my point of view. But it didn't settle the issue that it was intended to settle. Ultimately there's a decent argument that it ended up being more trouble than it was worth, because it became the subject of a long-drawn-out argument.

Polls, unless they're handled carefully, definitely have a tendency to reduce an issue to a supermajority vote, at best -- or just a regular majority vote, more likely -- or some kind of unpleasant popularity contest, at worst.

Generally none of those options is really anybody's favorite way to resolve LifeWiki issues. A gradually formed consensus is better -- in the rare cases where we can reliably figure out what the consensus is, given that usually very few people want to bother speaking up and say anything about any given issue!

Having said all that --
Based on past experience -- including my poll and Scorbie's poll, relatively recently -- polls do end up getting a good bit more participation than discussions. So there's that.

I actually don't have any personal objection to a poll thread being started about that article name. The choice of "55P23" or "54P23" seems like a nice simple binary choice to me, appropriate for a poll.

I'd personally be interested in seeing the results of that poll. I'd be happy to abide by the whatever the majority result comes out to be. The article will be totally fine either way, in my opinion.

However, it doesn't look like everybody agrees with that opinion -- in which case, someone might reasonably object to the idea of leaving the issue to be decided by a majority vote in a poll thread.

The theoretical conditions under which a poll would work great...
If there turns out to be a general consensus that

• a poll should be created, and
• the article should then get named whatever the poll says to name it

-- then I'll be very happy that a non-controversial method has been found to resolve the issue.

However, I'm thinking if even just a couple of of people object to the creation of the poll, it's probably not worth bothering with it.

[confocaloid]

Traffic jam
The embedded signal jam viewers are way too wide, and do not fit to the left of the infobox. Neither opening the browser in fullscreen nor zooming helps (and doesn't fix the problem). I think the width of those should be reduced.
In this case, it may also be better to get rid of the infobox, and instead put another embedded viewer on the top, showing the basic reaction.

[hotdogPi]

Would it be better to make them vertical, or does that cause other issues?

[confocaloid]

Would it be better to make them vertical, or does that cause other issues?

I think that's likely to cause other issues (vertical scrolling). Long thin patterns like those don't really work well in embedded viewers (compared to putting such a pattern in a separate RLE in a pattern collection).

[dvgrn]

I think that's likely to cause other issues (vertical scrolling). Long thin patterns like those don't really work well in embedded viewers (compared to putting such a pattern in a separate RLE in a pattern collection).

I just put in an experimental edit. From what I remember, four-digit WIDTH settings have always tended to cause various problems (though a recent LifeViewer update should now mean there aren't as many weird errors as there used to be, that some people would see and others wouldn't, depending on their browser display width.)

@confocaloid, how does the Traffic jam page look to you now, with WIDTH 800 settings for the embedded viewers instead of WIDTH 1600?

[confocaloid]

A parameter |style = "width:300px;" should be passed to the EmbedViewer template, to restrict the width of the box. Otherwise it remains full-width. Which looks bad enough:

png.png (13.59 KiB) Viewed 6853 times

[dvgrn]

A parameter |style = "width:300px;" should be passed to the EmbedViewer template, to restrict the width of the box. Otherwise it remains full-width. Which looks bad enough...

Okay, I gave that a try. On my system it looks like an overly long chunk of text in the caption can override the 300px setting, such that the viewer frame still ends up a little wider.

That's mostly an issue with too much detail packed into the caption, but that might be a rewrite for another day. I've put in some manual line breaks temporarily, even though I know it's not the greatest idea long-term. Is the article more or less tolerable for now?

[confocaloid]

A parameter |style = "width:300px;" should be passed to the EmbedViewer template, to restrict the width of the box. Otherwise it remains full-width. Which looks bad enough...

Okay, I gave that a try. On my system it looks like overly long caption can override the 300px setting [...]

Edit: looking through source code of another page (Pre-pulsar shuttle), it seems the double quotes are not needed at all.

[dvgrn]

I think that is because the 300px setting is specified with a typo (missing double-quote " at the end): https://conwaylife.com/w/index.php?diff ... did=146646

Hmm. That was a typo for sure, but fixing it doesn't seem to change anything -- not that it would really be an improvement to force new line breaks just before the ends of those overflowing lines, at this point.

EDIT: looking at other articles with that style setting, it looks like the mistake was to enclose the "width:300px;" in quotes at all. The template must take care of that detail; it works better without quotes.

Just need a rewrite with a Details section, probably. Among other things, it's still just about as clear as mud exactly how to go about building, say, a p108 traffic-jam oscillator.

(Looks like what's needed is four "fast" traffic-jam turns, like the ones in Bill Gosper's p200 example from 16 October 1996:

Code: Select all

#C p200
x = 77, y = 77, rule = B3/S23
26b2o4b2o$26bobo2bobo$28bo2bo$27b2o2b2o$26b3o2b3o$28bo2bo18b2o4b2o$36b
obo11bobo2bobo$35bo16bo2bo$36bo2bo11b2o2b2o$31bo4bobobo9b3o2b3o$31bo5b
o2bo11bo2bo$31bo6b2o20b2o$14b2o44b3o$13bo2bo10b3o3b3o24b2obo$14bobo45b
obo$12b2obo15bo22b3o4bo2bo$12b3o16bo30b2o$12b2o17bo20bo5bo$17b3o32bo5b
o$5b2o2bo42bo5bo$5bo2b2o5bo5bo$6b5o4bo5bo32b3o$15bo5bo7b3o$38b3o$6b5o
6b3o7bo5bo$5bo2b2o17bo5bo2bo5bo$5b2o2bo17bo5bo2bo5bo29bo2b2o$36bo5bo7b
3o10bo8b2o2bo$29b3o31bo7b5o$38b3o7bo5bo8bo$26bo21bo5bo$26bo21bo5bo4b3o
3b3o3b5o$26bo45b2o2bo$50b3o10bo8bo2b2o$22b3o3b3o32bo$63bo3bobo$9b2o15b
o43bo$8bo2bo14bo39bo2bo$7bobobo14bo23bo14bobobo$7bo2bo39bo14bo2bo$6bo
43bo15b2o$7bobo3bo$13bo32b3o3b3o$2o2bo8bo10b3o$o2b2o45bo$b5o3b3o3b3o4b
o5bo21bo$22bo5bo5bo15bo$13bo8bo5bo5bo$b5o7bo20bo10b3o$o2b2o8bo10b3o$2o
2bo25b3o3b3o4bo5bo17bo2b2o$43bo5bo17b2o2bo$34bo8bo5bo7b3o6b5o$34bo$34b
o10b3o7bo5bo$20b3o32bo5bo4b5o$55bo5bo5b2o2bo$18bo5bo42bo2b2o$18bo5bo32b
3o$18bo5bo20bo17b2o$13b2o30bo16b3o$12bo2bo4b3o22bo15bob2o$12bobo45bob
o$13bob2o24b3o3b3o10bo2bo$14b3o44b2o$15b2o20b2o6bo$21bo2bo11bo2bo5bo$
19b3o2b3o9bobobo4bo$20b2o2b2o11bo2bo$21bo2bo16bo$19bobo2bobo11bobo$19b
2o4b2o18bo2bo$43b3o2b3o$44b2o2b2o$45bo2bo$43bobo2bobo$43b2o4b2o!

Then either unices or those p4s from the p104 traffic jam could be used at the corners, with the loop expanded out to 2700 ticks and 25 signals in the loop.)

For the loop to be adjustable to period 102+6N by adding or removing groups of twelve traffic lights, six on each side, the corners had better use unices:

Code: Select all

x = 673, y = 125, rule = B3/S23
36bo2bo$36bo$18b4o13bo4bo$17bo4bo11bobo2b2o$17bo3bobo8b2obo$18bo3bobo
$24bo$24bo7bo2bo$21bo2bo4bo4b2o$6b2o14b2o5bo$6b2o21bo2$25b3o3b3o$5b3o
$5b2obo2b2o16bo$7b2o2b2o16bo$7b2o20bo$15b3o2$13bo5bo$13bo5bo$13bo5bo7b
3o$36b3o$15b3o7bo5bo19b3o10bo$10b2o13bo5bo2bo5bo23bo$9b4o12bo5bo2bo5b
o8bo5bo8bo10b3o10bo$8bo2bobo20bo5bo8bo5bo32bo$7bobo2b2o13b3o19bo5bo4b
3o3b3o4bo5bo8bo10b3o10bo$6bobo27b3o34bo5bo32bo$5b2o17bo26b3o10bo8bo5b
o4b3o3b3o4bo5bo8bo10b3o10bo$5b3o16bo39bo32bo5bo32bo$6bobo15bo39bo10b3o
10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$7b2o79bo32bo5bo32bo$b2o17b3o3b3o
59bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$o2bo108bo32bo5bo32bo$o23b
o87bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$o23bo111bo32bo5bo32bo$
obo3bo17bo111bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$bobo3bo152bo
32bo5bo32bo$2bo4bo152bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$3b4o
4bo172bo32bo5bo32bo$11bo172bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10b
o$11bo10b3o183bo32bo5bo32bo$208bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o
10bo$7b3o3b3o4bo5bo205bo32bo5bo32bo$20bo5bo5bo199bo10b3o10bo8bo5bo4b3o
3b3o4bo5bo8bo10b3o10bo$11bo8bo5bo5bo223bo32bo5bo32bo$11bo20bo10b3o10b
o199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$11bo10b3o31bo223bo32b
o5bo32bo$3b2o23b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4b
o5bo8bo10b3o10bo$5bob2o32bo5bo32bo223bo32bo5bo32bo$bo2bo2b2o23bo8bo5b
o4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o
10bo$bobo28bo32bo5bo32bo223bo32bo5bo32bo$2bo29bo10b3o10bo8bo5bo4b3o3b
3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$18b
3o35bo32bo5bo32bo223bo32bo5bo32bo$2b2o52bo10b3o10bo8bo5bo4b3o3b3o4bo5b
o8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo212b2o$2b2o
12bo5bo57bo32bo5bo32bo223bo32bo5bo32bo211b4o$16bo5bo57bo10b3o10bo8bo5b
o4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o
10bo172bo13bo2bobo$16bo5bo81bo32bo5bo32bo223bo32bo5bo32bo168b4obo11bo
bo2b2o$104bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8b
o5bo4b3o3b3o4bo5bo8bo10b3o10bo144b3obobo9bobo$18b3o4b2o101bo32bo5bo32b
o223bo32bo5bo32bo149bobo7b2o$13b2o10b2o101bo10b3o10bo8bo5bo4b3o3b3o4b
o5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo126bo8b
3o$13bobo9b2o125bo32bo5bo32bo223bo32bo5bo32bo125b2o9bobo$14b3o8bo126b
o10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o
4bo5bo8bo10b3o10bo101b2o10b2o$15b2o7bobo149bo32bo5bo32bo223bo32bo5bo32b
o101b2o4b3o$13bobo9bobob3o144bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10b
o199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$8b2o2bobo11bob4o168bo
32bo5bo32bo223bo32bo5bo32bo81bo5bo$8bobo2bo13bo172bo10b3o10bo8bo5bo4b
3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10b
o57bo5bo$9b4o211bo32bo5bo32bo223bo32bo5bo32bo57bo5bo12b2o$10b2o212bo10b
3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo
5bo8bo10b3o10bo52b2o$248bo32bo5bo32bo223bo32bo5bo32bo35b3o$248bo10b3o
10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5b
o8bo10b3o10bo29bo$272bo32bo5bo32bo223bo32bo5bo32bo28bobo$272bo10b3o10b
o8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8b
o23b2o2bo2bo$296bo32bo5bo32bo223bo32bo5bo32b2obo$296bo10b3o10bo8bo5bo
4b3o3b3o4bo5bo8bo10b3o10bo199bo10b3o10bo8bo5bo4b3o3b3o23b2o$320bo32bo
5bo32bo223bo31b3o10bo$320bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo199b
o10b3o10bo20bo$344bo32bo5bo32bo223bo5bo5bo8bo$344bo10b3o10bo8bo5bo4b3o
3b3o4bo5bo8bo10b3o10bo199bo5bo5bo$368bo32bo5bo32bo205bo5bo4b3o3b3o$368b
o10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo$392bo32bo5bo32bo183b3o10bo
$392bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo172bo$416bo32bo5bo32bo
172bo4b4o$416bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo152bo4bo$440b
o32bo5bo32bo152bo3bobo$440bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo
111bo17bo3bobo$464bo32bo5bo32bo111bo23bo$464bo10b3o10bo8bo5bo4b3o3b3o
4bo5bo8bo10b3o10bo87bo23bo$488bo32bo5bo32bo108bo2bo$488bo10b3o10bo8bo
5bo4b3o3b3o4bo5bo8bo10b3o10bo59b3o3b3o17b2o$512bo32bo5bo32bo79b2o$512b
o10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo39bo15bobo$536bo32bo5bo32bo
39bo16b3o$536bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o10bo15bo17b2o$560b
o32bo5bo32bo31bobo$560bo10b3o10bo8bo5bo4b3o3b3o4bo5bo8bo10b3o13b2o2bo
bo$584bo32bo5bo35bobo2bo$584bo10b3o10bo8bo5bo4b3o3b3o4bo5bo12b4o$608b
o32bo5bo13b2o$608bo10b3o10bo8bo5bo7b3o$632bo$632bo10b3o7bo5bo$653bo5b
o$653bo5bo2$655b3o$643bo20b2o$643bo16b2o2b2o$643bo16b2o2bob2o$665b3o$
639b3o3b3o2$643bo21b2o$643bo5b2o14b2o$637b2o4bo4bo2bo$637bo2bo7bo$648b
o$648bobo3bo$637bob2o8bobo3bo$632b2o2bobo11bo4bo$632bo4bo13b4o$636bo$
633bo2bo!

Maybe also mention in the article that there's a free choice of two locations for each traffic-light pair, so there's quite a bit of freedom in where the traffic-jam lines go? The p104 doesn't have to be oblique-looking, for example, and the p102 doesn't have to look orthogonal. Here's the top line of the p102 adjusted to make a bend in the middle:

Code: Select all

x = 576, y = 86, rule = B3/S23
540b2o13bo2bo$263bo34b3o10bo224b2obo15bo$263bo22bobo22bo224b2o2bo2bo10b
o4bo$250b3o10bo7bobo11bo2bo7bo5bo8bo10bo218bobo9bobo2b2o$10b2o259bo2b
o11bobo7bo5bo18bo4bo215bo8b2obo$9b4o202bo32bo5bo4b3o3b3o3bobo22bo5bo4b
3o3b3o12bo17b3o10bo$8bobo2bo13bo187bo22b3o7bo5bo64b2obo6b2o3bobo22bo17b
obo161b2o$8b2o2bobo11bob4o170b3o10bo7b3o12bobo7bo5bo8bo34b3o10bo7bobo
3b2o6bob2o7bo5bo8bo16bo3bo160b2o4bo3bo2bo$13bobo9bobob3o191bobo12b3o22b
o47bo15bo16bo5bo19bo176bo5b2o14b2o$15b2o7bobo140bo23bo8bo5bo4b3o3b3o3b
3o24b3o10bo47bo17bo4bo9bo5bo4b3o3b3o4bob2ob4o5b2o10b3o10bo139bo21b2o$
14b3o8bo141bo8bo13b3o7bo5bo126bo33bo4bo7bo3bo22bo12b3o146b2o$13bobo9b
2o127b3o10bo7b3o11b2ob2o6bo5bo8bo130b3o10bo7bo3bo7bo4bo7bo5bo8bo10b7o
b3o114b3o3b3o18bo$13b2o10b2o116bo30b2ob2o11b3o22bo143bo8b2o5b4ob2obo8b
o5bo19b4obobo4bo138bobo$18b3o4b2o92bo8bo13b3o7bo5bo4b3o3b3o3b3o13bo10b
3o10bo143bo21bo10bo5bo4b3o3b3o4b2o4bobo3bobo11b3o10bo91bo16b3obobo$119b
o7b3o11bobobo6bo5bo17bo194bo3bo40bo3b3o5bobo24bo91bo16b4obo$16bo5bo72b
o10b3o10bo6bobobo9b3ob3o5bo5bo8bo204bobo19b3o10bo9bobo5b3o3bo8bo5bo8b
o13b2o4b2o70bo20bo$16bo5bo57bo14bo29b3ob3o9bobobo21bo239bo9bobo3bobo4b
2o8bo5bo19b3ob2o2bo2bo81b3o$2b2o12bo5bo48bo8bo14bo8bo5bo4b3o3b3o2bobo
bo11b3o9b3o10bo239bo9bo4bobob4o10bo5bo4b3o3b3o4bob4o3b2ob2o12b3o10bo46b
3o$2b2o67bo8bo23bo5bo16b3o13bo275b3ob7o34bo2bobo4bobo2bo23bo48bo3b3o4b
o$18b3o26bo10b3o10bo19b3o3b3o4bo5bo8bo8bo296b3o14b3o10bo8bo2bobo4bobo
2bo8bo5bo8bo10b2obo5b2o23bo3b2o9bo$2bo29bo14bo28b3o3b3o34bo335bo10b2o
b2o3b4obo8bo5bo20b4o4b2o23bo9b2o3bo$bobo19bo8bo14bo8bo5bo4b3o3b3o19bo
10b3o10bo335bo10bo2bo2b2ob3o10bo5bo4b3o3b3o4bo2bo2bo3bobo13b3o7bo4b3o
3bo$bo2bo2b2o14bo8bo23bo5bo17bo14bo371b2o4b2o37bo3bo5b2o3bo31b3o$5bob
2o14bo3bobo13b3o3b3o4bo5bo8bo8bo14bo394b3o10bo8bo3b2o5bo3bo8bo5bo7b3o
$3b2o21bo3bo3b3o34bo8bo422bo11bobo3bo2bo2bo8bo5bo24b2o$11bo7b3o3bo3bo
17bo10b3o10bo431bo11b2o4b4o11bo5bo20b2o2b2o$11bo14bobo3bo14bo467b2o5b
ob2o37b2o2bob2o$11bo11bo8bo14bo490b3o27b3o$23bo8bo$7b3o3b3o7bo$568b2o
$11bo556b2o$11bo539b3o$3b4o4bo$2bo4bo541bo5bo$bobo3bo541bo5bo$obo3bo17b
o524bo5bo$o23bo$o23bo526b3o$o2bo$b2o17b3o3b3o2$23b2o$23b3o525bo$24bo526b
o21b2o$23bo527bo21b2o$22b3o$23b2o522b3o3b3o$573b3o$19b3o3b3o523bo16b2o
2bob2o$551bo16b2o2b2o$23bo527bo20b2o$23bo539b3o$6b2o15bo530b3o$5bo2bo
558bo$5bo172bo373bo5bob3o4bo$5bo30bo23bo47bo47bo15bo31bo47bo47bo47bo47b
o47bo47bo34b3o10bo11bo4b3obo5bo$5bobo3bo15bo8bo23bo14b2o4b2ob2o22bo14b
2o3b5o23bo15b4o5bo22bo47bo47bo47bo47bo47bo25b3o19bo25b3o19bo11bo$6bob
o3bo14b2o4b4o10b3o10bo13bo2bo3bo13b3o10bo13bo2b2obo4b2o8b3o10bo14bob2o
16b3o10bo18bobo2b3o8b3o10bo34b3o10bo34b3o10bo26bo7b3o10bo25b3o6b3o10b
o10b3o21b3o10bo10b3o19bo5bo8bo22b3o$7bo4bo20bo41bobo3bo2bo36b3ob2o41b
2o5bo5b3o32bo7b7o39bo7b2o47bo32bo13bobo30b3o11bo3bo42bo5bo41bo5b4o5bo
22b3o12b2o$8b4o16b2o5bo2b3o4bo5bo4b3o3b3o10bobo5b2ob3o4bo5bo4b3o3b3o8b
obobo3b2o4b2o4bo5bo4b3o3b3o7b2obob2ob4obobo5bo5bo4b3o3b3o6bo8b4obob2o
4bo5bo4b3o3b3o6bobo4bo7b3o4bo5bo4b3o3b3o7bo12b2ob2o3bo5bo4b3o3b3o6bob
o11bo3bo3bo5bo4b3o3b3o5bo3bo10bo3bo3bo5bo4b3o3b3o4bo5bo8bo5bo2bo5bo4b
3o3b3o4bo5bo8bo5b4o5bo4b3o3b3o23b4o$15bo7b3o2bo5b2o9bo5bo19b3ob2o5bob
o8bo5bo19b2o4b2o3bobobo6bo5bo20bobob4ob2obob2o5bo5bo19b2obob4o8bo4bo5b
o19b3o7bo4bobo4bo5bo18b2ob2o12bo5bo5bo18bo3bo11bobo4bo5bo18bo3bo10bo3b
o3bo5bo17bo5bo8bo5bo2bo5bo17bo5bo8bo5bo44bobo2bo$15bo14bo14bo5bo8bo14b
o2bo3bobo8bo5bo8bo20b2ob3o6bo5bo8bo11b3o5bo5b2o5bo5bo8bo12b7o7bo5bo5b
o8bo11b2o7bo11bo5bo8bo11bo20bo5bo8bo10bobo13bo5bo5bo8bo9bo3bo11b3o4bo
5bo8bo8bo5bo17bo5bo8bo8bo5bo19b3o10bo26b2o2bobo$15bo11b4o4b2o23bo17bo
3bo2bo22bo12b2o4bob2o2bo22bo20b2obo23bo12b3o2bobo27bo47bo47bo11bo35bo
10b3o34bo25b3o19bo25b3o19bo31bobo$27bo8bo10b3o10bo13b2ob2o4b2o10b3o10b
o14b5o3b2o10b3o10bo13bo5b4o11b3o10bo34b3o10bo34b3o10bo34b3o10bo34b3o10b
o34b3o10bo10b3o21b3o10bo10b3o34bo33b2o$11b3o3b3o7bo151bo393b3o$173bo398b
obo$15bo539b3o14b2o$7bo2bo4bo$7bo7bo539bobo$6bo4bo544bo$5bobo2b2o16bo
520b2o$3b2obo20bobo519bo2bo8b2o$26bo3bo530b2o$27bobo$3bo2bo21bo520bob
2o8bo$5b2o14b2o521b2o2bobo9bobo$21b2o10b2o509bo4bo10bo2bo2b2o$21b2o9b
obo513bo15bob2o$22bo8b3o511bo2bo13b2o$21bobo7b2o$16b3obobo9bobo$16b4o
bo11bobo2b2o$20bo13bo2bobo$35b4o$36b2o!

[confocaloid]

Maybe it would work better to actualy show only small parts of large patterns that were or could be built with these reactions, and explain each component separately in the text surrounding the embedded viewer (instead of putting a single long thin viewer and consequently having headaches over how to explain how the whole pattern works).

[confocaloid]

Multiple issues

https://conwaylife.com/w/index.php?diff ... did=138349
Problematic illustration using a multistate CA rule that isn't the topic of the article; hard to understand visually and cannot be easily copy&pasted into Golly or another simulation software.
The pattern should be replaced with a plain Life two-state pattern (separating differences in space, instead of overlaying them).

https://conwaylife.com/w/index.php?diff ... did=122330
(1) Problematic illustration using a multistate CA rule that isn't the topic of the article; hard to understand visually and cannot be easily copy&pasted into Golly or another simulation software. The AUTOSTART animation makes things even worse. The pattern should be either replaced with a plain Life pattern (showing variants separately) or simply removed.
(2) Unnecessary and unexplained reorientation of the 60p72 pattern, combined with replacement of the pname link with a RLE. The change is not an improvement. Most likely should be reverted.

https://conwaylife.com/w/index.php?diff ... did=146628 Significant changes in the user namespace of another user, made without their permission.

https://conwaylife.com/w/index.php?diff ... did=146703 Incorrect; the p116 doesn't hassle a beacon. When a beacon appears there are also other parts of the hassled reaction interacting with the beacon.

https://conwaylife.com/w/index.php?diff ... did=146701 The edit inserted text between a footnote ref and an HTML comment about that footnote, disconnecting the two from each other. It is still possible to recover the association with extra effort, but it becomes harder.

https://conwaylife.com/w/index.php?diff ... did=146629 Lack of the forum link to the relevant post; punctuation.

https://conwaylife.com/w/index.php?diff ... did=144869 No links to source / discovery information.


Reposting previous unresolved issues

• (repost from post178607) The edit https://conwaylife.com/w/index.php?diff ... did=142444 added "I for ill", which is not an existing term in common use. The linked edit appears to be an instance of someone documenting their own terminology (LifeWiki:Notability#Name_notability_guideline).
• (repost from post178110) In the edit https://conwaylife.com/w/index.php?diff ... did=125212 multiple patterns added to the page, with bad formatting (cleanup needed) and without providing links to sources (i.e. where these patterns come from?)
• (repost from post178110) In the edit https://conwaylife.com/w/index.php?diff ... did=144801 a pattern is added without linking to the sources - where it came from?
• (repost from post178933) Page section https://conwaylife.com/w/index.php?titl ... ther_rules
  The section is very hard to read and comprehend. In particular, there are nonobvious assertions without links to sources; unnecessarily nested bulleted lists; "This yields the following rulespaces" does not clarify explicitly whether those can or cannot contain spaceships; too long sentences; complicated structure of sentences.
  The overall impression is that there are too many details, and that level of details doesn't really belong in this article (and the information shouldn't be presented in this form anyway in an encyclopedic-style article).
  I think the section should be significantly reduced in size, to leave only a brief summary without details and several footnotes with links to places where an interested reader can read all the details, should they choose to do so.
• (previous relevant discussion in several earlier posts here) Fixing/trimming/removing the infobox in the heavyweight volcano entry. (The viewer does not show the 1995 pattern. The shown pattern does not match the discovery information.)
• Explaining traffic jams ( viewtopic.php?p=179956#p179956 viewtopic.php?f=2&t=6398 )

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=142352
The edit replaced a previously shown 8-glider synthesis for the object with a 6-glider synthesis.
The previously shown 8G synthesis should be restored, and a new viewer for the 6G synthesis should be added, with a different link/reference.

[dvgrn]

https://conwaylife.com/w/index.php?diff ... did=142352
The edit replaced a previously shown 8-glider synthesis for the object with a 6-glider synthesis.

It did, indeed.

The previously shown 8G synthesis should be restored, and a new viewer for the 6G synthesis should be added, with a different link/reference.

I checked the two current references when I made the edit -- wasn't clear that they needed changing. The first link is to the Catagolue page, which just shows the 6G synthesis now.

However, it's true that if you dig deep enough on the link to Mark Niemiec's database -- i.e., the "2.1" part of the reference -- you can find the old 8G synthesis. Is there a reason to still show the 8G synthesis? Why is it significant now that there's a 6G synthesis available? Could we just remove the link to Mark Niemiec's 13-bit object pages, or is that link somehow still important to keep?

[confocaloid]

Is there a reason to still show the 8G synthesis? Why is it significant now that there's a 6G synthesis available?

When I earlier added the 8G synthesis, the intent was to create a place where subsequent improvements could be added, showing history of reductions. It is interesting to see how cheaper and cheaper glider syntheses were found over time. I think the old synthesis should be kept in the article, along with the link to Mark Niemiec's pages (which are a common source for many other glider syntheses for other targets as well).

A reader does not have to dig to find the syntheses. The footnote already provides two separate links -- one link to the overview page "Life Thirteen-Bit Still-Lifes" (which is necessary to give context), and another link "(download pattern file: 13/13-42.rle)" which leads directly to the synth file.

[dvgrn]

When I earlier added the 8G synthesis, the intent was to create a place where subsequent improvements could be added, showing history of reductions. It is interesting to see how cheaper and cheaper glider syntheses were found over time. I think the old synthesis should be kept in the article, along with the link to Mark Niemiec's pages (which are a common source for many other glider syntheses for other targets as well).

In the absence of any information about what you were planning for this article, my judgment call was that it wasn't necessary to show the 8G synthesis any more. But I don't have a strong opinion one way or another, so I've gone ahead and put back the 8G synthesis.

Can you think of any good way to mark articles like this one, to explain the intention a little better? It looked to me like a regular out-of-date article, where the old synthesis was no longer particularly relevant or interesting now that a new cheaper synth is available.

For a lot of constructible objects we won't want to collect the whole series of incremental improvements in the article -- there will be too many of them, and will take up way too much space, considering the low level of importance of the outdated syntheses. An extreme case is something like the spacefiller synthesis; "moderate" cases include the other two synth-cost improvements that came up this month.

Your suggestion from November 2022 about "relatively small" syntheses ... seems like it will work in this case -- especially since we've probably reached the end of the improvement chain -- one more at most, right? 5G seems vaguely possible, but 4G quite unlikely. Where might the dividing line be between "relatively small" and "too big to document every improvement"?

A reader does not have to dig to find the syntheses. The footnote already provides two separate links -- one link to the overview page "Life Thirteen-Bit Still-Lifes" (which is necessary to give context), and another link "(download pattern file: 13/13-42.rle)" which leads directly to the synth file.

Let me put it this way, then: I did end up doing some digging, because I clicked on the "Life Thirteen-Bit Still-Lifes" link since it was the first one, expecting it to be relevant... and then had to poke around and find the long^7 snake and find the right place to click to see the synthesis file.

There's something I don't understand yet about the way that those links are set up in the article. For some reason there are now three links for the first reference -- 1.0, 1.1, 1.2 -- where I expected only one. I'm out of time for the moment, but might try rebuilding those references later, to see if I can get the 1.1 and 1.2 links to go away.

[confocaloid]

The section "Construction" is a place for collecting known notable ways to construct the object that is the topic of the article. (Glider syntheses, one-glider seeds, other notable reactions that create the object in an interesting/useful way.)

[...] An extreme case is something like the spacefiller synthesis; [...]

I think it would make perfect sense to document the detailed history of spacefiller synthesis efforts with successive improvements in a dedicated article, if only there was an article. The subject is clearly notable enough for a dedicated article.

Your suggestion from November 2022 about "relatively small" syntheses ... seems like it will work in this case -- especially since we've probably reached the end of the improvement chain -- one more at most, right?

For notable objects that can be expected to be used as components in larger patterns / intermediates in syntheses / parts of intermediate constellations (such as small still lives, Gabriel's p138, Rob's p16), it makes sense to document every known synthesis, in a certain sense. (Excluding syntheses that are trivial variations of each other and hence are redundant to each other.) This is not limited to reductions in the glider cost. If there are two or three known nontrivially different six-glider syntheses for long⁷ snake that can be used in different contexts, then it makes sense to document all those syntheses.

For notable objects that are very rarely or never used as components or intermediates (such as Gray counter or a spacefiller), and also for notable objects that are used as components/intermediates but are too large for a glider synthesis to be directly useful in the context of a larger construction (such as 208P41), it is unnecessary to show all known syntheses directly on the page. However, the history of synthesis reductions/improvements can and should be documented, when that is possible. (I.e. it is unnecessary to show improvements, but they should be mentioned in text.)
Having a section about efforts to find glider syntheses for the object is a large part of what makes the object interesting.

[...]
There's something I don't understand yet about the way that those links are set up in the article. For some reason there are now three links for the first reference -- 1.0, 1.1, 1.2 -- where I expected only one. I'm out of time for the moment, but might try rebuilding those references later, to see if I can get the 1.1 and 1.2 links to go away.

"1.0, 1.1, 1.2" says that there were three references to that footnote. These are backlinks allowing the reader to go back from the footnote to the places on the page where that footnote was referenced. The actual text of the footnote comes after the backlinks. This is the expected behaviour: https://www.mediawiki.org/w/index.php?t ... e_footnote

However, in this case, after the edits to the page, the caption "A 6G synthesis" now refers to a footnote linking to Niemiec's pages. This is incorrect: Niemiec's pages are a source for the 8G synthesis, but they are not a source for that six-glider synthesis.
Instead, a footnote for the 6G synthesis can link to https://web.archive.org/web/20240401170 ... 248c/b3s23 instead. This link provides an (incomplete) answer to "where this synthesis came from?"

[dvgrn]

Instead, a footnote for the 6G synthesis can link to https://web.archive.org/web/20240401170 ... 248c/b3s23 instead. This link provides an (incomplete) answer to "where this synthesis came from?"

Here's hoping somebody will show up and give a definite date for that discovery, but a timestamped Internet Archive page is at least slightly better than just a link to the current version of the same page, for the purposes of determining a "was definitely discovered by this time" date and also future-proofing the link so that it won't have to change if a cheaper synthesis comes along.

I've made an attempt to simplify the links. There was one duplicated link that was my recent mistake, but a couple of other links also seemed to be unnecessary -- e.g., It seemed a bit excessive to have a link to long^7 snake's Catagolue page in External Links, in References, _and_ under "Identifiers" in the infobox.

Is there maybe a standard policy of including the Catagolue page in External Links? I could certainly see putting that link back, if so; the link under "Identifiers" is maybe too well hidden, at least for newcomers to the LifeWiki.

A tangential topic: it really seems like we need a Help article about how to quickly create references correctly. The standard format for a long time used to be something like <ref name="post158985" />, with a section under <references> along these lines:

<ref name="post158985">{{LinkForumThread
|format = ref
|p = 158985
|title = Re: Small Spaceship Syntheses
|author = Adam P. Goucher
|date = March 13, 2023
}}</ref>

... and we used to do |accessdate also, but now that's not very common. For forum threads I think that's reasonable; in general, old forum posts aren't likely to change or disappear for the lifespan of the LifeWiki, so there's often not much point in spending time documenting the date that the reference was added. Often someone will come along and edit the article and re-check the reference, and it will still be there... but of course they usually won't bother to update the access date. So then it quickly starts looking like just some random old date that doesn't really need to be displayed.

Anyway, now there are some other types of compact inline references that are getting used more commonly -- but I never seem to be able to remember where I've seen them, so then I can't find a good example when I want to use it for a reference. With the importance that we attach to references, it seems like it's high time to lay out the various options clearly in a Help article somewhere... or is there something like that out there already, and I'm just not seeing it?

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=133216
Misplaced content (category pages are not supposed to contain extended discussion); currently controversial topic (relays and other oscillator terminology).

EDIT by dvgrn: Table moved to Relay article by hotdogPi.

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=114896

Not a typo. The intended meaning is "if and only if".

https://conwaylife.com/w/index.php?diff ... did=144853

See the discussion viewtopic.php?p=183073#p183073 for why the entry Problem should be trimmed down, to remove extended discussion of individual problems/conjectures, and instead leave only brief mentions and links to further reading / discussion threads.

[...]
however, I believe it would be an improvement if the wiki entry Problem would be shortened, and would list fewer specific problems/conjectures and instead give more "Further reading" hyperlinks at the end.
Otherwise, there are just way too many specific interesting conjectures and problems to list them all.
[...]

EDIT by dvgrn: The erroneous typo fix has been re-fixed by hotdogPi. Good catch!

I've looked at the suggestion about removing entries from Problem two or three times now. There aren't any specifics about which entries should be removed, and I personally can't see any particular problem with the current list, or the idea of extending it to include more items whenever someone wants to take the time to do that. I like DroneBetter's recent additions, though I'm thinking some version of the less-formalized problem statement could maybe be put first... maybe just link to the formalized statement?