Difference between revisions of "LifeWiki:Tiki bar"

From LifeWiki
Jump to navigation Jump to search
Line 380: Line 380:


:Good issue to raise. It would be good to have an explicit "policy" about such things. I think we also need a similar agreement about whether and when a person should be linked at all even if there is little likelihood of the link ever having a landing (I'm thinking mainly of well-aged red links). [[User:Book|Book]] ([[User talk:Book|talk]]) 23:37, 5 September 2022 (UTC)
:Good issue to raise. It would be good to have an explicit "policy" about such things. I think we also need a similar agreement about whether and when a person should be linked at all even if there is little likelihood of the link ever having a landing (I'm thinking mainly of well-aged red links). [[User:Book|Book]] ([[User talk:Book|talk]]) 23:37, 5 September 2022 (UTC)
:: In general, I like red links; they are a very simple lightweight way to tell other editors "This page is missing", and they interact nicely with other available tools.<br />Speaking of pages '''about people''' specifically (and excluding all other LifeWiki topics), I'm inclined to agree that it's probably better to unlink long-missing pages about people. My reason is that such pages are harder to write, and the usual simple "process" of starting a short stub to be expanded later does not really work when writing about a person. [[User:Confocal|Confocal]] ([[User talk:Confocal|talk]]) 05:46, 16 April 2023 (UTC)


== Catalysts vs Eaters ==
== Catalysts vs Eaters ==

Revision as of 05:46, 16 April 2023

Taka Tiki Break

Welcome, one and all, to the Tiki bar! This page is used to discuss the technical issues, policies, and operations of the LifeWiki. Or just sit down, relax, and enjoy a cocktail.

Click here to start a new Tiki bar discussion.

Welcome to the Tiki bar

Wikipedia has the Village pump, Wiktionary has the Beer parlour, but the LifeWiki's lacked a central page for discussion so far other than User talk:Nathaniel. So I took the liberty to create the Tiki bar to facilitate discussion in a friendly and relaxed atmosphere. Welcome! Apple Bottom (talk) 11:09, 13 June 2016 (UTC)

Archived discussions

Note: active discussions are never archived while still active.

Proposal for niemiecsynth infobox parameter

Are there any objections to me adding a parameter to the pattern infobox which would link to a given object in Mark Niemiec's synthesis database. Despite its outdatedness, I've personally still found the database extremely useful due to the number of alternative syntheses it has, and I imagine many other people would as well. This would be far easier than manually uploading synthesis files to the pattern collection.

Note that this is distinct from niemiecid, which does not necessarily determine where a synthesis is found. For example, boat does not actually have a niemiecid as far as I can tell it, and its synthesis file is actually located at 0/5bt.rle. Non-still-life patterns also appear to not have IDs under the #.# system. Ian07 (talk) 03:43, 4 January 2022 (UTC)

Linking to Niemiec synthesis database is nice, but not necessarily shown in infobox in my opinion. An alternative method is to use {{LinkNiemiec}} in the External links section. There have been a bunch of pages doing that; previously I edited some for 12-cell still lives (e.g. this one) so that the link goes to the particular synthesis RLE directly instead of the general "The <count> <pop>-bit still lives" panel. I have not done this to other smaller still lives, though. GUYTU6J (talk) 04:24, 4 January 2022 (UTC)
Linking directly to a downloadable file in the External links section (or in a footnote) may be unexpected for a reader. I think it is usually better to have links to webpages that link to downloadable files, rather than linking to downloadable files directly. This helps to provide some context about the file rather than jumping directly to the download. Such URLs may also be more permanent while filenames are subject to change. Confocal (talk) 02:12, 22 July 2022 (UTC)
I do not have objections against having a dedicated parameter in the infobox with a direct link to the synthesis file, as long as it is done consistently and it is reasonably clear that clicking on the link will immediately proceed to the download of a RLE file with synthesis. Confocal (talk) 02:33, 22 July 2022 (UTC)

Do LCMs need their own pages?

134P39.1: Keep. It's historical, and we don't know of any non-p3/p13 p39s anyway.
22P4.3 on 56P27: Merge to 56P27.
258P3 on Achim's p11: Unsure. I might say it's not needed at all.
44P7 on Beluchenko's p13: Redirect to Beluchenko's p13, mention on both pages.
48P9 on rattlesnake: Redirect to rattlesnake, mention on both pages.
65P48: Keep; this is a rephaser where large oscillator doesn't have its own page.
69P48: Keep for the same reasons as 65P48.
72P68: Merge to honey thieves.
74P85: Merge to honey thieves.
77P77: Redirect to rattlesnake, mention on both pages (rattlesnake and 41P7.2).
87P26: Either keep or merge with 53P13.
90P51: Merge to honey thieves.
Blonker on Rich's p16: Delete (there's already a delete tag).
Boring p24: Keep; it's natural.
Caterer on 28P7.3: Merge to 28P7.3.
Caterer on 42P7.1: Merge to 44P7.2 (42P7.1 is a smaller but lower-clearance variant of 44P7.2).
Caterer on 44P7.2: Redirect to 44P7.2; no need to show.
Caterer on 68P32: Delete, no longer smallest.
Caterer on Beluchenko's p13: Merge to Beluchenko's p13.
Caterer on figure eight: Redirect to figure eight, mention on both pages.
Caterer on Jason's p22: Merge to Jason's p22.
Caterer on Merzenich's p31: Merge to Merzenich's p31.
Caterer on rattlesnake: Merge to rattlesnake.
Figure eight on 22P36: Merge to 22P36.
Figure eight on Beluchenko's p13: Merge to Beluchenko's p13.
Figure eight on centinal: Redirect to centinal; no need to show since it's p200.
Figure eight on Jason's p22: Delete, not the smallest.
Figure eight on pentadecathlon: Keep, natural.
Figure eight on rattlesnake: Merge to rattlesnake.
Fumarole on 34P14 shuttle: Merge to 34P14 shuttle.
Fumarole on Achim's p11: Delete, by far not the smallest.
Fumarole on Beluchenko's p13: Merge to Beluchenko's p13.
Fumarole on p18 bi-block hassler: Merge to p18 bi-block hassler.
Fumarole on Rich's p16: Delete; overtaken by Rob's p16.
Fumarole on Rob's p16: Merge to Rob's p16.
Mold on 34P14 shuttle: Merge to 34P14 shuttle.
Mold on 41P7.2: Merge to 41P7.2.
Mold on fumarole: Merge to fumarole, mention on both pages.
Mold on Jason's p22: Delete, not smallest.
Mold on Jason's p33: Merge to Jason's p33.
Mold on Merzenich's p31: Merge to Merzenich's p31.
Mold on pentadecathlon: Merge to pentadecathlon.
Mold on rattlesnake: Merge to rattlesnake.
P6 thumb on Beluchenko's p13: Merge to Beluchenko's p13.
Pentadecathlon on 37P7.1: Merge to 37P7.1.
Pentadecathlon on 56P27: Merge to 56P27.
Pentadecathlon on snacker: Delete, not smallest.
Pentadecathlon on thumb 1: Merge to thumb 1
Pseudo-barberpole on Jason's p22: Merge to Jason's p22.
Pseudo-barberpole on rattlesnake: Merge to rattlesnake.
Snacker on 38P7.2: Redirect to 38P7.2, mention on both pages.
T-nosed p4 on Merzenich's p31: Delete, not smallest.
Thumb 1 on queen bee shuttle: Merge to thumb 1 (queen bee shuttle has a lot of other uses, and this would add clutter).
Tumbler on Rich's p16: Merge to tumbler; tumbler was chosen over Rich's p16 as people wouldn't expect tumbler to have sparks.
Twin bees shuttle on 22P4.3: Delete. We don't have a page for 22P4.3, and it ties the non-LCM record anyway.
Uninteresting p24: Keep, natural.
Unix on 34P14 shuttle: Merge to 34P14 shuttle.
Unix on 41P7.2: Delete, not smallest.
Unix on Rich's p16: Merge to Rich's p16.

HotdogPi (talk) 14:15, 15 January 2022 (UTC)

Well the first entry on this list certainly didn't age perfectly.
I agree with most of these proposals, although I'd prefer it if the cases marked for deletion were instead made into redirects to the current smallest, with their existence as the smallest at one point in time given a passing mention. - AwesoMan3000 (talk) 14:10, 19 January 2022 (UTC)


I also agree with most of these proposals, but there are a few I would do differently:
258P3 on Achim's p11: Keep or merge to Achim's p11; it's historical.
134P39.1: Merge to cheater 2.
72P68: Merge to cheater 2.
74P85: Merge to cheater 2.
90P51: Merge to cheater 2.
87P26: Move 53P13 to 50P13 and merge with 50P13.
Caterer on 42P7.1: Delete; no longer the smallest.
Caterer on 44P7.2: Delete; not the smallest.
Pentadecathlon on thumb 1: Move thumb 1 to p9 thumb and merge to p9 thumb
Thumb 1 on queen bee shuttle: Move thumb 1 to p9 thumb and merge to p9 thumb
Twin bees shuttle on 22P4.3: Already redirected to a smaller LCM p92.
~Sokwe 22:00, 20 January 2022 (UTC)
If an oscillator was the smallest known oscillator with this period at some point in time, that is sufficient for me to consider it notable, even when a smaller oscillator is found - my preference would be to keep the page, and only update it to refer to a smaller oscillator found later. Confocal (talk) 06:30, 5 October 2022 (UTC)

OCA RLE

Two hours ago our site admin User:Nathaniel added a collection of other cellular automata patterns to the main page under the name of oca.zip, and I noticed something that is worth discussing.

Firstly, click on "Expand" to the right to view the list of the filenames (currently there are 75). 

1308p7.rle
2c5ladders.rle
2x210cellstilllifes.rle
2x22cellstilllifes.rle
2x23cellstilllifes.rle
2x24cellstilllifes.rle
2x25cellstilllifes.rle
2x26cellstilllifes.rle
2x27cellstilllifes.rle
2x28cellstilllifes.rle
2x29cellstilllifes.rle
2x2blockoscillators.rle
2x2glider.rle
2x2linepuffer.rle
2x2oscillators.rle
2x2period2oscillators.rle
2x2stills.rle
4c13ladders.rle
4c9ladders.rle
b3578s238replicator.rle
bomberpredecessor.rle
briansbrainp3.rle
c3ladder.rle
c3ladders.rle
candlefrobraitself.rle
croaker.rle
dayandnightfireball.rle
flutter.rle
griddle.rle
highlife10cellstilllifes.rle
highlife11cellstilllifes.rle
highlife12cellstilllifes.rle
highlife13cellstilllifes.rle
highlife4cellstilllifes.rle
highlife5cellstilllifes.rle
highlife6cellstilllifes.rle
highlife7cellstilllifes.rle
highlife8cellstilllifes.rle
highlife9cellstilllifes.rle
highlifereplicatorxp96.rle
honeyfarmgenerator.rle
jasonsbow.rle
jellyfish.rle
lifehistoryexample.rle
lifewithoutdeathquadraticgrowth.rle
longlivedsparks.rle
maze2cellstilllifes.rle
maze3cellstilllifes.rle
maze4cellstilllifes.rle
maze5cellstilllifes.rle
maze6cellstilllifes.rle
maze7cellstilllifes.rle
maze8cellstilllifes.rle
maze9cellstilllifes.rle
mazeperiod2.rle
mazestilllifes.rle
mazewickstretcher.rle
moon.rle
movepuffer.rle
movestilllifes.rle
nontnosedp15.rle
nontnosedp8.rle
pedestrianlifeobliquespaceship.rle
pedestrianlifep106gun.rle
pedestrianlife_obliquespaceship.rle
pedestrianlife_p106gun.rle
pole2rotor.rle
pole3rotor.rle
pole4rotor.rle
replicator.rle
replicatorpredecessor.rle
semitnosedp16.rle
semitnosedp8.rle
ttetrominotlife.rle
uniquefatherproblemsolved.rle

Then, the issues.

Finally, the former suggestion of creating an independent OCARLE namespace looks reasonable to me. Would this be implemented?

(Meanwhile, happy Pi day!) -GUYTU6J (talk) 03:54, 14 March 2022 (UTC)

Thanks for this. I have fixed the script so that patterns with "rule = Life" and "rule = LifeHistory" are now placed in all.zip instead of oca.zip. The script runs on the server once every 24 hours, so these changes will take up to a day to appear. Nathaniel (talk) 12:32, 14 March 2022 (UTC)
Good, how about the remaining questions? For consistency, I went ahead and fixed the nonstandard "rule = Life" in the RLE above as well as in RLE:46p4h1v0 synth, both of which were produced by User:Dvgrn. Related to the second issue, RLE:Quetzal54 appears to be generated by User:Book's personal website and the link is broken; can you rewrite the comment so as to match LifeWiki standards? -GUYTU6J (talk) 12:56, 14 March 2022 (UTC)

Redirects from misspelling

I fail to see why redirects from misspellings are prohibited. Atavoidirc (talk) 21:40, 27 June 2022 (UTC)

  • I think there are too many possible ways to misspell something (just multiply the number of letters in the title by (number of letters in the alphabet - 1) and on top of that add misspellings that add/remove/exchange letters), so that it becomes unreasonable to make redirects for them. For another example, should jrake be redirected to rake, or to krake (note that letters j and k are adjacent on a common keyboard layout), or maybe to a disambiguation page created specifically for the purpose of distinguishing possible misspellings? Some redirects for really common misspellings may be acceptable - but I think it is necessary to show explicitly that these misspellings are indeed common, and there are few such cases.
In any case, I do not think it is helpful to quickly make dozens of redirects for misspellings - it clutters the logs of recent changes for editors, and it does not seem a noticeable improvement for readers. Confocal (talk) 07:06, 28 June 2022 (UTC)
(Added later) Although the following does not necessarily imply anything specific (I think the wiki should not promote an incorrect spelling, even if it becomes common), here are results of a quick forum search: "candelfobra" - 0 matches, "candlefobra" - 0 matches, "candelfrobra" - 16 matches, "candlefrobra" - 36 matches. Confocal (talk) 12:06, 28 June 2022 (UTC)
    • Personally i think redirects from misspellings that are not just typos (e.g. Candelfobra) should be allowed. I've made this specific misspelling several times before, so i know at least one person who would benefit from it. Atavoidirc (talk) 11:25, 28 June 2022 (UTC)
My vote would definitely be to not add misspelling-redirects, and to remove any that have been added. We've already got lots of spelling and punctuation variants showing up in the All Pages lists, and those lists will get extremely cluttered if we also add every possible misspelling of every article name -- or even every reasonable misspelling.
Of course there's a checkbox to hide redirects, but the problem I see is that current policy is fairly consistent about having redirects be valid variant spellings -- terms that people have actually used or might actually use.
So if we add things like "Suprise", we're kind of implying that "suprise" is a valid name that someone has used for something. People might click on it thinking, "what's that, a pun on 'sup' so it's some kind of eater?" and then mysteriously find no explanation of why "suprise" is listed. I'd much rather avoid that unlikely potential confusion, than avoid the unlikely potential confusion that someone can't find the Surprise article because they typed "suprise".
In other words, given that the lexicon of Life terms includes all kinds of things like "Catagolue" that look like misspellings but are actually completely purposeful and have meaning... there's useful information in the current collection of redirects, and it's not an improvement to add a random scattering of misspellings that are really just misspellings. People can perfectly well figure out how to spell "surprise" right, in the incredibly rare cases when they accidentally mistype it and don't get a LifeWiki article match. Dvgrn (talk) 14:59, 28 June 2022 (UTC)
  • (Replying here to a message left at Talk:T-tetsons, since it is possible that that talk page will be deleted later:) I do not see why "T-tetsons" or "T-tetson" should mean something specific. There is a page Tumbling T-tetson on this wiki, and there is an entry "tumbling T-tetson" in Life Lexicon. There is a page Twirling T-tetsons 2 on this wiki, and there is an entry "twirling T-tetsons II" in Life Lexicon. However, I cannot find "T-tetson" or "T-tetsons" by itself in Life Lexicon. On the forums, the only example I found which might be related is in the thread "Help with names" (link) where there was an attempt to translate a set of words/terms into another language. I think that "T-tetsons" does not by itself mean anything at all, so I proposed the redirect for deletion. Confocal (talk) 00:16, 4 July 2022 (UTC)

2023

This tiki bar discussion did not finish in 2022. I think it is incomplete (for one thing, it implicitly assumes that everyone knows what this is about). Before this discussion started, several redirects-from-misspellings were created in a short timespan, without any edit summaries or other explanation. Overall, this looks like trying to anticipate misspellings before these misspellings actually happen. I do not support making lots of redirects "just in case". But one added or removed redirect does not globally change anything.
I think drawing the attention of everyone to redirects is unfortunate, because the wiki is about writing pages that describe or explain something -- redirects are a relatively minor feature, and ideally should "just work" without becoming the focus of a tiki bar discussion. Confocal (talk) 11:15, 4 April 2023 (UTC)

Category:Polyominos

I propose that recently created Category:Polyominos should be renamed to Category:Polyominoes, to follow S. W. Golomb. See also polyomino. The actual renaming will involve editing every page in the category - otherwise I probably would just do it myself. Confocal (talk) 07:15, 28 June 2022 (UTC)

Done. Atavoidirc (talk) 18:56, 14 July 2022 (UTC)

Mobile LifeWiki

Greetings from a passing wiki editor! This site looks great and well-moderated. But on a smartphone, just noticed that you don't have a Mobile frontend extension installed. Why? GUYTU6J (talk) 17:36, 2 July 2022 (UTC)

  • The linked page says: "Before installing MobileFrontend [...] you should review your content to see whether it is mobile friendly. [...] MobileFrontend will not magically fix this for you!" It seems that ensuring that the actual content will render nicely is a non-trivial task. There may be a good solution to the problem - I'm only saying that it is not obvious what is an improvement and what is not. Confocal (talk) 22:47, 21 July 2022 (UTC)

Single-digit links in templates / links with very short displayed text

There are templates such as gliders and period, which are used for embedding short (often single-digit) links to categories. I suggest to modify such templates so that links become e.g. period-3 instead of period-3, and likewise 5-glider instead of 5-glider. I think this would be an improvement because clicking on the longer link would be much easier for a reader than clicking on a single-digit link. Confocal (talk) 02:47, 10 July 2022 (UTC)

Seconded. Glider is linked from the first sentence of the category page anyway, so it should still be easy for someone to find that link.
~Sokwe 08:08, 10 July 2022 (UTC)

Small update: slcells is another similar template; there may be more. Confocal (talk) 19:17, 10 July 2022 (UTC)

I modified {{gliders}}, {{period}}, {{periodS}} to use long displayed link text in non-brief mode. Probably {{cells}} and {{slcells}} should be handled by a more experienced editor semiautomatically (because that will involve editing large number of pages where these templates are used). The current usage is like e.g.

The frobnozzle is a {{cells|22}}-bit p3 oscillator.
The snargehive is a {{slcells|6}}-bit still life.

That should be changed in articles to

The frobnozzle is a {{cells|22}} p3 oscillator.
The snargehive is a {{slcells|6}} still life.

and the templates should be modified accordingly, to provide "-bit" as part of the displayed link text. Confocal (talk) 00:16, 19 July 2022 (UTC)

Good ideas. Book (talk) 00:28, 19 July 2022 (UTC)

Missing OCA rules

Currently

  • 3D Life
  • Codd's cellular automaton
  • Critters (cellular automaton)
  • Langton's loops
    • Byl's loop
  • Paterson's worms
  • Rule 30
  • Rule 90
  • Rule 184
  • Turmite
    • Langton's ant
  • Von Neumann cellular automaton
    • Nobili cellular automata

And the following Cellular automata related topics:

  • Asynchronous cellular automaton
  • Block cellular automaton
  • Bootstrap percolation
  • Continuous automaton
  • Elementary cellular automaton
  • Lattice gas automaton
  • Majority problem (cellular automaton)
  • Mobile automaton
  • Movable cellular automaton
  • Network automaton
  • Reversible cellular automaton
  • Second-order cellular automaton
  • Stochastic cellular automaton

Atavoidirc (talk) 19:44, 14 July 2022 (UTC)

  • A minor remark: even if Wikipedia has a page about something, that does not mean that the subject of that page meets Wikipedia's notability criteria. More significantly: assuming that it is good to have a page about a certain subject here on LifeWiki, I think it would be much better to have that page written by someone who knows enough about the subject (i.e. knows what it is all about), and who is able to write it down in a clear understandable way. I think there's not much point in quickly creating lots of new small stubs that do not really provide much useful knowledge. Confocal (talk) 02:47, 15 July 2022 (UTC)

Sections for lists of patterns

There is a number of lists of patterns which can be found in Category:Lists of patterns, with multiple viewers on each page. Would it be an improvement to split such pages into sections in some consistent way? It may help readers to quickly navigate e.g. to a specific period. It may enable categorized redirects to sections for patterns without their own articles. Confocal (talk) 21:32, 21 July 2022 (UTC)

Maybe List of still lifes with 4 to 12 cells should be split into several pages to reduce its length in the all-content-shown mode. Confocal (talk) 19:45, 13 August 2022 (UTC)
Was why the sections were collapsed, which I know you oppose. But ok by me to split. Book (talk) 20:17, 13 August 2022 (UTC)
I plan to make the large sections separate pages. This is a multi-step process over several days. Book (talk) 22:13, 15 August 2022 (UTC)
11 and 12 have their own pages now. Created "4 to 10" page, however, perhaps better to move "4 to 12" to "4 to 10" to preserve editing history? Book (talk) 23:19, 15 August 2022 (UTC)
Does this mean that 15- and 16-cell oscillators should be given their own pages as well given the similar counts? - AwesoMan3000 (talk) 14:51, 22 August 2022 (UTC)
Seems reasonable. Book (talk) 18:05, 22 August 2022 (UTC)

11-cell and 12-cell still lifes

Recently, Carson Cheng added a notability tag to a decent number of 12-cell still lifes and a few 11s, and Book redirected them to List of still lifes with 4-12 cells. Confocal is arguing against this. There are now only 96 out of 121 in the Category:Strict still lifes with 12 cells category and 40 of 46 in the 11 category. In addition, the ones that were redirected are a bit arbitrary. Should the redirected ones be restored? HotdogPi (talk) 13:11, 28 July 2022 (UTC)

  • I'm currently editing pages that are not redirected, to make relatively minor formatting fixes. I'm also removing notability templates which are present in pages about 12-bit still lives, since it seems more reasonable to discuss this kind of questions for all similar pages at once, rather than one-by-one. One possible solution is to keep all pages for 12-bit SLs (and de-redirect redirected ones). Confocal (talk) 13:17, 28 July 2022 (UTC)
(Added later:) I think the same applies to 11-cell SLs. One issue with List of still lifes with 4 to 12 cells is that a significant part of the content is collapsed-by-default; I think it is usually better to have all content shown by default. Confocal (talk) 18:18, 28 July 2022 (UTC)
  • I would say that in general we do not have a good process for adjudicating notability tags. Assuming interested parties will stumble across those pages and comment on the discussion page in a timely fashion is hit or (mostly) miss. I've attempted to raise individual page issues on the forums without much success, and that's cumbersome, especially when there are a lot of open tags. I also don't think letting those tags linger interminably (and I know we all have different ideas about timeliness) is good practice. It seems to me that getting a thumbs up or down should be possible in short order, but I'm not clear on how to do this in a process-driven way. — Preceding unsigned comment added by Book (talk • contribs) 28 July 2022‎
  • Since this is somewhat off-topic in this tiki bar discussion, I attempted to write a partial answer on the forum: link to the post. Feel free to reply there. Confocal (talk) 10:28, 29 July 2022 (UTC)

I restored the 6 pages for 11-cell SLs. I suggest to restore the 25 redirected pages for 12-bit SLs as well, unless there are good reasons to not do so. I think in this case a separate page for each object is better than a single long list with mostly collapsed-by-default content. Confocal (talk) 18:35, 3 August 2022 (UTC)

The 25 previously redirected pages for 12-bit SLs are restored. Confocal (talk) 21:56, 13 August 2022 (UTC)

Should the pages for barberpoles up to at least 13 cells also be restored for much the same reasons? - AwesoMan3000 (talk) 15:35, 24 August 2022 (UTC)

Redirects

Should redirects like p52 pipsquirter be in categories? Atavoidirc (talk) 15:00, 6 August 2022 (UTC)

It would be good to state in a more clear way exactly which redirects are meant by "redirects like p52 pipsquirter". For example, categorizing redirects to sections for interesting objects without their own pages seems helpful to me. Confocal (talk) 15:10, 6 August 2022 (UTC)
This one was explicitly made to appear in Category:Oscillators with period 52 and similar. I don't expect anyone to type in the name "p52 pipsquirter"; it's meant to appear in categories. HotdogPi (talk) 18:54, 6 August 2022 (UTC)
  • In my opinion, there should be some kind of protection against someone overenthusiastically creating lots of redirects that are apparently never used anywhere for any purpose. Isn't the wiki supposed to be primarily about writing good pages (as opposed to making lots of redirects to relatively few existing pages)? Ignoring any disk space-related concerns (that may or may not be negligible), redirects require maintenance, e.g. when the content of target page changes, the redirects may need to be changed. (I'm adding this reply to an existing discussion, because the title of this section is "Redirects", and there are already at least four discussions with "Redirect" in the title - I do not want to create yet another redirect-related Tiki bar discussion.) Confocal (talk) 01:02, 18 October 2022 (UTC)

Forums error

An error occured on the forums: 

Fatal error: Uncaught Error: Undefined constant "Patchwork\Utf8\MB_OVERLOAD_STRING" in /home/psstoref/conwaylife/forums/vendor/patchwork/utf8/src/Patchwork/Utf8/Bootup.php:45 Stack trace: #0 /home/psstoref/conwaylife/forums/includes/utf/utf_tools.php(28): Patchwork\Utf8\Bootup::initMbstring() #1 /home/psstoref/conwaylife/forums/common.php(97): require('/home/psstoref/...') #2 /home/psstoref/conwaylife/forums/viewtopic.php(20): include('/home/psstoref/...') #3 {main} thrown in /home/psstoref/conwaylife/forums/vendor/patchwork/utf8/src/Patchwork/Utf8/Bootup.php on line 45

GUYTU6J (talk) 15:34, 17 August 2022 (UTC)

Popover, Pi portraitor, Pentoad 1H2, Pentoad 2

Pages Pi portraitor, Popover, Pentoad 1H2, Pentoad 2 were redirected by Carson Cheng, as far as I can tell without any previous discussion. My attempt to restore these pages was reverted with edit summaries "Added redirect; Alternate stabilizations of something known generally aren't notable on their own." and "Undone the removal of redirects by Confocal".

What should be done with these pages? I would prefer them to remain separate, to avoid overloading pages Gourmet and Pentoad. At least, such mass merges should be previously discussed and explained in edit summaries. Confocal (talk) 13:35, 26 August 2022 (UTC)

The three p32 pi variants are pretty much identical. They don't need three separate pages. HotdogPi (talk) 13:42, 26 August 2022 (UTC)

List of Life-like cellular automata

I propose that the named patterns with red links be made redirects to this page. It is where in the wiki they are defined and someone could find them and most have been long red. — Preceding unsigned comment added by Book (talk • contribs) 27 August 2022

  • These are rules, not patterns. I would prefer them to remain red links. Red links encourage people who are interested in the subject to do the documentation. In this case, redirects to a long table would not be very helpful, and would simply hide the problem instead of solving it. Confocal (talk) 22:30, 27 August 2022 (UTC)
    • I of course meant rules not patterns. I still think we should make finding these named rules easier. We do so with a lot of (this time I mean it) patterns in tables. It says "here is where you can find something about this thingy." Book (talk) 23:28, 27 August 2022 (UTC)

Imprecise redirects

Examples of imprecise redirects:

  • As stated in the reason for the proposed deletion, Cyclotron should (eventually) become an article. However, until someone becomes sufficiently prepared and enthusiastic and writes that article, it should be a red link. Confocal (talk) 00:22, 28 August 2022 (UTC)
  • People is an unused cross-namespace redirect to Category:People.
    • People used to be accessed from "all categories" but was moved to another namespace; this redirect was for people who could no longer find people. Book (talk) 00:12, 28 August 2022 (UTC)
  • title=Θ&oldid=114490 and Theta are imprecise redirects to Big-Θ notation.
    • Please see discussion tab on these pages Book (talk) 00:12, 28 August 2022 (UTC)
  • Replying here: there is no need to explain letters and their names to people who are interested in cellular automata - it is very likely that those people already know letters, and even if not, that is solved by googling it. These redirects are imprecise - the notation is not the letter. Confocal (talk) 00:22, 28 August 2022 (UTC)

(There are also redirects from misspellings, see the relevant tiki discussion.)

These redirects are not alternative ways of referring to the target page. These redirects introduce confusion instead of helping readers. Confocal (talk) 23:48, 27 August 2022 (UTC)

Proposed deletion of redirects from personal names to pages about a different subject

There is a number of redirects from names of people to pages that are not about the person (Alain Noels, Christiaan Hartman, Kees Kwekkeboom, Roger Banks, Steven Eker, and likely more). I propose that such redirects be deleted.

I believe it is unacceptable to have an imprecise redirect from a personal name. That may incorrectly suggest that the person is known only for one specific contribution (the one mentioned on the target page of the redirect), and also does not provide any context before directing the reader to another subject.

I think either there should be a separate non-redirect page for a person, or (less preferable) a redirect to a category for discoveries made by the person, or there should be no page at all (i.e. no redirect to anything). Confocal (talk) 23:19, 5 September 2022 (UTC)

Good issue to raise. It would be good to have an explicit "policy" about such things. I think we also need a similar agreement about whether and when a person should be linked at all even if there is little likelihood of the link ever having a landing (I'm thinking mainly of well-aged red links). Book (talk) 23:37, 5 September 2022 (UTC)
In general, I like red links; they are a very simple lightweight way to tell other editors "This page is missing", and they interact nicely with other available tools.
Speaking of pages about people specifically (and excluding all other LifeWiki topics), I'm inclined to agree that it's probably better to unlink long-missing pages about people. My reason is that such pages are harder to write, and the usual simple "process" of starting a short stub to be expanded later does not really work when writing about a person. Confocal (talk) 05:46, 16 April 2023 (UTC)

Catalysts vs Eaters

I have done a number of edits regarding the pages Catalyst and Eater, and the categories of Category:Catalysts and Category:Eaters to transfer content from the page of eaters to the page of catalysts. Should we simply merge these pages and get Eater redirect to Catalyst?

If so, how do we deal with the collection of glider eaters? Should we put it on another page (possibly the Catalyst page), create a new page (possibly in userspace) to accommodate it, or put it in an accessible place on the forums or in a major pattern collection on GitHub? Has this been done already?

Carson Cheng (talk) 00:15, 11 September 2022 (UTC)

What is the reason for the proposed merge? I think these changes (both already attempted and proposed) do not improve the wiki, and also are made without seeking consensus first. I suggest that Eater should remain a separate page from Catalyst, and also Category:Eaters should remain a separate category from Category:Catalysts. Confocal (talk) 01:07, 11 September 2022 (UTC)
The term eater basically refers to the term catalyst. You may argue against that, but the term eater is very rarely used now other than referring to eater 1, eater 2, eater 3, and other catalysts with "eater" literally in their names. On the other hand, the term catalyst is in much more common use, and is strongly preferred by the Life community. What's the point in keeping the page of eater? Carson Cheng (talk) 01:15, 11 September 2022 (UTC)
If a simple merge causes any confusion, we can just mention in the catalyst page that they can also be referred to as eaters, but very rarely. (talk) 01:20, 11 September 2022 (UTC)

Quoting from CGoLM&C 2.3 "Eaters": 

(...) Deleting gliders is the simplest of these tasks, and it can be done with objects called '''eaters''': still lifes[11] with the property that if a glider (or another object) collides with them in the right way, the glider is deleted and the eater suffers no permanent damage.

[Footnote 11] Strictly speaking, an eater does not need to be a still life, but still life eaters are used so much more frequently than other types of eaters that it is often assumed.

Quoting from CGoLM&C 7.1.1 "Conduit Terminology": 

(...) Back in section 2.3 we discussed eaters, such as eater 1, that can delete other objects without suffering any permanent damage. Eater 1s are very common components in Herschel conduits. They do very often act as eaters, simply deleting unwanted output gliders, or deleting blocks or blinkers or other objects generated as the active reaction passes through the conduit. However, their function is not always limited to eating.

A more general term for the still lifes that make up a conduit is '''catalyst'''. Like an eater, a catalyst is not permanently affected by a passing active reaction. It is temporarily altered (unless it is a rock as described in section 2.3.1) but eventually recovers to its original form with no permament damage. That passing active reaction is not necessarily any well-defined object like a glider, block, beehive, or blinker. Very often it is simply some unnamed chaotic mess, and the catalyst just causes it to evolve differently from the way it would have without the catalyst's presence.

As I understand from these quotes, "catalyst" is more general than "eater", in that an eater is something that deletes (or prevents from forming) some reasonably well-defined object, while a catalyst in general is not required to delete something without trace. A catalyst changes an active reaction to a different reaction; an eater changes an active reaction to the absence of active reaction.

Also I do not agree with the claim that the term "eater" is rarely used. Currently for me forum search returns 4423 matches for the keyword "eater" (some of these results are in parts of names of numbered eaters) and 2266 matches for the keyword "catalyst". At least if you just look at the numbers without investigating specific search results, it seems like "eater" is actually used more commonly than "catalyst"!

Based on the above and on my understanding of these two subjects, I think "eater" should be kept separate from "catalyst". These concepts are related, but they are not identical. I think putting different concepts into one page often results in added confusion - a page that attempts to cover two or more distinct subjects, frequently fails to explain either of those subjects in a satisfactory way. Confocal (talk) 02:11, 11 September 2022 (UTC)

I have added a few edits to the eater page to narrow down its definition on the wiki so that it's more precise (and hopefully more accurate), and also added references to section 2.3 and section 7.1 of the CGOLM&C book:
https://conwaylife.com/w/index.php?title=Eater&diff=115157&oldid=115108
https://conwaylife.com/w/index.php?title=Eater&diff=115161&oldid=115157
https://conwaylife.com/w/index.php?title=Eater&diff=115162&oldid=115161
Let me know if there are any problems.
Carson Cheng (talk) 02:57, 11 September 2022 (UTC)

But what about the Category:Catalysts and Category:Eaters? The category of eaters is a subset of the category of catalysts, so there's no need to exclude things from the list of catalysts. But how should we judge if one catalyst page belongs to the category of eaters? Carson Cheng (talk) 03:02, 11 September 2022 (UTC)

Category:Eaters can be a subcategory of Category:Catalysts. If there are no known ways for a pattern to eat something, the page can be put into Category:Catalysts only. If it is known that a pattern can function as an eater, the page can be put in both categories (so that a reader has the choice of either browsing all catalysts, or browsing only eaters). Confocal (talk) 03:30, 11 September 2022 (UTC)

Page sizes

What are (if any) current limits of reasonability/politeness for page sizes? I'm asking after looking at Special:RecentChanges and Special:LongPages. The longest pages in the main namespace seem to be around 100 kilobytes. The longest page in my userspace is currently less than 50 kilobytes. I am not expecting to get a precise answer with exact numbers. But after half a megabyte or so per page, it does look somewhat unreasonable to me. Using the wiki as a file hosting may not be the best way to use the wiki. Confocal (talk) 04:37, 14 September 2022 (UTC)

(For the record, I'm referring to these page creations currently visible in "Recent changes" including new pages with sizes 459355, 342781, 333155, 288921, 265478, 167993 bytes.) Confocal (talk) 08:01, 14 September 2022 (UTC)

Usage of a non-default viewer theme

I added to several pages patterns that use #C [[ THEME Book ]] (this viewer theme is related to the book), as an attempt to understand how to improve presentation of patterns in pages. (For my edits adding this theme, see current versions of pages LWSS, MWSS, HWSS, Blockic.) I chose this theme because I like how it displays "off" cells that were "on" differently from cells that were always "off", in the same way as in the patterns printed in the book.

The first (more specific) question here is: does #C [[ THEME Book ]] look fine in the LifeWiki? Is it a good idea to optionally use this LifeViewer theme, in those cases when it seems preferable to display history trail? Or it is better to stick with the default theme everywhere without exceptions?

I note that there was already an objection to one of my edits, on the grounds of consistency with the rest of the wiki. However, I think presentation of patterns across the wiki is currently already inconsistent in several distinct ways. For instance, sometimes static images are used - and that may be preferable in some cases but not others. Another example is that {{EmbedViewer}} is used often but not everywhere - again, there may be good valid reasons for that. Hence a second, less specific question: how to improve presentation of patterns in the wiki?

Any feedback to the above? Confocal (talk) 09:02, 11 October 2022 (UTC)

Yes to theme Book (no pun intended). Good choice for the reasons and usage you state. Book (talk) 17:45, 12 October 2022 (UTC)
I personally think that themes with history cells should be avoided on the wiki except in cases where the history cells provide a substantial benefit in understanding the pattern. With regard to the consistency issues mentioned above, many pages have static images because they were created before LifeViewer existed. Sometimes LV:viewer is used because {{EmbedViewer}} adds an additional frame and caption that is not always desired. Neither of these represents inconsistency in how the wiki is currently updated.
~Sokwe 01:31, 28 February 2023 (UTC)

One of "use cases" where I was changing the theme is when history cells make it easier to see how a certain pattern is composed of smaller parts. For oscillating patterns, currently available features of LifeViewer make it possible to show the reaction envelope, by auto-running the pattern for one complete cycle (with history cells enabled) and then auto-stopping. In p8 glider reflector, it seems to help to see how a p128 oscillator is made out of two 180° reflectors. I used the same technique in p143 Bandersnatch loop to show how catalysts are arranged relative to the reaction. There are other pages where I used "THEME Book + AUTOSTART + STOP" combination to show reaction envelopes. Would this be considered a valid use case? Confocal (talk) 02:46, 28 February 2023 (UTC)

Another common "use case" is when showing a complete glider synthesis of a pattern. I think it becomes significantly easier to understand an animated synthesis (i.e. to see "how it works") if gliders leave traces behind them, and pauses are inserted in appropriate points. An example of this usage can be seen in Amphisbaena. If anyone is interested, I think I can write a more detailed explaination for how I was formatting glider syntheses with the "Book" theme -- I'm trying to be reasonably consistent with syntheses. Thanks for any feedback. Confocal (talk) 02:46, 28 February 2023 (UTC)

Stable and Periodic

I have completed a draft of an article intended to replace the current Stable article. It has almost all the content from the current article, though reorganized to emphasize what I believe is the most common usage, along with a history section in support of that usage. I also revised the Periodic article to add what I believe is the common usage of that term, however, Confocal undid the revision so that the two article changes could be discussed in concert. So lets discuss! Book (talk) 21:39, 11 October 2022 (UTC)

  • I would suggest to start a discussion on the forum, rather than on the tiki bar. This way, more people would have chance to participate - there are more people registered on the forum than people with wiki accounts. And this issue is about the common usage of terms - not about something that wiki editors can define here. (Spoiler alert: I oppose moving the [1]oldid=116425 proposed version] to the mainspace, for several reasons, which I hope to state on the forum.) Confocal (talk) 22:04, 11 October 2022 (UTC)

Creating pages in the OCA namespace

As we all know, well maybe not, but that's not important, I have an incomplete OCA:LeapLife page, currently under my user namespace. I'm considering completing it and moving it to the OCA namespace soon, and I would like to 1. know if there's any objection to it. 2. Know what makes an OCA rule notable enough to have an entry in LifeWiki.

Additionally, it was once planned to create some subpages under OCA:LeapLife, to document the many patterns of LeapLife. 3. Is this acceptable, and will this cause any trouble to the LifeWiki? Ultimium (talk) 08:16, 14 October 2022 (UTC)

I support the idea. If in doubt about whether the page is well-written / well-formatted / up-to-date / etc., the template {{stub}} can always be added on the top of the page, as a lightweight way to indicate that it may need expansion. Subpages are already used - see for example OCA:HighLife/Bomber, OCA:Pedestrian Life/List of common objects. Confocal (talk) 09:49, 14 October 2022 (UTC)
I am fine with the proposal in the description, but not with the proposal in the title — the OCA namespace is there for a reason, and if pages on specific OCA pages are moved to mainspace, it will cause confusion over what exists in CGOL itself and what doesn't. HotdogPi (talk) 11:22, 14 October 2022 (UTC)
Apologies - fixed now. Ultimium (talk) 11:59, 14 October 2022 (UTC)

User:Ultimium/OCA:LeapLife is halfway now. Do anyone have suggestions? Especially what to say in the Oscillators section.

  • Is the current version considered ready to be moved to the OCA namespace? I do not want to move it without making sure that main contributor(s) are okay with that. Confocal (talk) 03:05, 28 February 2023 (UTC)

Regarding the censuses

Many object pages, for instance Octagon 2, state their commonness with their rank among all objects in Achim Flammenkamp's census, then their rank among only oscillators in Catagolue. Is the reason that infinite-growth patterns are excluded in Achim's census, or that it's meant to be more representative of the dynamics of ash in an infinite non-sparse universe? Is this truly worth it having (at present) (159214128553422*16**2)/(1829196*2048**2)>5312 times fewer initial random cells simulated and (159214128553422*16**2)/(1829196*2048**2*(-(1-0.375)*lg_2(1-0.375)-0.375*lg_2(0.375)))>5566 times fewer bits of entropy?

Should this information, when only given in the form of a commonness rank (and sometimes also expected number of soups per occurrence), have an infobox section instead?

Also, speaking of which, what should be done with the pages for strict still lifes with the sections stating that all with sufficiently few cells (including them) are known to be constructible within a maximum number of gliders? These aren't useful, surely, to duplicate information so much, can we assume that people looking for this information (that is numerical and conducive to being presented in tabular form) will go to Catagolue instead? Especially those with apgcode-only titles, pages here aren't necessary for lookup by conventional name if they have none. DroneBetter (talk) 13:51, 9 December 2022 (UTC)

Re: infobox -- my preference would be to leave the commonness/occurrence information in plain text. The infoboxes are already long enough, so that they often conflict with sufficiently wide viewers not fitting to the left of the infobox, and it is sometimes necessary to reorder sections to avoid that conflict. As a consequence, I'd prefer not to make infoboxes even taller than they are. Stating what is known in the text also gives more flexibility. Confocal (talk) 14:13, 9 December 2022 (UTC)
Re: synthesis -- the glider synthesis sections of pages could contain information not only about the current cheapest synthesis cost, but also historical information about when the synthesis was found, and also about previously known / alternate syntheses. Here is an example: Krake. I'm slowly adding this kind of information to pages. I think this is useful and interesting to readers - instead of just the cheapest glider cost, show the syntheses themselves and tell when/how these were found. Confocal (talk) 14:13, 9 December 2022 (UTC)

Should LifeWiki be more like the chessprogramming wiki?

It contains things like an article on general algorithms and others on things like bitwise operators (that don't pertain inherently to the nature of the problem it documents (playing chess as well as possible with finite resources), but are useful to human endeavours to solve it), should we have some (covering things that arise frequently enough in the study or implementation of cellular automata to be worth detailing with more specifics than Wikipedia) also?

Specifically, should there be pages here with contents of at least some of the sections of Tutorials/Coding Life simulators, in the instructive style of the other tutorial pages on how to set up and use various other software? Perhaps also one on writing simple row-based search programs that find oscillators and spaceships in equivalent multistate Wolfram rules for given widths in 2D ones. If we had one explaining the idea of David Buchanan's simulator (not the specifics of the conversion to YUV4MPEG but the simulation, using it as a basis for teaching (being that Python is a simple language to read, though it has doubtless been thought of before)), and perhaps even some of the ideas in my fork, perhaps such a page could link to the Stanford bit-twiddling hacks page (which may be of a great deal of interest to the kinds of people who'd be interested in such articles), or even an intermediate page here? I could create such an explanation of Buchanan's and my programs in my user area, then see whether it's deemed sufficiently useful to be moved to the mainspace, if anyone would like. DroneBetter (talk) 01:16, 13 December 2022 (UTC)

    • I don't know enough about those to do so (though I hope to one day), however I have made Tutorials/Coding Life simulators/bitwise SWAR Life (covering my program up to the three different simulation modes and implementation of manifolds), being that I have some more time on my hands now I think I will make another regarding the application of the Pólya enumeration theorem to implementing efficient indexing methods for binary matrices under symmetry eventually (after finishing and optimising and cleaning my program for that), if it's okay
    • Since the user Magma from the ConwayLife lounge taught me about the Pólya enumeration theorem, I made my "eightfold reducer" its own program (much was made when I was relatively new to Python and the rest only as a proof-of-concept, I will eventually get around to cleaning it up (optimising and reducing some things) and adding the rest of the class methods), it was originally only an implementation of my idea for exhaustively generating single canonical representations of nonequivalent states under symmetry in square boards (more efficiently than iterating over all states and discarding those that are not their own lexicographically-minimal orientation), but that I realised could have efficient indexing methods using the theorem, and I more recently made a "dimensional INT enumerator," originally for confirming the number of 3D Moore transitions in the INT rulespace table and supporting arbitrarily many dimensions but then today modified for returning closed forms for numbers of nonequivalent binary hypercubes in terms of width using the theorem, given a number of dimensions (see the comment on the gist for a brief explanation). Being that the first one only pertains to cellular automata slightly (ie. the indexing methods are useful for parallelisation, initialising the threads at the beginnings of different slices of the search space (that would be able to proceed through with the even more efficient next() method)) and the second only extremely tenuously (and to a more theoretical area of the study of cellular automata), would it be okay for me to make articles about their ideas (and explaining their implementations' specifics (such that the pages contains within them both a set of instructions to implement the idea and documentation of a functionally complete demonstration), like I did in the bitwise SWAR Life page)? DroneBetter (talk) 03:56, 30 December 2022 (UTC)

Attempting to show huge patterns in infoboxes

What is the current consensus on attempting to show huge patterns in infoboxes (with the alternative being to display the pattern in a viewer inside the text)? I am not sure whether changes like this or this are improvements. It seems like infoboxes work better for small patterns. Confocal (talk) 00:00, 20 December 2022 (UTC)

And some bigger patterns end up looking like smudged fingerprints in the infobox. But I think we need the categorization that follows from infobox, as well as the standard presentation. Maybe do both presentations? And while we're at it, maybe agree on a max width for whatever is shown to the left of an infobox? Book (talk) 17:55, 20 December 2022 (UTC)
  • I think it would be much better to have some reasonable upper limit on the width of the infobox itself, to leave enough space for the main part of the page. The automatic categorization could in principle be done in a completely invisible way without enforcing any particular layout/presentation (e.g. see {{Glossary}}). I'm not convinced that all pages need to be indiscriminately converted to infobox-based layout - being able to explain/describe/show the pattern in some reasonably good way is more important than any "standard presentation". Sufficiently large patterns simply do not fit well in the infobox. Some patterns may be better shown as images or schemes, and/or by explaining/describing/showing smaller components. Confocal (talk) 19:00, 20 December 2022 (UTC)
OK, I see the issue and the benefit. Hiding the infobox in these cases would be good, if 1)the data in the hidden infobox still functioned as usual in terms of all the things it triggers; 2) the article displayed important infobox data in its text. How does one do #1? Book (talk) 23:57, 6 January 2023 (UTC)
  • No significant updates so far, just adding links back to related forum posts for future reference: p158434 p158438. Confocal (talk) 05:43, 6 March 2023 (UTC)

Regarding programming language syntax colouring support in code blocks

It would greatly benefit Tutorials/Coding Life simulators/bitwise SWAR Life and Tutorials/Coding Life simulators/eightfold reducer if we were to have this. Also, how do I prevent linebreaks followed by indentation (which appear often in my programming, as you may expect) causing code blocks to generate others nested inside them? Neither <pre> nor <code> seem to allow this. And is there a way to have inline monospaced text (ie. without line breaks) like the Python docs? DroneBetter (talk) 17:51, 2 January 2023 (UTC)

  • What about <blockquote><pre>...</pre></blockquote>? Confocal (talk) 17:58, 2 January 2023 (UTC)
class Thingy:
   pass

def example():
   print("Hello World!")

Regarding "known" information

For instance, List of period-2 oscillators with 17 cells says there are 199 known such oscillators, implying that the explicit examples provide only a lower boun, however A056614(17)=199 and Mark Niemiec had a section of a page, entitled The 199 seventeen-bit period 2 oscillators, do these count as sufficient sources in and of themselves or should a program be provided to act as proof of the nonexistence of any more? As mentioned above, I cited my program for the confirmation of the disputed number of 3D INT transitions in the table, should this be the convention for proofs of other such values that are given in pages but currently imply that they're only accurate to as far as is known and not objective?

I don't think the OEIS would add values not known to be correct (assuming no bugs in implementations), being that they say "Thousands of people use the sequence database every day. Please take great care that the terms you send are absolutely correct. The standards are those of a mathematics reference work." as you edit a sequence, but A231427 was amended with the discovery of the rattlesnake, so perhaps not too rigorous when it comes to Life matters. — Preceding unsigned comment added by DroneBetter (talk • contribs) 21:55, 3 January 2023‎

  • Added the two references to pages for 17 cells and for 18 cells -- these links seem to be useful as ways of helping the curious reader to find more information. I think it is safe to leave "known" in -- a computer program may have bugs, a mathematical proof may have gaps, and so on. Confocal (talk) 05:18, 6 March 2023 (UTC)

Single column vs Two columns of EmbedViewer

What is the reason to restrict layout to stacking all {{EmbedViewer}} in a single column like in this edit? That could made the page overly long with much whitespace around. Well, I am not suggesting possibilities for three or more columns — which would made the page too wide — I am just curious about the case of two columns. GUYTU6J (talk) 14:42, 5 March 2023 (UTC)

Actually, I prefer three, which is what I use on my userpages. HotdogPi (talk) 15:04, 5 March 2023 (UTC)
  • The question in the first sentence appears to be about the specific edit. As explained in the edit summary, it is a revert to a single column. The reverted edit is a previous edit made by someone else (diff=126024&oldid=111614), changing the layout from single column to double column, with false edit summary stating "The last version still looks too wide for me". The edit summary is false, because the edit made the gallery more wide, not less. Confocal (talk) 15:13, 5 March 2023 (UTC)
More generally for the main/OCA namespaces, single-column galleries are preferable, because a two-column gallery already does not fit to the left of the infobox. For galleries in later sections of the page that can be reasonably assumed to appear strictly below the infobox on all devices, two columns could be used. Three columns are already too wide, even without the infobox. Confocal (talk) 15:13, 5 March 2023 (UTC)
By "looks too wide for me" I meant individual viewers, not the sum of two. Is there a demonstration for a two-column gallery failed to fit to the left of infobox? GUYTU6J (talk) 15:23, 5 March 2023 (UTC)

Is there a potential way to make it change based on screen width? On my screen, 5 columns easily fit to the left of the infobox, and 1 column leaves a ridiculous amount of white space. --Galoomba (talk) 07:33, 29 March 2023 (UTC)

  • For static images only, the <gallery>...</gallery> tag should work (example). For embedded viewers, I'm not aware of any existing solution.
    See also a forum thread for all infobox-related issues/discussions: link. Confocal (talk) 09:29, 29 March 2023 (UTC)

Adding kinetic symmetry to infoboxes

Currently, pattern symmetries are tracked by an invisible template at the bottom of the pattern page which does nothing other than add a category. I don't like this, since it's in stark contrast to every other pattern statistic which is tracked in the pattern infobox. However, the current system is in place for basically every oscillator and spaceship with time symmetry, so moving things to the infobox would take a long time and require a lot of changes. I think it'd be worth it, however, since kinetic symmetry is currently only described in the currently rather obscure kinetic symmetry page. Having this in the infobox would direct more traffic to that page, increase the understanding of kinetic symmetry in the Life community, and also make the symmetries of patterns far more obvious and clear since people wouldn't have to sift through the twenty categories each pattern is in to find out what each pattern is classified as.

Any thoughts? - AwesoMan3000 (talk) 10:54, 7 March 2023 (UTC)

It's doable. However, a script that does it automatically would also need to look at the bounding box, as the templates don't distinguish between odd and even symmetry. HotdogPi (talk) 14:03, 7 March 2023 (UTC)
Would a script even be able to distinguish between a D2_+1 pattern that flips across the edges and vertices of cells (-f+e) and a D2_+2 pattern that flips through the faces and edges of cells (-e+e)? Both are orthogonally flipping oscillators which would have odd by even bounding boxes. - AwesoMan3000 (talk) 14:24, 7 March 2023 (UTC)
  • I like the idea to add specific kinetic symmetry to the infobox (and perhaps create corresponding categories for every possible value, so that objects with a given symmetry can be viewed).
    However, on the other hand the infoboxes are already quite tall, and significantly reduce the available width for the main content that is located in the beginning of the page.
    Given that there are several related-but-distinct issues with infoboxes (as evidenced by the Tiki bar), would it be possible to discuss infobox-related questions as part of a broader discussion of infoboxes (perhaps preferably on the forum rather than on the wiki, so that forum members without LifeWiki accounts could reply as well)? Confocal (talk) 06:55, 8 March 2023 (UTC)
  • A forum thread for infobox-related issues: link. Confocal (talk) 06:19, 26 March 2023 (UTC)

"Oscillators made of still lifes"

I was perusing Catagolue (by means of my program), and found a D4_+1 oscillator comprised of still lifes, already named the half-tub harbour, that also has rarer (single-occurrence) C4_1 and D4_x1 variants. There wasn't any result for "oscillator made of oscillators," only Constellation (which seems vaguely fitting but not very), should a page be created dedicated to oscillators that are separable into still lifes (that hassle each other) in at least one phase? Are there any other such cases to document? DroneBetter (talk) 22:50, 28 March 2023 (UTC)

Amendment: I didn't notice the much more common D8_1 occurrence (due ot it having lower volatility and not appearing in my sortings) — Preceding unsigned comment added by DroneBetter (talk • contribs) 23:40, 28 March 2023

Apologies if the following is a bit off-topic; one interesting kind of oscillators is those where several consecutive phases consist of nothing but gliders and stationary objects, in such a way that the oscillator permanently becomes a strictly-lower-period pattern if all the gliders are instantly removed from one of such phases. These oscillators look quite cool and may well deserve a dedicated collection. Here's a recently posted alien example: post159731 (Catagolue). In Life, several examples are the p143 Bandersnatch loop (and its period-doubling stabilisation), this p253, this p160, the (capped) period-563 glider gun. There should be more examples, even not counting adjustable glider shuttles. (And even more, if the requirements are relaxed to allow any oscillators with temporary internal well-separated gliders.) Confocal (talk) 06:36, 29 March 2023 (UTC)

Pauses in glider syntheses

Why do most glider synthesis LifeViewer embeds have pauses in them? I get it's to see important intermediates (although sometimes it pauses before the gliders even collide) but it's really awkward to watch.
On a related note, why do they all have a copy of the final object on the right side? Seems redundant. --Galoomba (talk) 09:02, 9 April 2023 (UTC)

  • Some (not all) glider syntheses have pauses in them, because I decided to add pauses in them. I'm not aware of any previous conventions regarding of how exactly to represent glider syntheses on LifeWiki. The relatively long pause T = 20 (before the gliders collide) in particular is so that it is visible where each glider comes from, and it is easier to see that the synthesis is rewindable.
    The reason behind adding a copy of the (stationary) final object is because Mark Niemiec's glider synthesis database does this, and I did not really want to invent something entirely new from scratch, when there are existing tested ideas that can be reused in this context. Confocal (talk) 09:22, 9 April 2023 (UTC)
  • If this can be useful for setting future guidelines, I think I could write a more detailed explaination for my particular choices when formatting syntheses. Earlier I already asked about that on Tiki bar, but got no response there so far. Confocal (talk) 09:21, 9 April 2023 (UTC)
Retrieved from "https://conwaylife.com/w/index.php?title=LifeWiki:Tiki_bar&oldid=129113"