Difference between revisions of "LifeWiki:Tiki bar"

From LifeWiki
Jump to navigation Jump to search
 
(134 intermediate revisions by 15 users not shown)
Line 1: Line 1:
[[File:Taka Tiki Break 250.jpg|right|thumb|250px|Taka Tiki Break (tiki temple)]]
+
[[File:Taka Tiki Break 250.jpg|right|thumb|250px|Taka Tiki Break]]
 
<div style="clear: both; float: right; margin-left: 1em; margin-bottom: 1em; margin-top: 1em">__TOC__</div>
 
<div style="clear: both; float: right; margin-left: 1em; margin-bottom: 1em; margin-top: 1em">__TOC__</div>
 
'''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.
 
'''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.
Line 14: Line 14:
 
* See [[LifeWiki:Tiki bar/Archive/2017]] for Tiki bar discussions started in 2017.
 
* See [[LifeWiki:Tiki bar/Archive/2017]] for Tiki bar discussions started in 2017.
 
* See [[LifeWiki:Tiki bar/Archive/2018]] for Tiki bar discussions started in 2018.
 
* See [[LifeWiki:Tiki bar/Archive/2018]] for Tiki bar discussions started in 2018.
 +
* See [[LifeWiki:Tiki bar/Archive/2019]] for Tiki bar discussions started in 2019.
  
== Conduits and converters ==
+
==CiteDiscord template?==
  
I'm gradually gathering the necessary courage to tackle the new Life Lexicon items that start with "P". Looks like one of the big things I should do is to carefully figure out how to make proper use of [[Template:Reflector]], but in this modern LifeViewer age I don't think I agree with the part about "The image in this infobox should '''NOT''' include the glider that is to be reflected...". Or else the glider can start anywhere! When there was only one page for [[bumper]], Entity Valkyrie got confused of where to put the glider and when.
+
Was thinking about this since [[User:Dvgrn]] added a Discord citation to the [[Max]] article. Would there be any objections to a template to cite the [https://discord.gg/BCuYCEn Conwaylife Lounge Discord server]? It is a public server, after all, and there have been quite a few notable discoveries and developments announced there over the years. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 17:53, 16 February 2020 (UTC)
 +
: Sounds good to me. I'd also like a Templates Cheat Sheet page under [[LifeWiki:Editor_pages|How to Contribute]] somewhere, probably just a section in [[Help:Templates]]. There are examples there of how to use some templates, but for many of them I currently just go hunting around randomly in articles until I find a good example of how it's used, and then copy and modify that. As the number of templates increases, this is starting to seem more and more, um, suboptimal. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:06, 17 February 2020 (UTC)
 +
:: I know it's been two months, but [[Template:CiteDiscord]] is now up and running on the [[Max]] article. Thoughts? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:12, 17 April 2020 (UTC)
  
Seems to me these template recommendations should be updated to say something like "The image in this infobox '''should''' include the glider that is to be reflected -- optionally, two input gliders separated by the mechanism's minimum [[recovery time]], and an output glider if that allows a smoother animation. However, the bounding box and population count should be calculated with these gliders removed."
+
==Black ribbon==
 +
Briefly popping out of the woodwork to mourn [[Richard K. Guy|Rich]] --- I had the idea of adding a black ribbon in the lower right corner of pages. This is added by a bit of code in <tt>[[MediaWiki:Common.js]]</tt>, with some supporting CSS in <tt>[[MediaWiki:Common.css]]</tt>. To turn this off again, simply comment out the line that says
  
It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to goWhen copying and pasting one of these to use in a larger construction, it's usually pretty handy to have some kind of marker for where the the input goes and where the output comes from -- thus the [[ghost Herschels]] in recently added [[Herschel conduit]]s.
+
$( document ).ready(function() {
 +
    console.log( "ready!" );
 +
    addMourningRibbon();
 +
  });
  
[Ideally the marks are state-4 LifeHistory so you don't have to edit them out after pasting -- but we should probably stick with simple 2-state Life patterns on the LifeWiki and not open the LifeHistory can of worms.]
+
near the bottom of <tt>[[MediaWiki:Common.js]]</tt>. (Actually, commenting out the call to <tt>addMourningRibbon</tt> there will be enough.) Leave the rest of the code and the CSS in though; that way the ribbon can be reused next time there is a death in the community. (The link on the ribbon is set a little further up, and can easily be adjusted as needed.)
  
... And we can probably get rid of [[Template:Reflector/Doc]] while we're at it, no?
+
<s>N.B. --- the ribbon itself is a bit fiddly and doesn't always appear; I suspect this has to do with page caching, but I know too little about Javascript, Mediawiki and all that jazz to get to the bottom of it. Perhaps someone else who knows more can help.</s> Using jQuery (which, thankfully, is included in MediaWiki) fixed this, so we should now have a ribbon on all pages, always. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 10:13, 11 March 2020 (UTC)
  
Before I start this I'll definitely undertake to review all the existing converters and reflectors and conduits -- there are a bunch with raw RLE and/or uploaded pattern files missing.  That's relatively easy to fix, once we have an official decision about whether and how to show inputs and outputs.  I'm currently puzzled by the mysterious [[Template:ConduitInput]] and [[Template:ConverterInputOutput]]. Not that that's surprising -- I'm easily confused by all this wiki template trickery. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:26, 8 May 2018 (UTC)
+
: The black ribbon has been there for over ten days now; anyone want to suggest an appropriate total time period for it? I wandered over to <tt>[[MediaWiki:Common.js]]</tt> to see what would have to be done to turn it off, but found that I didn't have permission:
 +
Permissions for editing of sitewide CSS/JS/JSON files were recently separated from the editinterface right.
 +
If you do not understand why you are getting this error, see [https://www.mediawiki.org/wiki/MediaWiki_1.32/interface-admin mw:MediaWiki_1.32/interface-admin].
 +
:Luckily I had permission to give myself permission, so I can now comment out the relevant line. The Internet suggests there are common 7-day and 30-day traditional mourning periods. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:32, 22 March 2020 (UTC)
  
:I agree that reflector patterns should include the input glider. I'm the one who originally wrote that they shouldn't, and I'm not really sure why anymore.  It can't have been very good reasoning, because I completely disagree with it now.<br/>~[[User:Sokwe|Sokwe]] 07:08, 9 May 2018 (UTC)
+
::10 days seems fine to me. And yes, I had the same issue with permissions. Bit weird that MediaWiki doesn't give the relevant right to admins by default, but perhaps this is so that admins who're not aware of what they're doing won't accidentally break things. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:33, 27 March 2020 (UTC)
  
:[[Template:Reflector/Doc]] also asks users not to put animated images on pages, instead suggesting that one should "''consider using a static image of the reflector with a caption that links to the animation''". I think this does not match the general current LifeWiki practice regarding animated images, or generally animated content. Should we reconsider? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 05:25, 7 June 2018 (UTC)
+
== LifeViewer and RLE on OCA subpages ==
  
:: It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to goThere are quite a few Help documents and templates that were written long before the advent of LifeViewer. I'd love to have the Help actually explain to a new user how exactly to add RLE to the RLE namespace, how to get that RLE to show up in an infobox or an embedded viewer, how to adjust the LifeViewer config so that animations (if any) look good, etc. It will take a while to get all the docs updated, no doubt.  My edit yesterday was just a first attempt to start chipping away at the problem. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:48, 7 June 2018 (UTC)
+
I was just looking at some experimental pages that [https://conwaylife.com/wiki/User:Ultimium Hunting/Ultimium] has put together for LeapLifeFor example, the small knightship in LeapLife is called a "lepa", so it's presumably going to go under [[OCA:LeapLife/Lepa]].
  
:::Definitely agree! Unfortunately writing documentation is one of things I'm hopelessly.. well, hopeless at. ;) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 10:33, 9 June 2018 (UTC)
+
But that brings up all kinds of questions.  Look at [https://conwaylife.com/wiki/User:Ultimium/LeapWiki/Lepa Hunting's experimental Lepa page].  If RLE is added in the RLE: namespace for a lepa, and for all the other things Hunting will want to document, then those patterns will end up in the main pattern collection, right?  That doesn't seem like such a good idea. It would be nice to be able to put RLE someplace where LifeViewer can still find it, but it doesn't end up in the main LifeWiki pattern collection. We only have a few non-Life patterns so far, like [[Bomber]], but it seems as if things could get out of control pretty fast if people want to add LifeViewer support for OCA pattern articles.
  
== Lexicon tags ==
+
It seems like some different templates might be needed, to point to the alternate RLE namespace (if that gets created), and to get rid of irrelevant stuff like the links to Catagolue syntheses which won't exist for OCA patterns.
  
Many of our articles (glossary, in particular) are based on, or at least synced with, Life Lexicon content. This creates a need to update these articles when the Lexicon changes.
+
Thoughts on this?  Would it be better to skip the templates, and just recommend that OCA patterns should keep their RLEs directly in the articles, as part of embedded LifeViewer text?  Then I think the "RLE: here Plaintext: here" template won't work too well, and an alternate embedded-LifeViewer template for OCA patterns might be a good idea. (?)  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:09, 7 April 2020 (UTC)
  
Some of that has been handled in an ad-hoc manner [[User:Apple Bottom/TODO/Life Lexicon|on my userpage]], but the process is fairly involved: look at the project page, find an article to work on, make sure it needs to be worked on, make the necessary edits, make the necessary changes to the project page to reflect the fact you edited the article.
+
: I think there should be a separate category, say OCARLE: and an option in the template |rle = oca for checking specifically under that header. Either that or one of the three other options:
 +
:*Removing the pattern collection.
 +
:*Creating a new wiki for other cellular automata.
 +
:*Excluding all OCA RLE pages from the collection.
  
It's also not easily found by newcomers who may want to help out. (OK, I'll admit, there likely aren't droves of eager newcomers to begin with, but that nonwithstanding, if you don't know said page exists you're not going to find it easily.)
+
:: I agree with OCARLE. [[User:Ultimium|Ultimium]] ([[User talk:Ultimium|talk]]) 03:15, 30 May 2020 (UTC)
  
So I was thinking, can't we improve on this? And I just had the idea of tagging articles themselves instead, indicating which version of the Lexicon they correspond to.
+
:Giving a quick search for RLE:bg gives 5 RLE pages as well, all in LeapLife. I think those should be excluded even if the others can't be, especially if I'm going to create more. (and Hunting's too, afaik there's only RLE:Lepa and RLE:Crawfish so that shouldn't be too hard) [[User:Bubblegum|Bubblegum]] ([[User talk:Bubblegum|talk]]) 18:25, 29 May 2020 (UTC)
  
The Nethack wiki does something similar; for instance, take a look at their [https://nethackwiki.com/wiki/Foodless Foodless] article, and you'll find that it has an indicator at the top right saying that the page reflects Nethack 3.4.3 (rather than the current 3.6.1), generated by [https://nethackwiki.com/wiki/Template:Nethack-343 this template].
+
: I don't object to either of these ideas, just want to point out that the latter option actually won't require the creation of a new template - if ''rle'' is specified instead of ''pname'', the links won't appear. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 21:24, 7 April 2020 (UTC)
  
We could use something similar. There wouldn't necessarily have to be a visible indicator (though there could be); at the very least, though, pages could be tracked in appropriate categories, and we'd know at a glance what needs to be updated (or at least reviewed) and what's current.
+
:: I prefer to use a seperate collection instead of the RLE embedded in the page, and a template for OCA patterns, for, um, for no reason. I mean they will be easier to access and manage. [[User:Ultimium|Ultimium]] ([[User talk:Ultimium|talk]]) 06:11, 8 April 2020 (UTC)
  
This way, all edits would be in one place: review an article and make edits as necessary, and also update the tag to indicate it now reflects a newer Lexicon version. And placing those tracking categories into an appropriate supercategory and placing that in the existing category tree in turn would allow editors interested in helping out find articles in need of review.
+
::: So far, the only good way to add patterns to OCA pages is what Hunting/Ultimium has done, e.g., with [[User:Ultimium/LeapWiki/Crawfish]]. But this currently means that the crawfish RLE is going to get added to the omnibus RLE collection downloadable from the main page.  There are currently 66 OCA patterns scattered in among the 2300+ Life patterns. Might it be a good idea to split out all OCA patterns and provide a separate downloadable collection?
 +
[[RLE
 +
:::: I'm just mimicking Apple Bottom's [[User:Apple Bottom/Day & Night|Day & Night Wiki]]. I agree, we should split out all OCA patterns. {{unsigned|Ultimium}}
  
There would be two downsides. a) most of the Lexicon doesn't change in each Lexicon release, so we'd have a lot of articles tagged as (say) reflecting v28 when in fact they're also current, by virtue of not having changed since v28. And b) we wouldn't easily be able to see which articles are missing from the wiki entirely.
+
::: Also it might be worth adjusting the template used there somehow, to clearly label the crawfish spaceship in the infobox as being in a non-B3/S23 rule. (?) [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 13:49, 19 April 2020 (UTC)
  
I still feel that this would be an improvement though, and there's no reason we couldn't combine these tags with a manually-curated project page to get the best of both worlds.
+
:::: I like the current idea of adding a new OCA RLE category so they won't get lumped into the B3/S23 stuff. Yes, I think adjusting the infobox template to make it more visible that the pattern is not a CGoL pattern is worth doing. Also, there are some RLEs I'm using in some of my user pages for OCA patterns. They are [[RLE:Smosmos]], [[RLE:Sakaphipush]], [[RLE:Sakacapush]], [[RLE:Sakaw2]], and [[RLE:Sakasaladc8]] if I didn't miss any. [[User:Saka|Saka]] ([[User talk:Saka|talk]]) 13:42, 30 May 2020 (UTC)
  
Also, re: downside a) specifically, I think this could be dealt with by also having an indicator on the wiki saying which Lexicon release is current; pages that haven't been tagged as reflecting the current version would then display a gentle, unobtrusive note, and anyone viewing such a page could quickly check that it does indeed match the current Lexicon release, and update the tag if so.
+
::::: I've compiled the list of OCA RLE pages here: [[RLE:Ttetrominotlife]], [[RLE:Pole2rotor]], [[RLE:B36s245replicator]], [[RLE:Pole3rotor]], [[RLE:Pole4rotor]], [[RLE:2x2glider]], [[RLE:Awesoman3000/10p84h2v2]], [[RLE:Lepa]] (hunting version), [[RLE:Bglepa]] (bubblegum version), [[RLE:Pedestrianlifep106gun]], [[RLE:Mazeperiod2]], [[RLE:Briansbrainp3]], [[RLE:Jellyfish]], [[RLE:Sakaw2]] (i was surprised that this works), [[RLE:Awesoman3000/9p7h2v2]], [[RLE:Replicator]] (highlife's), [[RLE:Bgpsgriddleblock]], [[RLE:Tlifegatekid]], [[RLE:2x2linepuffer]], [[RLE:Bgrigel]], [[RLE:2x2stills]], [[RLE:Bgrollor]], [[RLE:Highlifefourboats]], [[RLE:Bomberpredecessor]], [[RLE:Sakasaladc8]] (same thing), [[RLE:Awesoman3000/ant]], [[RLE:Dayandnightbutterfly]], [[RLE:Mazewickstretcher]], [[RLE:Lfodmoon]], [[RLE:2x2period2oscillators]], [[RLE:Awesoman3000/hawk]], [[RLE:Smosmos]] (saka why these line-break tags with wrong-side slashes), [[RLE:Gemsc5648]], [[RLE:Dayandnightbug]], [[RLE:Dayandnightfatbug]], [[RLE:Dayandnightsnail]], [[RLE:Replicatorpredecessor]] (highlife again), [[RLE:Sakacapush]] (you know the drill), [[RLE:Crawfish]], [[RLE:Movepuffer]], [[RLE:Dayandnightflameball]], [[RLE:Drylifeflowergarden]], [[RLE:B36s245spaceships]], [[RLE:Highlifereplicatorxp96]], [[RLE:B36s245-14c300spaceship]], [[RLE:Bgstar]], [[RLE:Sakaphipush]] (i swear, all of saka's rles do this), [[RLE:B36s245gun]], [[RLE:Movestilllifes]], [[RLE:Lifehistoryexample]] (does this count?), [[RLE:Dayandnightmilkbone]], [[RLE:Dayandnightfireball]] (please ab get better names), [[RLE:Jasonsbow]], [[RLE:Dayandnightrocket]], [[RLE:Dayandnightp60fireball]] (...), [[RLE:Dayandnightp120fireball]] (is the fireball like a variable-speed ss or what), [[RLE:Dayandnighttotempole]], [[RLE:B36s245-28c1200spaceship]], [[RLE:Dayandnightp220fireball]] (aaa)
  
Thoughts? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:49, 18 July 2018 (UTC)
+
:::::I probably missed some so great
  
: This seems like a fine idea to me.  As far as downside a) goes, I think that the last year of Life Lexicon updates is highly unusual, since it involved catching up after over a decade of no maintenance at all.
+
:::::Also [[RLE:1234_synth]] uses b2s23 instead of b3s23 so that's just lovely [[User:Bubblegum|Bubblegum]] ([[User talk:Bubblegum|talk]]) 05:06, 31 May 2020 (UTC)
  
: The standard editing methodology for new Lexicon releases is to maintain a Changes section at the top of the raw Lexicon text file, carefully listing every "added" or "edited" entry since the last release, by name.  Nobody is supposed to edit a Lexicon definition without updating the change log.  This should make it trivial to find missing articles, and hopefully should also allow an easy update to the tags.  Every Lexicon entry that's not listed in the change log can be automatically bumped to the latest lexicon release.
+
== "Non-Lifelike" CAs -- cleanup suggested ==
  
: That's a lot of small changes to a lot of articles with every Lexicon release, thoughDoes it make sense to have the default Lexicon tag be just {{LexiconLatest}} or some such, with a template to display on the page whatever the latest Lexicon release number actually is?
+
[https://www.conwaylife.com/forums/viewtopic.php?p=93581#p93581 This post by BokaBB] got me looking at the rule pages that have been collected in the OCA namespace.  [https://www.conwaylife.com/w/index.php?title=Category:Life-like_cellular_automata Category:Life-like cellular automata] includes several isotropic non-totalistic rules ([[OCA:GlideLife]], [[OCA:Goat Flock]], [[OCA:Just Friends]], [[OCA:Salad]], [[OCA:Snowflakes]], [[OCA:Tlife]], and [[OCA:Wlife]], so far, and I might have missed something.) There seems to be standard wording in all of these saying " ''{Rule R} is a non-totalistic Life-like cellular automaton".  But this just plain isn't right:  a non-totalistic CA can't be Life-like.
  
: Then, for the next Lexicon release (30), we can just update the (relatively small) list of changed definitions to say "Release 29" -- and then after each definition is reviewed and patched, the tag is updated at the same time, back to {{LexiconLatest}}? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:15, 18 July 2018 (UTC)
+
The standard wording links to [[Non-totalistic Life-like cellular automaton]], which shouldn't really exist because technically there is no such thing.  I guess the right name for that article should probably be just [[Non-totalistic cellular automaton]], and "Life-like" should also be removed from [[Isotropic non-totalistic Life-like cellular automaton]] and [[Non-isotropic_Life-like_cellular_automaton]] (both the titles and the article text).
  
::I suppose that would work, but it's pretty much the opposite of what I was trying to accomplish. ;) I was thinking of this as a status checkbox of sorts where editors would check off that yes, this article has been reviewed for Life Lexicon release 30 or 50 or whatever, and any articles that lacked that virtual checkmark would automatically be herded and available for review and/or updating, as necessary.
+
Does anyone have any objection if I do a bunch of editing to fix this, before the problem gets any worse?  Or does someone really want to LifeWiki-officially redefine what "Life-like" means?  The current definition is so widely accepted that it's even [https://en.wikipedia.org/wiki/Life-like_cellular_automaton on Wikipedia]: "Life-like" implies an outer-totalistic rule, so it's '''much''' more limited than the space of isotropic non-totalistic rules.
  
::Having a "LexiconLatest" tag instead would mean checkmarks that check themselves, by default, and that we'd then have to go and un-check. That's not so different from the current approach, with my TODO page.
+
I'd like to add a couple of new LifeWiki categories (or have someone competent do it for me): one for "Other Cellular Automata" in general (Life-like '''and''' isotropic NT rules), and one for isotropic NT rules specifically. At the moment it seems kind of hard to find a category page for all OCA: namespace articles -- you can't just search for "OCA" or "OCA:" (right?)
  
::But you raise a good point. We have a log of Life Lexicon changes, and once we're actually caught up with the Lexicon in general all we'd have to do is keep an eye on those. Hmmm.
+
If we want to be really brave, we could make the isotropic NT category something like "Iso-NT".  If that caught on -- big "if" -- then there would finally be a short standard way to say "isotropic non-totalistic".  Maybe someday people could just say "isont" or "anisont" and expect to be understood. ("Aniso-NT" would be the equivalent category for "anisotropic non-totalistic", but there doesn't seem to be any point in creating that category since nobody's come up with a rule worth naming in that rulespace yet.)
  
::Here's a thought, admittedly a rather complicated one. How about we do both? That is to say, how about a tag template that has ''both'' an explicit parameter ''and'' uses a default "low watermark", displaying the higher of both?
+
... If anyone '''does''' have an objection, please suggest something we could do instead! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:40, 7 April 2020 (UTC)
  
::The explicit parameter would be used by editors to indicate that a page has been reviewed/updated to reflect a certain Lexicon release; the "low watermark" (kept in a template of its own) would be updated by us whenever we're sure that ''every'' Lexicon-related entry reflects a certain Lexicon version.
+
: This is probably a bit late, but I think those bunch of edits are a good idea (Which it appears you have not done yet). And yes, I do agree with defining "Life-like" as strictly for Outer-totalistic rules. Nope, you can't just search "OCA" or "OCA:", so yeah, it's currently impossible to find a category with all the OCA rules and nothing more: The "Life-like_cellular_automata" category doesn't include LTL and multistate rules, while the "Cellular_automata" category also lists a bunch of non-rule pages such as the general articles for rulespaces and the lists of rules investigated on Catagolue (which, aren't they obsolete?).
  
::For instance, assume that all our articles conform to Lexicon release 30. Suppose that release 31 comes out now. We then go through the changelog, edit all articles that need updating, and after that's done, we conclude that no further changes are necessary, and bump the "low watermark" to 31, thus causing ''all'' articles (that reference the Lexicon) to declare that they match release 31.
+
: Back on the definition of "Life-like", the inclusion of IsNT (Isotropic Non Totalistic) rules in the category of Life-like CA on the wiki will probably make new CA-Enthusiasts think that they are included in Life-like CA, which might have an effect on the forum.
  
::One advantage of this would be that we'd still see when an article was last ''explicitly'' reviewed. For instance, an article might say it reflects Lexicon release 31, but the "version=" parameter might still say it was last reviewed for 28. If nothing else, this would make it easier to spot articles that haven't been reviewed for a long time and where discrepancies might've crept in.
+
:Also, over on the Discord the standard way to write "Isotropic Non-Totalistic" quicker seems to be "INT", and Heavpoot suggested (somewhat jokingly?) "AINT" for "AnIsotropic Non-Totalistic" (Perhaps "AiNT" is better), or we could just refer to them as "MAP Rules", although yeah, that isn't very good, as MAP includes Isotropic and totalistic rules as well. [[User:Saka|Saka]] ([[User talk:Saka|talk]]) 14:04, 30 May 2020 (UTC)
  
::Another idea: we've already got [[Template:LinkLexicon]] to link to Lexicon entries. We could repurpose this to also additionally display a tag, which would save us the need to edit 831 articles just to add a tagging template.
+
:: Not only Discord uses this name - "INT" is also well known on the forums. [[User:Ultimium|Ultimium]] ([[User talk:Ultimium|talk]]) 22:00, 4 June 2020 (UTC)
  
::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:50, 19 July 2018 (UTC)
+
== Expanding Covered OCA Rules ==
  
::: This all seems reasonable to me -- especially sneaking a displayed tag into [[Template:LinkLexicon]].  Now that Golly 3.2 and Release 29 are safely out the door, I'm sorta kinda planning to get back to work on the LifeWiki ToDo list for Lexicon updates, with the intention of getting everything up to date eventually -- hopefully well before Release 30 comes along to confuse things any moreWe already have some kind of a tracking system set up for Release 28 and 29, so maybe it makes sense to keep using that, and design the new template/tag system to really come into use once everything has been updated to Release 29.
+
Does anyone think that having articles for rules beyond Life-Like and Isotropic Non-totalistic should be on here, like Wireworld or Langton's Ant? These would still go under the OCA namespace, obviously. If anyone has any thoughts on this, that would be great. [[User:AforAmpere|AforAmpere]] ([[User talk:AforAmpere|talk]]) 5:02, 16 April 2020 (UTC)
 +
: As far as I'm concerned, articles for any reasonably well-known rule would be very welcome in the OCA namespaceWireworld and Langton's Ant definitely count as good examples.
  
::: So in early 2019, if we end up with a list of say fifty articles that have changes for Lexicon Release 30, my thought would be to update just those fifty articles to specifically say "Release 29" (however we decide to do that exactly -- maybe with a template saying "this article is out of date, please help out by updating it"?).  Then bump up the "low watermark" to 30 right away.  As articles get updated, the "please help" template can get removed again with the same edit. Does that work? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:49, 19 July 2018 (UTC)
+
: A big reason for inventing the OCA namespace was to provide a place for this kind of information, without accidentally cluttering up the "Life" part of the LifeWiki. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:08, 19 April 2020 (UTC)
  
::::OK, cool. :) Good to hear you'll have some time to devote to the Lexicon-to-LifeWiki TODO list. I'm not able to put in much effort there myself --- too much studying, too many exams. Ah well.
+
: I would like to contribute to these pages. [[User:Ultimium|Ultimium]] ([[User talk:Ultimium|talk]]) 02:00, 20 April 2020 (UTC)
  
::::Re: marking e.g. fifty articles as needing updates and everything as conforming to e.g. release 30 by default --- that would be a lot easier if we had Lua scripting available! MediaWiki's templates only go so far and aren't really meant for pushing lots of structured data around.
+
Mmm, a similar discussion took place three years ago, see [[LifeWiki:Tiki bar/Archive/2017#Lists_of_rules]]. Speaking of articles for other cellular automata, how about those red links in the [[list of Generations rules]]? There are a variety of rules, and therefore it will be a huge amount of work if we want to write a page for each. Or should we consider their historical/current significance first? Need Generations experts here. (I dislike red links...Wait, I shouldn't show personal feelings here.) [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 16:50, 13 May 2020 (UTC)
  
::::Our options there would include at least the following:
+
:: Personal feelings?  Nah, that's just on the actual article pages.  I really like red links, because they encourage other people to do documentation work... It would make sense to me to add a page for each of the major Generations rules in the [http://psoup.math.wisc.edu/mcell/download.html old MCell 4.20 collection], just for starters. There's usually some descriptive text that could be lifted out of Mirek's representative {RULENAME}.mcl file, as a starting point.
  
::::# Manually edit each of those 50 articles (e.g. by setting an extra template parameter) to override the "low watermark". Not ideal --- we might as well just edit those 50 articles to update them if we're already editing them anyway.
+
:: The named Generations rules in the MCell pattern collection are Banners, Bombers, Brain 6, Brian's Brain, Burst, BurstII, Caterpillars, Chenille, Ebb&Flow, Ebb&FlowII, Faders, Fireworks, Frogs, Glisserati, Nova, Rake, SediMental, Snake, Spirals, StarWars, Sticks, Swirl, Transers, TransersII, Wanderers, and Worms. There's also an "Other Rules" folder, but it has just a couple of patterns in it -- one in the Star Wars family, and an unnamed explosive one (345/24/25) with a side-effect production of some Rule-90-ish behavior. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:08, 30 May 2020 (UTC)
::::# Provide a global "kill switch" for the low watermark that, when set, causes the low watermark to be ignored. Pages explicitely listing a conforming Lexicon release would then display that instead, so those 50 "release 29" articles would show up in the right category, etc. Also not ideal --- there might be many other articles that would also have the explicit "reviewed for release 29" tag, or older tags at that, which would NOT need to be updated.
 
::::# Keep a list of those 50 articles, and rig the template to display a notice if the title of the transcluding page happens to be on that list. '''Also''' not ideal --- we'd have to curate that list, and as I said, MediaWiki templates aren't really meant for this sort of thing.
 
  
::::Maybe there's another solution I'm not seeing, though.
+
::: Right, I've made attempts to write for [[Star Wars]]. It still needs some content about various constructions before releasing to the OCA namespace, but I lack time now. (EDIT: I've released it on June 22, further compositions welcome!) [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 03:21, 19 June 2020 (UTC)
  
::::That said I also have a feeling we're trying to overengineer the solution, though, or perhaps attacking the problem from the wrong angle. After all, what do we want to do? Keep the LifeWiki current as far as Lexicon content goes. How do we achieve that? By importing Lexicon as necessary, and (once done) keeping an eye on changes made to the Lexicon and mirroring them on the wiki (again, as necessary). And how do we do ''that''? By rolling up our sleeves and working on it. Fancy templates and tagging nonwithstanding we won't get anywhere if we don't just jump in and do it.
+
By the way, putting a somewhat off-topic request here: can we integrate a LifeViewer equipped with command RANDOMIZE in Template:Rule? The command is for generating a random 64×64 soup upon launching the viewer (or refreshing the page):
 +
{{EmbedViewer
 +
|rle = x = 0, y = 0, rule = B3/S23
 +
!
 +
|viewerconfig = #C [[ RANDOMIZE THUMBLAUNCH OFF THUMBNAIL THUMBSIZE 2 ]]
 +
|caption = An example soup in rule B3/S23
 +
}}
 +
It works well with 2-state rules. For rules with more states, like Generations, more commands is needed to specify which state to use. [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 06:05, 22 June 2020 (UTC)
  
::::<small>(And by "we", I mean whoever's willing to do that job.)</small>
+
== Criteria for notable INT rules ==
  
::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 18:16, 20 July 2018 (UTC)
+
The discussion at [[LifeWiki:Tiki bar/Archive/2019#Non-notable isotropic rules]] inspired me to move OCA:Wlife to User:Evin/Wlife. Previously the reason for proposed deletion was "non-notable rule; forum thread only has 9 posts in total". Sounds reasonable, right?
  
:::::Re: overengineering... yeah, offhand I don't see a better solution than the first one: manually edit 50 articles, copying and pasting the same "stub"-like template marker in as a header.  This is a bit tedious, but that's what multiple browser tabs are for, and it can be done pretty easily in half an hour or so.  The idea is that we can make a little bit of effort to spread the update work around.  (Here "we" means the small group of people who have done the work so far -- a small group because it's kind of tricky to do everything right, so not many people have figured out all the fiddly details.)
+
But then here come the questions. Can we develop some universal criteria for a section in [[LifeWiki:Notability]] about an INT rule? Which rule warrants an article on OCA namespace, and which rule is at most qualified for a User subpage? Rules differ greatly in behaviour and potential for interesting technology, but still I think "Well-explored syntheses", "Turing-complete", "Orthogonoid/Demonoid engineered explicitly", or something along these lines, may suffice for the judgement.
  
:::::I can add "needs Lexicon update" headers to 50 articles in half an hour, but I sure can't do a careful comparison and repair on 50 articles, especially if it will require adding new illustrations or modifying existing ones.  But it seems to me that there's a larger (and growing) population of LifeWiki users who can perfectly well review a particular Lexicon definition when they trip over a "needs Lexicon update" template header begging for help.  Often it isn't too hard to find what needs changing, make the required edits, and remove the "needs Lexicon update" tag at the same time.
+
Related, should we encourage users to write about their custom INT rule ''in their User subpage first'', and move it to the official OCA namespace after reaching a consensus that it is well-developed and notable enough according to some guideline? [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 02:52, 3 June 2020 (UTC)
  
:::::Every one of these articles that someone picks up and fixes, is one that I don't have to do myself... and in the meantime, a half hour of work has already brought the LifeWiki more up to date, by specifically flagging the fact that there's newer information somewhere else that needs to be integrated into the article. Seems like this might be a good habit to get into, for as long as the Life Lexicon is kept more or less in synch with current reality.
+
: I don't think that a rule has to be Turing-complete and have a Orthogonoid/demonoid to be interesting / to warrant their own wiki page, but that's just my opinion. Making a universal definition for interesting INT rules will be hard, as is making a strict definition of interesting anything. But if we do make one, maybe we could judge the rule by it's activity as well? Number of active explorers, number of (useful / constructive) posts in the rule's thread (that are related to the rule, not off-topic chatting), that kind of stuff. One problem I can see with that approach, however, is that some genuinely interesting rules do get unnoticed, but maybe that's outside the scope of this... discussion?
  
:::::Sound reasonable? And could you have a look at [[Template:NeedsLexiconUpdate]] and see if it has everything in it that this plan might need? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:02, 20 July 2018 (UTC)
+
:On the last part, yeah, I think that's a good idea. Related to that, is the wiki O.K.a.y. with a bunch of pages under the userspace? We already have a good amount, and if we encourage that we'll have some more. Also, maybe encourage users to write a page under their username if they think their rule is interesting enough (Maybe that will slightly decrease the number of user subpages?).
  
::::::Redirect pages don't need any markers saying they're from a Lexicon entry -- do they?  I've been trying to rebuild some momentum by getting the remaining redirects done... [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:57, 26 July 2018 (UTC)
+
:I don't think we should have strict guidelines but rather a board / panel of people that will decide if a rule warrants a wiki page.
  
:::::::Cool, good to see this is already progressing. Good job! :) I'm a little less swamped now, so I'll take a look at the Template'n all over the weekend.
+
:EDIT: I forgot, I do think that the current Wlife page is a bit too empty to be in the official&trade; OCA namespace. [[User:Saka|Saka]] ([[User talk:Saka|talk]]) 04:55, 3 June 2020 (UTC)
  
:::::::No, I don't think redirect pages need markers. I don't consider these "content" in the strictest sense, in either the Lexicon or the LifeWiki --- they're just tools that help people ''find'' content.
+
:: Well, the activity of a rule is indeed another possible consideration, though more subjective. Besides quantity, explorers and posts are also of different quality, which is more related to the rule's ''known'' interestingness. Also time is an important factor here, as understandings usually cumulate over time. (Of course, given infinite time and adequate utilities, genuinely interesting rules are bound to be realized and explored in-depth, eventually warranting an OCA article.)
  
:::::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 08:31, 28 July 2018 (UTC)
+
:: Pages under User namespace are not offical, they cannot be found in the simple search on the main page unless you add "User:". They record semi-interesting stuff with potential to be officially notable. For notable rules this can be a primary filter. But wait, what if someone wants to contribute to a rule under someone else's user space?
  
== Object frequency classes ==
+
:: If the secondary filter for notable rules were to be a group of people, there could sometimes be conflicts of intererst and other complex issues. [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 07:50, 3 June 2020 (UTC)
  
I do apologize for my somewhat extended absence. That said, I had an idea (long ago actually) about adding information on the commonness of objects to pattern infoboxes, using data from Catagolue (specifically, B3/S23/C1).
+
: Sorry for non-constructive comments, but well-developed syntheses seems like a personal bias rather than an actual factor of rules' interestingness. Others seems good enough to me. [[User:Ultimium|Ultimium]] ([[User talk:Ultimium|talk]]) 11:01, 4 June 2020 (UTC)
  
I don't think saying "this still life is the 1,691th most common object on Catagolue" is useful, of course. What I'm proposing instead is the frequency class, defined as follows: a pattern is in frequency class X if the most commonly-occurring object (the [[block]], in this case) is 2<sup>X</sup> times more common. X need not be an integer; to strike a balance I'd suggest using one decimal digit.
+
== 2-state rule cleanup ==
  
Let me give an example. The [[twin hat]] has appeared 240,372,408 times on Catagolue (as of this morning), whereas the block has appeared 71,146,901,659,666 times. So the block is approximately 295,986 &asymp; 2<sup>18.17517</sup> times more common, and the twin hat's frequency class is 18.2, rounded to one decimal digit.
+
Yet another discussion on the non-Life part of the wiki... I noticed that User:Ian07 [https://conwaylife.com/wiki/Special:Log?type=delete&user=Ian07&page=&wpdate=2020-02-15&tagfilter=&subtype= deleted] a few pages (Tq6, Movingstrings and Lotsofdots) under Rule namespace on Feb 15 due to "2-state rule, no ruletable needed".  
  
I think this is a fairly intuitive way of capturing commonness. An additional nice property is that if an object has occurred sufficiently often, its frequency class is unlikely to change much, if at all; this is true even for objects whose commonness is very similar and who might switch ranks regularly, with one or the other having occurred more often at any given moment. So once this information's added, we wouldn't need to edit it much, if at all ever.
+
At the time of writing there are [https://conwaylife.com/w/index.php?title=Special:Search&limit=100&offset=0&profile=all&search=%22num_states%3D2%22 73] pages with 2-state range-1 rules on a 2-dimensional square grid. Since they can all be described with MAP strings, I suggest discarding these pages like the previous examples. We need to do the following:
  
Like I said, only sufficiently common objects should have this information added; there's too much uncertainty about the frequency class of an object that has only appeared once, say. I unfortunately lack the statistical background to suggest a good cut-off value ("objects should only have this information in their infoboxes if they have occurred at least ''n'' times"), but unless there are objections I'll add this, or at least do the necessary template work.
+
#Look into the rule tables and figure out their MAP strings,
 +
#Submit the rule names as aliases of the MAP strings, or edit the (if) very few instances mentioning the <s>manes</s> names on the forums.
  
...heck, I'll just go ahead and do it, it's been a while since I've edited anything here. If anyone thinks that this is a load of bull, please just speak up and say so. :) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 17:56, 1 September 2018 (UTC)
+
Does anyone want to help? [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 15:47, 4 June 2020 (UTC)
  
(P.S. --- although the block is the most common in B3/S23/C1, it isn't necessarily for other B3/S23 censuses; in some symmetries, the [[blinker]] is more common.)
+
:: Here are a couple of initial contributions:
 +
::: 1) For a few of these rules, the thing that makes them rule-table-worthy might be not the rule but the associated icons. HexLife and Pentagonhood are examples, I think.
 +
::: 2) I ''think'' that the "figure out the MAP strings" part can be done fairly simply with a version of [https://conwaylife.com/forums/viewtopic.php?f=&p=58143#p58143 this MAPper Lua script], by installing each rule in Golly, running the script, and copying out the reported MAP string.
 +
:: Thanks for working on this!  Rule namespace maintenance is a big job for one person, but hopefully many hands can help lighten the work. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:48, 4 June 2020 (UTC)
 +
:::: Once the aliases are submitted LifeViewer will prefer them to any Rule namespace definition. Regarding Icons: at some stage I'll add support for Icons but it won't be any time soon. For Hex neighbourhood rules there is a [[MAP]] format that supports these and will cause LifeViewer to use hexagonal cell display. There's also a VN MAP format but visually it uses square cells like Moore. Help->Info->Pattern will let you know whether LifeViewer is using a Rule namespace definition (there will be a Type of @TABLE or @TREE if so). [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 03:52, 5 June 2020 (UTC)
  
:Replying to myself, I've started doing this; there is a new template parameter, <tt>fc=</tt>, currently only for [[Template:Stilllife]], [[Template:Oscillator]], [[Template:Spaceship]] and [[Template:Puffer]] (no other types of object have appeared on Catagolue anyway). I've also added a short glossary entry at [[Frequency class]], and added frequency calss data to a couple of object infoboxes, including all with FC &le; 10.0. The script used to generate the necessary data from Catagolue's [https://catagolue.appspot.com/textcensus/b3s23/C1/ textcensus] is this:
+
:::: Good. Besides a spelling fix, I have a few minor questions:
 +
:::: Is there a page which lists those aliases, so that one can search (with Ctrl+F) through/copy them?
 +
:::: The rule tables were added to LifeWiki in an "auto-import project". Where can I see the details of the project? Can it be modified so that 2-state rules are not collected?
 +
:::: Do we need to archive the references on the rule pages? [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 06:47, 5 June 2020 (UTC)
  
<pre>
+
::::: You can see the list of aliases in LifeViewer with Help->Aliases. While the Help is displayed pressing Ctrl-C copies the topic to the clipboard.
#!/usr/bin/perl
+
::::: For the auto-import project [[User:Dvgrn|Dvgrn]] wrote the script to scan the forums and find the rules. I then used the output from this to create the required rule definitions (adding @TREE sections where missing) which he then uploaded to the Rule namespace. Built-in rules (like B3/S23 etc) and existing LifeViewer aliases were filtered out. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 09:11, 6 June 2020 (UTC)
  
# usage eg.:
+
: Re: auto-import scripts --
# perl ../frequencyclasses.pl b3s23.C1.txt >frequencyclasses.txt
+
: That project was a one-time effort, and nobody is currently planning on ever running [https://github.com/dvgrn/b3s23life/tree/master/conwaylife-scrapers those scripts] again.  They were a combination of one-off Python scraper scripts and some Selenium automation trickery.  From now on, as new rules get created, there will be a strong incentive for anyone posting new-rule patterns to the forums, to just throw a copy immediately into the Rule namespace, so that LifeViewer can display those patterns.  So -- at least according to my theory -- there's no need to run any further automated surveys to try to pick up new rules posted on the forums.  We'd get a lot of duplication and possible conflict headaches, for no obvious benefit.
 +
: A survey that '''could''' be done is to run back through old posts and look for old-style rule tables. There are a few of those that were missed because they don't have the @TABLE keyword at the top of the code block. But I think most of the commonly used rules have long since been converted to @TABLE format, so this would just pick up a few out-of-fashion rules from the early 2010s.
 +
: The auto-import script that _is_ run semi-regularly, every month or two, is the one that takes new embedded and infobox patterns from the RLE namespace and turns them into commented patterns added to the all.zip LifeWiki pattern collection. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:29, 19 June 2020 (UTC)
  
use Modern::Perl '2016';
+
:Alright, I'm done. Here's the list of aliases I created:
 +
*Bigship - B2ei3eiqry4ny5ajkr/S23ajkr4jnry5inq
 +
*WolfVN-W50_B14_S34V - B2an3cjr4acij5nqy6ak/S2cn3cqy4cny5e
 +
*B2ex3-lS23 - B2en3-a/S23
 +
*randomnn - MAPA1Az8wMAqgAAUADAAAAAAAAAgMAAAIAAgICAwAAAgAAAAAAAiACqAAAAAAAAAAAAAACAAIgAgACAgIAAAACAAA
 +
*water - MAPABAbrwAA//8AQltdAAD+/8Aa/f8AAP//YgD//wAA//8AAP//QAD//wBA//8AAP/fAgD3+wKA//8AIPZ/AAD//w
 +
*B45_S034_N21 - B2ei3-ce4cny/S02-cn3cinqy4c
 +
*HexLife (Saka) - B3o/S234-o6
 +
*rules6 - MAPAgl/+0Ug/fVAIv/9AADdPwDi9/uAQft5qIDtlQgA/b8gAP//AAD//wAQv/8AAP7+AhD/+gAA/f8EAv//AID//w
 +
*x-rule - MAPBSB64CCTqARFBImEADAGBSCTgICTSIAAADCFCSTAAAANAMEUBCKEBchCE00YAE3IACSFACCIQQDIIF4UIIAGSA
 +
*pentagonhood - MAPEWYRZmaIZogRZhFmZohmiGaIZoiIAIgAZohmiIgAiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB
 +
*B578_S4567_N31 - B3-ce4aikqtwz5e/S2-cn3-ce4cny5e
  
# only patterns with more than $cutoff occurrences should be considered.
+
:Notes:
# mark all other patterns with an asterisk.
+
*B45_S034_N21 was anisotropic as a .rule file, but intended to be isotropic.
our $cutoff = 10;
+
*The original name of HexLife (Saka) was just HexLife.
 +
*B578_S4567_N31 simply did not work as intended. The inferred rule preserves everything described except the r-pentomino, which should just be an error in the original. I don't know.
  
# throw away header line
+
:I'd say HexLife (Saka) and pentagonhood should stay where they are due to their @ICONS sections and everything else could be cleaned up. <br />
<>;
+
:Also hey, did you know you can customise your signature? <span style="font-family:Palatino,serif">[[User:Bubblegum|<span style="color:#00BFFF">bubblegum</span>]]-[[User_talk:Bubblegum|<span style="color:#BF7FFF">talk</span>]]|[[Special:Contributions/Bubblegum|<span style="color:#FF7FFF">contribs</span>]]</span> <span style="font-family:Palatino,serif">00:33, 29 July 2020 (UTC)</span>
  
my %objects = ();
+
== Topics article suggestion ==
my $mostcommon = -1;
 
my $mostcommoncode = "";
 
while(<>) {
 
    chomp;
 
    next unless m/^"([^"]*)","(\d+)"$/;
 
  
    my ($apgcode, $count) = ($1, $2);
+
Some thread-digging found a [https://www.conwaylife.com/forums/viewtopic.php?p=25135#p25135 post] listing the topics in Game of Life. Anyone putting it on the LifeWiki? I have little time on this. [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 06:10, 18 June 2020 (UTC)
    $objects{$apgcode} = $count;
 
  
    if($count > $mostcommon) {
+
: It would be really interesting to try to come up with a list of all of the esoteric sub-fields of Conway's Life that have been studied over the last five decades, including whatever links and references are available for each topic.  OCA topics should have their own list, no doubt, for stuff like record-breaking RROs, Spaceships Made of Spaceships, the 5S project, micro-Orthogonoids, etc., etc.
        $mostcommon = $count;
 
        $mostcommoncode = $apgcode;
 
    }
 
}
 
  
my %frequencies = ();
+
: Let's see, here's [https://www.conwaylife.com/forums/viewtopic.php?p=17109#p17109 one more list for Conway's Life] to be integrated.  Also two more lists of topics have now been cleaned up a bit and dropped in [[User:Dvgrn/Life_Topics]]. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 20:21, 18 June 2020 (UTC)
foreach my $apgcode (keys %objects) {
 
    my $frequencyclass = sprintf("%.1f", (log($mostcommon / $objects{$apgcode})) / log(2));
 
    $frequencies{$frequencyclass}->{$apgcode} = $objects{$apgcode};
 
}
 
  
foreach my $frequency (sort { $a <=> $b } keys %frequencies) {
+
:: That's a wonderful toplevel design! Actually the list in my quote was adapted from that in yours. By"LLLS" in volume VII it means LSSS, right? Also, where would [https://www.conwaylife.com/forums/viewtopic.php?f=9&t=3942 Project von Neumann] and existing tutorials on LifeWiki go in this scheme? [[User:GUYTU6J|GUYTU6J]] ([[User talk:GUYTU6J|talk]]) 03:44, 19 June 2020 (UTC)
    foreach my $apgcode (sort { $frequencies{$frequency}->{$a} <=> $frequencies{$frequency}->{$b} } keys %{ $frequencies{$frequency} }) {
 
        print "*" if($frequencies{$frequency}->{$apgcode} <= $cutoff);
 
        say "$frequency\t $apgcode\t $frequencies{$frequency}->{$apgcode}";
 
    }
 
}
 
</pre>
 
  
:(I'm sure there's better ways of doing this, but this worked for me.) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 18:52, 1 September 2018 (UTC)
+
::: Ha, yes, LLLS is a typo, now fixed.  Project von Neumann hasn't progressed far enough yet to deserve a place on the list, probably.  Maybe give it a few more years.  I at least won't be spending time on it until the Life textbook is all wrapped up and out the door.
  
::Another reply to myself --- [[User:Goldtiger997|Goldtiger997]] [http://conwaylife.com/w/index.php?title=Tumbler&curid=703&diff=46374&oldid=41650 suggested] a cut-off value of 10 (non-inclusive). This strikes me as sensible. So unless there's objections, how about we run with this, and only add frequency class information to objects having appeared more than 10 times?
+
::: Good suggestion on the tutorials. I've gone through the outline and added a few items, and added links to tutorials when they're available. Will try to go back and annotate everything else that's mentioned in the outline, a volume at a time... might take a while.
  
::Also --- right now the information is [[Catagolue]]-specific, which is sensible but still somewhat arbitrary; if we want to include more information later (e.g. from Achim's, Andrzej's and Nathaniel's censuses, or from whatever future censuses people may come up with), we can easily adjust the infoboxes to include a new "Commonness" section, and re-interpret <tt>fc=</tt> as "'''f'''requency in '''[c]'''atagolue". [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:08, 2 September 2018 (UTC)
+
Except for "Volume 1", which will actually become a generally-available PDF sometime in 2021, I suppose the outline is kind of heavy on specific patterns and light on general theory.  Maybe the "list of topics" should really be an article, separate from my "outline of explanations of large constructions" (which probably doesn't rate an article).  As I add more "volumes", I guess some of the later ones get more into covering higher-level topics, but it's probably a confusing way to organize things for a general audience. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 12:40, 19 June 2020 (UTC)
  
:::Sounds good. However, I already broke my "suggestion" of the 10 occurence cut-off twice; for the [[Coe ship]] and [[Achim's p8]]. Is it worth removing the <tt>fc</tt> parameter for those two articles, or should they just be left as they are? [[User:Goldtiger997|Goldtiger997]] ([[User talk:Goldtiger997|talk]]) 09:26, 2 September 2018 (UTC)
+
== Embedded-viewer variant collections ==
  
::::I think we can grandfather those in --- would be good if you could keep an eye on them in case the information changes, of course, but it's just two articles, so that should be fine. I've also added the cutoff of &gt;10 to the script above; patterns not reaching that cutoff are marked with an asterisk. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:35, 2 September 2018 (UTC)
+
I just tried some experiments with using embedded viewers floating to left, right and center, in the [[Fx77]] article.
  
==Infobox vs. EmbedViewer==
+
It looks like it's always going to be a little tricky to get this kind of viewer stamp collection to flow correctly on the page, cooperating with the infobox -- at least, unless someone can put together some very very clever templatesIt seems to be far beyond my web layout skills.
All this interminable Life Lexicon import work has been leading me to believe that there are two classes of articles that can use LifeViewer animations.  There are the named patterns, where if you say "Pattern X" there's really only one likely Pattern X that you could be referring to.  These get put into an infobox category, with appropriate statistics collected and so forthThe most recent example of this kind of imported Lexicon article is [[line crosser]].
 
  
The other class of article is for a term that might refer to a variety of different patterns, so that there are various examples but no specific example should really be considered to be the one canonical one. In these cases I've been using an embedded viewer but haven't been bothering with an infobox.  The most recent examples along these lines are [[line-cutting reaction]] and [[line-mending reaction]]I like the way these are turning out, but am curious to hear if anyone thinks that these should also be infoboxed somehow, or if anything else should be added as standard practice[[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 09:45, 12 September 2018 (UTC)
+
I found that the old trick of adding <pre><div style="clear:both;"> ... </div></pre> '''almost''' worked well for flow control -- for example, to force the centered Fx77+R64 to drop below the two Hersrch Fx77 variants, Fx77S and Fx77SWThis looks okay on a small laptop screen, but produces ridiculous amounts of whitespace on a larger monitor, so I removed itThe clear:both trick is particularly unwieldy when a pattern has a very lengthy infobox, because all the following text drops below the entire infobox -- not just below the most recent embedded viewers.
  
:I think this is eminently sensible. Off the top of my head, aren't there a few articles that have infoboxes despite being about a family of patterns rather than a specific individual one? (Or patterns with variants, anyway --- the bee shuttles come to mind there.) I've never been quite sure how to handle those, though that's not limited to LifeViewer and embedded patterns: the same goes for other infobox'ed information, such as bounding box, population etc. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:54, 13 September 2018 (UTC)
+
Also, it seems as if I often get stuck having just one left-aligned, one right-aligned, and one center-aligned embedded-viewer thumbnail. I'm thinking that there are a number of medium-sized stamp collections that it would be good to get into LifeWiki articles, e.g., maybe representatives of the sixteen classes of glider timing adjustment circuits. I've never gotten a midsized collection like that to look any good on multiple monitors, but maybe if they all just float left with THUMBNAIL THUMBSIZE 3 in LifeViewer, that will be about the best we can do?
  
::Yup, those are the ones where I find the infoboxes to be not-helpful. Would suggest in those cases maybe just using an embedded viewer to show one of the family, or maybe a small stamp collection would be better.  The most recent example I dealt with was [[HFx58B]] from the Life Lexicon.  Rather than pick a variant, and/or leave out perfectly good information that the Lexicon had, I just threw caution to the winds and put both patterns in the same infobox, but picked the older variant to do the infobox stats about.  Probably this will puzzle somebody sometime, but sometimes Life can be confusing... [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 11:20, 13 September 2018 (UTC)
+
I did find that captions could be improved by centering with <pre><div style="text-align:center;">first-line caption<br /><br />extended-caption<br /><br /></div></pre>Does that look tolerable to everyone else? Unless this is added, EmbedViewers with '''position=center''' will have centered caption text, but '''position=left''' and '''position=right''' EmbedViewer captions will both have left-justified text, which doesn't look so good.  The automatically-added last two lines still end up left-justified in those two cases, unfortunately; I didn't attempt to fix that for the Fx77 article.
  
== Semi-automated collection of raw RLE ==
+
In general, if anyone has better suggestions for dealing with page flow issues like these, please let me know! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:51, 1 July 2020 (UTC)
  
I now have a completed Python script -- working on my system, at least! -- that goes through all articles in the main namespace looking for pname definitions in infoboxes and embedded viewers. If it finds any defined pnames, it checks '''www.conwaylife.com/patterns/{pname}.rle'''; if a Not Found error comes back, it creates an appropriate file using RLE from '''conwaylife.com/w/index.php?title=RLE:{pname}&action=edit''', in a reasonably standard format including pname, discoverer and discovery year if available, and links to the relevant article and the RLE file itself.
+
==Link to Discord server on navbar?==
 +
So today ApChrKey joined and said something about how the invite link was really hard to find. It is on [[LifeWiki:Life_links|links]] but at the very bottom. (I don't know how that affects it but whatever) Macbi suggested that we could put it up top on the navbar or whatever it's called. Given that we already have a way to cite it I don't see why we can't have a direct way to access it. [[User:Bubblegum|Bubblegum]] ([[User talk:Bubblegum|talk]]) 22:56, 10 July 2020 (UTC)
  
On the last pass the script found 190 missing RLE files in the main namespace.  These have now been uploaded to the server and added to all.zip.  You can sort the contents of all.zip by date to see the new additions.  Since this was a mostly automated process, the script may have picked up a few patterns that shouldn't really be part of the collection.  If anyone wants to do a quick independent review, I'd appreciate it!
+
== Time to delete [[Template:LinkWeisstein]]? ==
  
I think this will make the process of getting RLE uploaded to the server a lot easier for non-admins. If raw RLE is created in the RLE: namespace, and is used in a pattern infobox or an embedded viewer, then it will make it to the all.zip collection eventually.  To give time for new raw-RLE additions to be peer-reviewed, I would think this script would only be run quarterly or so, with the resulting new RLE files sent as a ZIP file to Nathaniel to do a bulk upload to the server.  There shouldn't be any problem with good files getting overwritten with bad ones, since the script only generates an RLE file if no existing file is found.
+
At this point, I think it's unlikely that the site is going to be updated so that this template can be re-enabled. As it stands, all this template does is produce an ugly piece of whitespace in articles such as [[toad]]. Any objections to deleting it? (note that I can semi-automatically remove all the occurrences beforehand with AutoWikiBrowser) [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 16:40, 18 October 2020 (UTC)
  
It occurs to me that another semi-automated survey might be looking for articles with nofile=true, that do in fact now have raw RLE and/or uploaded RLE files.  I'll try adjusting the script to include any such files it finds in its final report.  It's a little trickier to automatically update all such "nofile = true" to say "rle = true" instead -- it's doable, but it needs a different kind of automation.
+
== Excessive barberpole articles ==
  
Thoughts, suggestions, worries, bug reports?  I'll add a link here to the RLE-scraper Python script when I've made it available on GitHub.  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:21, 23 October 2018 (UTC)
+
In light of the recent [https://conwaylife.com/w/index.php?limit=500&title=Special%3AContributions&contribs=user&target=Bubblegum&namespace=&tagfilter=&start=2020-10-12&end=2020-10-12 merging] of [[Template:Vessel]] articles, we should probably consider merging some of the larger [[barberpole]]s as well, as most people seem to agree that going up to [[quindecapole]] is pretty excessive. However, this raises the question of what the new cutoff point should be. I'd say we should keep at least everything up to [[heptapole]], since all of those have shown up naturally. Note that although [[duodecapole]] does not have any sample soups in any symmetry, [[tredecapole]] does, making that the largest semi-natural barberpole. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:11, 20 October 2020 (UTC)
: [https://github.com/dvgrn/b3s23life/tree/master/lifewiki-rlescraper Link!] [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 00:58, 26 October 2018 (UTC)
 
:: The next item on the RLE-scraper script TODO list will be to check for raw-RLE {pname}_synth files, and upload them if they aren't already there.  Longer term, the script can make a report of any differences it finds between files already on the server and the current contents of the RLE: namespace.  Probably best not to upload changed files automatically -- it seems worth having a human review any changes, and take the time to revert any changes that aren't approved for upload to the pattern collection. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 10:46, 25 October 2018 (UTC)
 
 
 
== Oscillator mods ==
 
 
 
I noticed that all the recently created oscillator pages from the latest Lexicon update (example: [[p29 pentadecathlon hassler]]) have their mods listed along with their periods even if they're equal. Is it agreed upon that this should be the case? Because if so I can go through the [[:Category:Oscillators with unknown mod|unknown mod]] list later and add in all the mods if no one objects to it. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:53, 28 October 2018 (UTC)
 
 
 
: I can't claim to have made a really deliberate decision to include the mod when it's the same as the period -- I was just blindly filling in values in the oscillator template I was using. I don't have any objection to listing both period and mod, but let's see if anyone else has a different opinion.  Many thanks for all the cleanup work you've been doing recently, by the way! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:04, 1 November 2018 (UTC)
 
 
 
:: Just to chime in --- I think listing both the period and the mod is valuable even if they match. Otherwise, if an infobox doesn't have mod information, a user won't know if that's because we haven't filled in the info or because it's the same as the period.
 
 
 
:: And I agree, thanks are due to Ian07 for all the clean-ups and other work. MediaWiki has barn (heh) stars; do we have something similar? Maybe we should. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:01, 3 November 2018 (UTC)
 
 
 
== Conduit orientations and ghost Herschels==
 
 
 
Quick question, y'all: is "T" a standard designation for a "turned" conduit output orientation? I'm asking because of [http://conwaylife.com/w/index.php?title=Template:Conduit&curid=11630&diff=48592&oldid=45674 this edit] to [[Template:Conduit]] --- I lack the expertise whether this is standard terminology or not.
 
 
 
If it is, it should be documented in the template. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:27, 3 November 2018 (UTC)
 
 
 
: Similarly, [http://conwaylife.com/w/index.php?title=Template%3AConduit%2FDoc&diff=50590&oldid=44902 this edit] to [[Template:Conduit/Doc]] doesn't seen to be adding anything useful to the page. As I've just started here I'm a bit hesitant to go around rolling back changes to Template pages though. [[User:Wildmyron|Wildmyron]] ([[User talk:Wildmyron|talk]]) 03:31, 12 December 2018 (UTC)
 
 
 
:: Thanks for pointing these out.  I rolled back the "gray eaters" edit.  The "T" option for symmetrical signals is a little more complicated.  It is definitely something that I tried as a classifier a few years ago, but it never really caught on.  Now just in the last few days Freywa has done a new update of the Elementary Conduits Collection with a better idea than "T", so I'll have a go at documenting that instead.
 
 
 
:: Another conduit-related topic, for @Sokwe and anyone else interested:  it looks like there isn't universal agreement about whether ghost Herschels are a good idea or not, in conduit patterns.  I recklessly ported them in from the Life Lexicon, and I'm certainly going to keep them there because they're so darn useful.  You can copy conduits out of the Lexicon and string them together immediately.  My theory is that the same is true of patterns on the LifeWiki, and therefore that there ''should'' be a ghost eater in [[Syringe 2]], to match the one in [[syringe]] and the dozens of other instances in various recently added conduits.
 
 
 
:: I can see how this looks a little bit like pollution, though, especially if it's extended to other types of outputs (which isn't very clean or easy to do in general, so let's not do that).  I've been careful to link to [[ghost Herschel]] every time I use one (I think), so they shouldn't be mysterious for long -- and I'm seeing them getting a fair amount of use as markers in constructed patterns lately.  Anyone want to contribute other opinions on this? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 13:33, 13 December 2018 (UTC)
 
 
 
== Categories and User Pages ==
 
Entity Valkyrie has been using pattern templates on user pages, causing those user pages to show up in [[:category:patterns]] and other categories.  It is my opinion that patterns on user pages should not be included in the categories.  One way to fix this would be to detect the namespace of the page that the pattern template is being used on.  Something like the following:
 
 
 
<code><nowiki>{{#ifeq:{{NAMESPACE}}|User||[[category:patterns]]}}</nowiki></code>
 
 
 
This would categorize a non-user page as a pattern, but would do nothing on a user page.
 
 
 
Are there any objections to this proposal?  Comments?<br/>~[[User:Sokwe|Sokwe]] 08:11, 2 December 2018 (UTC)
 
: I like that plan, especially if someone else implements it who is less likely than me to break templates.  I've been trying to keep user namespace stuff out of the main namespace in general, with fairly good success so far I think -- but I don't usually go in and edit things like categories when a page moves from the main namespace to the User namespace.  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 11:53, 2 December 2018 (UTC)
 
 
 
== Documenting 12-Bit Still Lifes ==
 
 
 
AwesoMan3000 has been working on a fairly ambitious project to add articles for all of the 12-cell still lifes.  Most of them have systemic names, and it looks like negotiations have been at least partially successful about [http://conwaylife.com/wiki/Talk:Tub_with_tail_with_cape not just making names up] when long-standing existing names are available.  As of this writing, [[swimming cap]] is still an unnecessary neologism for "integral with tub and tail", I believe, and there may be others -- it's hard to keep up, but this is a work in progress with lots of ongoing adjustments.  The plan is for it to be complete by the end of the year.
 
 
 
A number of issues have appeared that I'd be interested in trying to get some kind of consensus about:
 
 
 
# when a still life is renamed for consistency -- e.g., "X and Y" names have been rapidly changing to "X on Y", as in [[block on cap]] -- changing the pname to match the name tends to break lots of links, especially for older 12-bit objects where Life 1.05, Life 1.06, and .cells formats are available.  I'd like to suggest that we can take the radical step of dropping support for Life 1.05, 1.06 and .cells formats, and removing the links for those formats whenever we have an opportunity.  Is there any disagreement on this?  After that, it should be fairly workable to add just RLE:pname.rle and RLE:pname_synth.rle pages wherever necessary.  That will eventually fix the remaining broken links (see below).
 
# if the pname is changed, '''or''' if the still life in question didn't have an existing article on LifeWiki, AwesoMan3000 has been promising that there is an RLE file, using '''rle = true''' in the infobox parameters, and then uploading raw RLE under that pname.  If I remember right, the '''rle = true''' is currently needed to get the infobox template to notice that LifeViewer can be used to display the pattern, instead of looking for an image file.  There isn't actually an uploaded RLE file in the LifeWiki pattern collection, so .rle and _synth.rle links will give Not Found errors for the time being.
 
# Several still life names have been changed due to an alphabetization rule, e.g., [[barge siamese loaf]] instead of '''loaf siamese barge'''.  This poses the same dangers of link breakage as above, fixable in the same way.  Or... it also seems workable to change the name of the page but keep the pname the same, at least until replacement raw RLE is uploaded.  See [[Talk:Hat_siamese_vase]].  This is being done for the moment in several of the "X on Y" pages.  Am I missing other possible problems with this brave but potentially foolhardy renaming-for-consistency project?
 
# When no systemic or traditional name is available for a still life, either on Catagolue or in Mark Niemiec's database, it's hard to avoid the temptation to invent new names that no one has ever used before, and most likely no one will ever use and they'll just cause confusion.  One way around this would be to make it standard practice to write the article using the apgcode as the systemic name.  I don't like this idea all that much, just because the pname would have to have an underscore in it for readability -- and MediaWiki likes to change underscores to spaces in some contexts, and I'm relatively sure that Murphy's Law will produce some unintended consequences somewhere.  Still, it's been tried, and it appears to work okay -- see [[xs15_3lkia4z32]].  Does that seem like a reasonable stopgap solution for unnamed objects?  We can always move apgcode-named articles later if a better systemic naming convention shows up.
 
 
 
===Next Steps===
 
When all raw RLE files have been added in the RLE: namespace for this project, I can re-run the auto-uploader script and make a set of new RLE files for a bulk upload to the LifeWiki server.  The script will have to be updated to check for RLE:pname_synth pages as well as RLE:pname files.  If the RLE namespace has been populated correctly, this will fix all the remaining broken links.  I'll plan to do a round of auto-updating early in 2019.
 
 
 
As [[LifeWiki:Tiki_bar#Semi-automated_collection_of_raw_RLE|before]], if a pname.rle or pname_synth.rle pattern has already been uploaded to the LifeWiki server, it won't be overwritten by anything added to the RLE namespace.  Eventually the script might check whether the uploaded pattern is the same as the raw RLE, and produce a report of any discrepancies so they can be resolved.  Not sure I'll get around to adding that feature in this next update, though.
 
 
 
Comments, concerns, suggestions? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:23, 21 December 2018 (UTC)
 
: Also, AwesoMan3000 put the following in checkin comments for [[beacon on dock]]:
 
<pre>can we get a tiki bar discussion on whether all disambiguation pages should have (disambiguation) on the end, by the way? i'd rather cut down on unnecessary redirects where possible</pre>
 
: So, okay, here's a Tiki Bar discussion. I don't see why the page shouldn't be moved to [[beacon on dock (disambiguation)]] to match the original [[beacon and dock (disambiguation)]] page.  I'm not a big fan of disambiguation pages in general, especially where they can be avoided by making a single page for the most common definition, and linking from that page to other possible meanings under different names. But that doesn't work for cases like this where there isn't a most common definition. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 20:44, 21 December 2018 (UTC)
 
 
 
::'''Re: Made-up names'''
 
 
 
::I agree that we should stick to established names when they're available and not make up new ones. OTOH, when an object does ''not'' have any established name (and I really do mean ''does'' not, not just "whoever wrote the article couldn't remember it"), I think it's in the best tradition of Life (and life) to give it one.
 
 
 
::The question then is whether the LifeWiki is the right place for this. My general feeling is that we're a relatively conservative part of the Life universe: we aim to document, not invent. We're not as anal about it as Wikipedia with its "no-original-research" and "verifiability-not-truth" criteria for inclusion, and neither do we have to be; but just like we're asking people to not create wiki pages for new discoveries of their own but instead share them on e.g. the forums, we can also ask people to not name previously-unnamed on the wiki but instead resort to (again) the forums, etc.
 
 
 
::OTOH this may very well lead to a situation where a user wanting to name an unnamed object will simply suggest the name on the forum in an appropriate thread (is there one yet?), wait for a few days/weeks/months, and conclude from the resulting thundering silence that there are no objections -- all in favor --, and go ahead and name the object on the wiki. The end result would be the same, modulo the extra pain of that extra waiting time.
 
 
 
::And would this gain us anything?
 
 
 
::FWIW, what are we looking to gain from a policy that forbids new names from being put on the wiki first anyway? If we don our documentationist's hats (documentationist --- I hope that's a word!) and take no position on whether a named object is somehow preferable to an unnamed ones, if we merely want to document the Life's community works, passively and from the outside, then yes, this is preferable. If we see ourselves as being an ''active'' part of the community, we might find named objects preferable to unnamed ones (and "proper" names preferable to systematic ones, etc).
 
 
 
::I think I'm in the latter camp myself. I like named objects.
 
 
 
::What I am worried about is that, if we allow new names to be "born" on the LifeWiki, &hellip; shall we say, ''easily excited'' users might get carried away and go on an editing spree, adding hundreds of new names to previously unnamed objects without any discussion or consensus.
 
 
 
:: Going off on a tangent for one paragraph, I also think the creative naming in Life stem in no small part from the need to be able to ''talk'' about objects. These days we have apgcodes, so we can indeed refer to [[xs15_3lkia4z32]] without it having a proper names.
 
 
 
::The best solution I have is what one might call a four-eyes approach, where
 
 
 
::# New names are valued in principle;
 
::# But the person proposing them can't be the one naming the object on the Wiki;
 
::# If someone wants to add page for a (notable) object that doesn't yet have a name, they should use the object's apgcode.
 
 
 
:: Whether names are proposed on the forum or elsewhere is largely irrelevant than, though I'd suggest a dedicated thread on the forum. I'd also suggest a certain cool-down period between the proposal and the wiki edit, so that others have a chance to speak up. (What I'm worried about there is the possibility that ''two'' easily-excited users, might join forces after one of them proposed a new name elsewhere, say on Discord: one would propose it, and right after the other would accept it).
 
 
 
::'''Re: pname changes, Life 1.05/... support'''
 
 
 
::No objects to dropping Life 1.05, 1.06, and cells; RLE has clearly emerged as the standard at this point. I don't know if anyone's still using a CA simulator that's not capable of using RLE, but the lack of complaints about ''new'' patterns only having RLE files available and nothing else leads me to believe there isn't. I'd say let's remove support for these and see if anyone speaks up. If there's no complaints, we can flip the switch for good.
 
 
 
::As for pname changes in general, they're still a pain. I'd suggest that
 
 
 
::# Whoever changes a pname is responsible for cleaning up the resulting mess; and
 
::# pname changes shouldn't be mandatory without a good reason.
 
 
 
::What is a "good reason"? A typo, say --- "<tt>pname = 2enginecrodership</tt>" would obviously require correction. OTOH, if [[Beluchenko's p51]] has "<tt>pname = 112p51</tt>", I see no problem with that at all. (If anyone else does, they're welcome to change it, provided they clean up afterwards, as per 1. above).
 
 
 
::'''Re: infobox parameters'''
 
 
 
::These should '''always''' correctly reflect the status quo. If a pattern doesn't have an RLE file uploaded, the infobox template call shouldn't have "rle=true". Don't lie to the infobox templates! It's the responsibility of those who create articles to make sure all parameters are correct to the best of their knowledge.
 
 
 
::'''Re: RLE files and raw RLE snippets'''
 
 
 
::I'll leave this in your capable hands. :)
 
 
 
::'''Final note'''
 
 
 
::I think having articles on all 12-bit still lifes is a worthwhile endeavor, but -- in light of who's doing this, and admittedly without actually having looked at anything that was created recently -- I'd like to remind everyone who's creating articles that they have a duty to exercise care when doing so. In particular, this means not just starting a whole lot of articles and leaving them in half-broken states.
 
 
 
::I'd also like to remind people that they should learn from their mistakes. Nobody's perfect, especially newcomers; the LifeWiki can be difficult to get used to, I imagine. We have the right to make mistakes, but we have the duty to learn from them. He who keeps making the same mistakes time and again is either ignorant, or careless, or both, and those are not qualities a LifeWiki editor should have.
 
 
 
::(And that's about all I can think of, off the top of my head.) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 11:20, 22 December 2018 (UTC)
 
 
 
::: Thanks for the thoughtful review. A couple of template issues have come up where some expert advice would be helpful:
 
::: 1) A [http://www.conwaylife.com/w/index.php?title=Template:Oscillator&diff=52573&oldid=50579 change made yesterday] to [[Template:Oscillator]] seems to be not working to populate [[:Category:Periodic_objects_with_minimum_population_3]] and all other, um, categories in that category. Is there a misplaced character somewhere in those hideous piles of parentheses, or is the problem actually somewhere else?
 
::: 2) Is it possible to do Template Magic (TM) to make glider syntheses behave the same way as regular pattern files do?  That is, if '''synthesisRLE = true''', then the standard link to an uploaded pattern file should appear in the Glider Synthesis section of the infobox -- but otherwise, if there's a page at '''RLE:{pname}_synth''', then a "raw RLE" link should appear instead.
 
::: Here's an example of an update currently in process:  we used to have an uploaded eateronboat.rle --
 
#N Eater on boat
 
#C A 12-cell still life consisting of an eater 1 and a boat.
 
#C http://www.conwaylife.com/wiki/index.php?title=Eater_on_boat
 
::: -- and an uploaded eateronboat_synth.rle --
 
#N Eater on boat_synth
 
#O Mark D. Niemiec
 
#C Glider synthesis of eater on boat.
 
#C www.conwaylife.com/wiki/index.php?title=Eater_on_boat
 
::: Then along comes AwesoMan3000, who probably thinks that that's a lousy name for this object because it can mean two different things, and isn't really a common use of "on" anyway. So the name gets upgraded to the more specific "boat tie eater tail", and all the appropriate changes get made to the text of the article.  And there's a redirect from [[eater on boat]], so damage is limited to other pages that link to this page.
 
 
 
::: However, AwesoMan3000 can't do anything directly about those uploaded pattern files, or the comments in those files.  The simple solution is to just leave the pname the same, still pointing to the old pattern and synth files. That doesn't break any links, but it's a bit confusing because the name doesn't match the article.
 
 
 
::: If we want to get boattieeatertail.rle and boattieeatertail_synth.rle files uploaded to the LifeWiki server, currently what we can do is add those as raw RLE, and change the pname in the article to '''boattieeatertail'''. I've done that experimentally for this example. As a nice side effect, as soon as the pname changes, LifeViewer shows up in the infobox instead of a static image.
 
 
 
::: That's not too exciting when we're dealing with still lifes... but it does start to get people used to an easier way of getting a copy of the RLE to paste into Golly or wherever -- click to launch LifeViewer, then Ctrl+C.
 
 
 
::: (If anyone is following along, [[Beehive_at_loaf]] is currently an example of the old style of article, with a separately uploaded static image -- no LifeViewer, just because no raw RLE has been uploaded to [[RLE:beehiveatloaf]].)
 
 
 
::: Okay, so here is where the difficulty shows up!
 
 
 
::: '''PROBLEM''': as soon as the pname is changed from "eateronboat" to "boattieeatertail", the '''rle = true''' and '''synthesisRLE = true''' lines in the infobox suddenly turn into lies.  They're only temporary lies, because there's a plan to run the auto-uploader script and get the new RLE uploaded.  But when RLE is being added for dozens or hundreds of still lifes, there's no way that an admin is going to keep up with running the auto-uploader after every change.
 
 
 
::: In fact, it just plain doesn't work that way -- the auto-uploader does a scan of the entire main LifeWiki namespace and creates an archive ZIP file of a big pile of changes, intended to be sent to Nathaniel to do a bulk upload to the server.  That should really only happen a few times a year, not every time a change happens. So we wait until a batch of changes have been made, then collect and send them.
 
 
 
::: Theoretically we could remove the '''rle = true''' and '''synthesisRLE = true''' lines from each article, then add them right back again after the auto-upload is done. But when the timeline of a project is short enough, that looks like a highly irritating waste of time -- basically, Life is too short.
 
 
 
::: I hope everyone is okay with the idea of saying that these particular deliberate temporary inaccuracies in infobox parameters are actually not "lies", but rather something along the lines of "promises". [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 13:40, 22 December 2018 (UTC)
 
 
 
:::: As for the first issue, I checked and double-checked the template and didn't find any syntax errors. What's weird is if you go to the [[Blinker]] article you can see that it has the [[:Category:Periodic objects with minimum population 3]] category, but the category page says it's empty. This makes me think that there's some sort of glitch with MediaWiki rather than a syntax error, especially considering that, as you pointed out on Discord, LifeWiki is running a [https://www.mediawiki.org/wiki/MediaWiki_1.23 pretty outdated version] of it. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 14:00, 22 December 2018 (UTC)
 
 
 
::::: Can the links to pattern files be directed to a dynamic endpoint that creates the pattern file? For all patterns with apgcodes, for instance, Catagolue could theoretically include endpoints of the form /objfile/<rule>/<apgcode>/<format> (with support for RLE, Life 1.05, and Life 1.06). That would mean that humans only need to provide static RLE files for large and/or aperiodic patterns. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 00:36, 23 December 2018 (UTC)
 
 
 
:::::: Late reply, but yes, that would definitely be possible. Pattern file links are handled by [[Template:PatternDownload]], which already gets passed the apgcode (if we have it, for a given object), so it'd only be a matter of tweaking that template. And I think doing away with manually-generated and -uploaded RLE files where possible would save us a lot of work.
 
 
 
:::::: (I should qualify this by stating that I'm not suggesting we delete existing manually-generated pattern files; merely that having Catagolue be able to do this would allow us to not have to worry about future ones, except for Patterns of Unusual Size&trade; etc).
 
 
 
::::::: I do like the idea of not having to upload pattern files for all the files that have apgcodes, theoretically.  On the other hand, the fastest way to get a picture of an object into an article about the object, these days, is to upload RLE to the RLE namespace and add the relevant infobox.  And the RLE-scraper script can then (with just a small amount of help from me) magically grab all the new pname-linked RLE files, put them in a ZIP archive, and send it to Nathaniel to put on the server -- once every month or three as needed.
 
::::::: I can add automatic conversion of everything to .cells format and add those files automatically to the ZIP file sent to Nathaniel.  So would we gain much by being able to link to a pattern file on Catagolue?  Not sure.
 
 
 
::::::: I'm starting to work on support in the script for {pname}_synth files as well, so that if people put something into RLE:{pname}_synth, it will get turned into {pname}_synth.rle and get thrown in the ZIP file along with everything else.  But here I'm really not sure if that's the best thing to do, at least for a lot of cases.  There are a couple of big sources of synthesis RLE:  chris_c's script (via Catagolue these days) and Mark Niemiec's database.  Maybe Catagolue could serve up RLE without the LifeViewer, or maybe the "Glider synthesis" section in the infobox could be tweaked so that it links to the LifeViewer page on Catagolue showing the relevant synthesis?
 
 
 
::::::: Then for anything that has a synthesis in Mark Niemiec's database, we just need to collect the identifiers and add them to the infobox template (somehow -- suggestions gratefully accepted), then set up the template to link directly to those files.  For example, the path to the beehive synthesis is [http://www.conwaylife.com/ref/mniemiec/0/6hv.rle "0/6hv.rle"], and the path to a beehive on cap synthesis is [http://www.conwaylife.com/ref/mniemiec/14/14-50.rle "14/14-50.rle"].
 
 
 
::::::: That way RLE:{pname}_synth pages would only have to be collected and uploaded for patterns where no synthesis is available on Catagolue or on Mark's site.
 
 
 
::::::: Something like this would prevent us from continuing to upload so many no-value-added syntheses that are just copies of something from elsewhere (and that won't get updated when Mark's database or chris_c's script gets updated).
 
 
 
::::::: I don't think we should necessarily start the big project of supplying all those Niemiec-database identifiers to the infoboxes ''quite'' yet:  Mark has said recently that he's close to rolling out a new version of his site, and it might make sense to wait and make sure nothing major has changed in the new version.  But we could try the experiment of getting everything set up correctly for, say, the [http://www.conwaylife.com/ref/mniemiec/p1-12.htm 12-bit still lifes] that were added to the LifeWiki recently.
 
 
 
::::::: TL;DR: Templates need tweaking. Anyone interested in trying some experimental additions to the Glider Synthesis section? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 03:59, 10 January 2019 (UTC)
 
 
 
:::::::: It seems that MDN has helpfully highlighted objects in a different colour in his version of Extended RLE. I think this means that the .rle files can be automatically reverse-engineered to deduce the objects that are produced, enabling the generation of an apgcode-to-mniemiec-url mapping. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 16:10, 10 January 2019 (UTC)
 
 
 
::::::::: That might work, though it might also be more trouble than it's worth to get the automated reverse-engineering working.  It's not just the target objects that get the "x" color, but also the intermediate stable stages -- and there are a lot of those in some cases, when multiple construction paths are documented.  If you censused all the 'x' objects, the most common object is probably the target object -- or the one that's farthest to the right, I suppose.
 
 
 
::::::::: But that may not be necessary.  Mark sent an email to me over half a year ago saying that he had put together "...vastly improved search pages [which] should include everything necessary to perform searches... pattern lists, statistics for each pattern, and links to other sites (like Catagolue, Pentadecathlon, David Eppstein's Glider Repository, and LifeWiki)".  So it's possible that Niemiec Database Mark 2 (heh) might provide a list of the required apgcodes with no need for reverse engineering.
 
 
 
::::::::: We'll see when the time comes, I guess.  At worst, generating that lookup table manually or semi-manually would be a one-time effort -- painful, but finite. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:44, 10 January 2019 (UTC)
 
 
 
Resetting indent back to zero, but still talking about kind of the same thing:
 
 
 
I just thought to check the LifeWiki pattern collection for outdated links to Mark's database.  There were 165 RLE files with dead links in the comments.  I fixed two of them, one by creating an RLE:{pname}_synth page and one by editing the pattern comments and deleting and re-uploading the file by hand... and then thought, "Nope.  There has to be a better way."
 
 
 
Now I'm just doing a search-and-replace, "http://www.conwaylife.com/ref/mniemiec" instead of "http://home.interserv.com/~mniemiec/", and will ask Nathaniel to re-upload all those files to the server along with the output of the auto-upload script.
 
 
 
Of course, if these _synth files were created when that website was available, a lot of the actual syntheses might be out of date as well. A dynamic endpoint somwehere for reporting the actual latest synthesis for each object would certainly be a step up from the current perpetually out-of-date synthesis files.
 
 
 
-- On the other hand, there are big advantages to Mark's comprehensive collections of practically every historically known way of constructing each object.  Sometimes you might want a synthesis with a suboptimal number of gliders but better clearance than usual, or might want an incremental construction starting from one half of the still life, or whatever.  Reporting just a single current-best synthesis would lose a lot of that useful information. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:25, 24 January 2019 (UTC)
 
 
 
== The list(s) of rules investigated on Catagolue ==
 
 
 
Short version: these have increasingly become a burden to maintain on-wiki, and with Catagolue now having [https://catagolue.appspot.com/rules its own endpoint] providing an overview over and an exhaustive list of all rules searched, they're largely irrelevant now. (The on-wiki list was only started because Catagolue didn't provide one at the time.)
 
 
 
So I'm giving up maintainership of these. If anyone wants to take over, please do! [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 17:00, 7 January 2019 (UTC)
 
 
 
: If we are to retire the [[List of rules investigated on Catagolue]], how should we do this? Add a notice at the top saying:
 
 
 
: "This page is no longer actively maintained in favour of the [https://catagolue.appspot.com/rules equivalent Catagolue page]."
 
 
 
: or words to that effect?
 
 
 
: It still might be a good idea to actually keep the information in the LifeWiki, because Catagolue occasionally has outages when the daily quota has been exceeded, whereas conwaylife.com tends to be permanently accessible. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 18:26, 7 January 2019 (UTC)
 
 
 
:: The wiki page does have some advantages over the Catagolue one, such as listing the rule integers for outer-totalistic rules and being easier to edit (e.g. adding names for new rules). [[User:77topaz|77topaz]] ([[User talk:77topaz|talk]]) 23:51, 7 January 2019 (UTC)
 
 
 
== Time for a consensus decision on pnames? ==
 
 
 
I've run the RLE-scraper script to collect new RLE files for a bulk upload. The script found 321 new RLE files. Before I send them to Nathaniel, it looks like I'll be doing some more standardization, especially involving pnames.
 
 
 
The [[LifeWiki:Pattern_pages|guidelines for creating pnames]] say very clearly:
 
<pre>pname (required) The name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed.</pre>
 
 
 
This has worked fine for us for the great majority of cases, but there are two related cases where blindly following that rule creates not-very-good pnames:
 
 
 
# '''apgcode-based names''', where removing the underscore can sometimes concatenate two strings of digits. For example, according to the rule, [[Xs15_3lkia4z32]] is theoretically supposed to have a pname of "xs153lkia4z32", which reads as if it's a 153-bit still life.  Underscores are confusing in article names because MediaWiki turns right around and renders the name without an underscore. But they do seem to work fine, and they're necessary in other article names, anyway -- raw RLE "pname_synth" synthesis files need them.
 
# '''patterns named after a Niemiec or pentadecathlon.com ID''', where removing a period causes similar problems with readability.  Examples:
 
* [[37P7.1]], created by Sokwe in 2009 with a pname of "37p7.1" -- including the period. Another similar case is [http://conwaylife.com/w/index.php?title=37P10.1&diff=13437&oldid=13432 37P10.1], where Sokwe changed the pname from Nathaniel's original "37p101" to "37p10.1", back in 2010.
 
 
 
* [[38P11.1]], with a pname of "38p111". Periods in filenames are definitely annoying because the part after the period can look like a file extension... but I think "38p11.1" would really be better here.
 
 
 
* Several patterns with pnames created by Entity Valkyrie recently: 14p2.1, 14p2.3, 14p2.4, 28p7.3, 28p7.3bumperbouncer, 28p7.3eatingss, 31.4, 33p3.1, 33p3.1bumper, 33p3.1eatingss, 33p3.1reactions, 34P6.1.
 
 
 
====Capitalization Bad====
 
The last pname in that list is also nonstandard due to capitalization, but that's a separate problem. The full list of capitalized pnames is 35P12, 53P13, 55P10, 113P18, BF20H, BFx59Hinjector, FMHEB, Gtolwss.rle, L112functions, L156reactions, L156variants, L200, Lightspeedcrawler, P5HWV, P58toadflipper, PT8P, PT9B, PT38P -- again all by Entity Valkyrie, I think.  I'll definitely have to go through and fix all of these, just because they're dangerous to cross-platform uses of the pattern collection:  "35P12.rle" will overwrite "35p12.rle" on a Windows operating system, but not on Linux.  And LifeViewer fails to find "RLE:35P12" when told given "pname = 35p12", because the LifeWiki's filesystem is case-sensitive.  So I think the no-capitalization part of the pname guidelines should continue to be very carefully enforced.
 
 
 
====Periods Not So Bad====
 
However, given the long precedent for pnames occasionally including periods, I'm not planning to change any of Entity Valkyrie's pnames if a period is the only non-standard part. Should probably do something about "31.4", but the rest seem okay.
 
 
 
-- Anyone know where the ".4" comes from in "31.4", by the way?  The problem with calling the thing just plain "Snark catalyst" is that there are several workable Snark catalysts. 31.4 is one of the two most common ones, but it's not exactly "the" Snark catalyst.  But no other common name has caught on. ('''Bellman Zero''', anyone? '''Catalyst B0'''?  '''31.4''' seems better than either of those.)
 
 
 
====Summary questions====
 
TL;DR:  Does anyone object if I adjust the pname guidelines to say that periods are okay, but "only where necessary", or something along those lines?  And also say that underscores are okay only in apgcode pnames and raw-RLE _synth articles?  Underscores are a minor nightmare, because MediaWiki automatically converts them into spaces, and pnames really aren't supposed to include spaces.  I'm reasonably sure that that underscore-to-space conversion is bound to cause coding difficulties somewhere sometime.  But unless someone wants to recommend consistently using periods in place of underscores in apgcode pnames, I just don't see any good alternative.
 
 
 
Comments, suggestions, disagreements? Please post 'em here! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:56, 15 January 2019 (UTC)
 
 
 
: Also, not sure if anyone will find this note here, but gmc_nxtman's recent series of synthesis postings made for a good test case for reworking several pages recently updated by AwesoMan3000. It's been different changes for every article, but it tends to take a lot of fiddly adjustments to synchronize the pname, RLE, synthesis RLE, LifeViewer config, and any files already uploaded to the LifeWiki server.
 
 
 
: I've done half a dozen articles for starters:  [[very long snake]], [[trans-block on long hook]], [[integral with tub]], [[eater head siamese eater tail]], [[cis-block on long hook]], and [[aircraft carrier with feather]].  LifeViewer generally Just Works once there's a raw RLE article with the right pname, but the images come out too small by default, so I've been adding viewerconfig '''THUMBSIZE 2'''. This should probably be a default added to the template, with SUPPRESS, except I don't know if that will change the looks of a lot of existing articles).
 
 
 
: This leaves [[boat with long tail]], [[beehive with nine]], [[broken snake]], [[cis-boat with nine]], [[eater bridge eater]], [[long boat tie ship]], [[long shillelagh]], [[ortho-loaf on table]], [[snake siamese snake]], [[snake with feather]], [[snorkel loop]], [[trans-boat on table]], [[very long shillelagh]], and [[sesquihat]] that still need editing to add the latest syntheses. I could definitely use some help with updating these:
 
# decide whether the pname should change to match the article name
 
# new synthesis copied from '''Talk:{name}''' to '''RLE:{pname}_synth''', either updating or replacing any RLE that's currently there
 
# fix "synthesis = {n}" in infobox
 
# add to infobox: <pre>viewerconfig    = [[ THUMBSIZE 2 ]]</pre>
 
# remove Life1.05 and Life1.06 lines (optional)
 
# double-check that article name matches article text and Catagolue link -- there's often something wrong there
 
# add '''RLE:{pname}''' if it's not there already, to make LifeViewer show up instead of an old image file
 
 
 
: A couple other tasks are admin-only --
 
# If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
 
# If Life1.05 and Life1.06 lines have been removed, delete corresponding files from server. (I'm leaving the "plaintext" (.cells) links, because I'm hoping to generate those automatically for all sub-64x64 patterns currently on the LifeWiki.)
 
# When a good break point is reached, re-run the auto-upload script and collect all the new pattern and synthesis RLE text into a ZIP file for bulk upload.
 
 
 
: Here again, I'm leaving some broken links to pattern or synth files, which I'm planning to fix fairly soon (by putting the files back in place using the auto-upload script).
 
 
 
: This is the kind of project where I'm very unlikely to get everything exactly right. Independent reviews of all this stuff will be greatly appreciated, and just let me know what I've done wrong so far. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 12:33, 21 January 2019 (UTC)
 
 
 
==Special pages broken?==
 
I have noticed several oddities in a few of the maintenance pages:
 
* [[Special:BrokenRedirects|Broken redirects]] claims there is an existing page named [[RLE:lobster]] that redirects to a non-existent page named [[RLE:83p7h1v1]], when the opposite is actually true.
 
* [[RLE:Loafer]] is listed in various places (such as [[Special:ShortPages|Short pages]]) despite being in the wrong namespace.
 
* [[ConwayLife.com:About]] is listed as in [[Special:DoubleRedirects|Double redirects]] despite not having any redirects.
 
* [[Special:FewestRevisions|Pages with the fewest revisions]] isn't even close to being correct.
 
* [[Special:UncategorizedPages|Uncategorized pages]] is quite incomplete; I noticed the articles [[Ruler]] and [[Alternating rule]] were not listed even before I added categories to them, and these are almost certainly not the only examples.
 
 
 
Anyone know what's up with these? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:35, 15 January 2019 (UTC)
 
 
 
==Rulespace info for eaters, reflectors, conduits, etc.==
 
So lately I've been busy adding isorule parameters to the infoboxes for various patterns. So far I've stuck with oscillators, spaceships, still lifes, and infinite growth patterns, but I'd also like to expand this to other pattern such as conduits which are a bit more ambiguous. For example, the [[sidesnagger]] works in B/S23, but obviously there are no gliders for it to eat. I'm of the opinion that for these patterns we should show the rules they're actually ''useful'' in, since that's what makes them notable in the first place, (though with the possible exception of [[eater 1]] since it's such a small pattern) but I'd like to hear others' thoughts on this. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 18:57, 19 January 2019 (UTC)
 
 
 
: My main thought is that all but the very simplest and lowest-step-size conduits are very close to rule-specific -- useful only in B3/S23. Adding a B8 or an S8 might be one of the few isotropic bits where some conduits would survive the rule switch (?). Even if a particular conduit works in another rule, it's only interesting if a large enough group of conduits works in the alternate rule to make it computationally universal.  (That would probably make it construction-universal, too, but only after someone re-did all the single-channel search work to produce new recipe libraries.)
 
 
 
: Anyway, from my point of view the reason why B38/S23 or B3/S238 doesn't get a lot of attention is that there's nothing really new and exciting about those rules to make up for the fact that the rule spec is just that little bit more complicated... pun maybe intended. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 02:04, 20 January 2019 (UTC)
 
 
 
==[[apgsearch]] and [[Catagolue]]==
 
Would anyone be opposed to a reorganization of the information on these two articles? I noticed that a lot of the information in the Catagolue article really applies more to apgsearch rather than the site itself, and therefore might be worth moving. Such a change would be particularly easy to revert if need be, but I'd rather not go through the effort if that's the case, so I'd also like some feedback about that. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:32, 19 January 2019 (UTC)
 
 
 
: No opposition here. I wouldn't think anyone would be likely to revert changes to those articles, just the usual quick review to see if the changes happen to serve as a reminder of anything else that should be added. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 02:04, 20 January 2019 (UTC)
 
 
 
== Help Wanted with templates and general review ==
 
 
 
Here are three problems that I'd like to fix. I could probably track down the necessary template changes myself, eventually, but I'd like to have expert advice if I can get it.  Both of these items have been sorta kinda mentioned on the Tiki Bar before, fairly recently:
 
 
 
1. I think '''THUMBSIZE 2''' should be the default for all infobox LifeViewers.  I keep adding '''#C [​[ THUMBSIZE 2 ]]''' to get infobox pattern frames back to the right size.  There seem to be hundreds of these '''THUMBSIZE 2''' specifications by now, but looking through a bunch of new aircraft-carrier-themed still lifes that AwesoMan3000 added recently (see links a few paragraphs up)... those all need the same addition done to them, and there are dozens or hundreds more existing articles that still have the same problem.  The [http://lazyslug.no-ip.biz/lifeview/plugin/suppress.html '''SUPPRESS''' command] should follow '''THUMBSIZE 2''', so that the relatively few viewerconfigs that specify '''THUMBSIZE 3''' won't start throwing errors after the change is made.
 
 
 
2. As of this morning, Nathaniel has officially removed the Life 1.05 and Life 1.06 patterns from the LifeWiki patterns directory.  That means the infobox template probably ought to be adjusted to stop showing those links.  We could remove "'''|life105 = true // |life106 = true'''" from all the articles that have those infobox parameters instead, but only if someone wants to get a leg up on entry into the 10,000 Club.
 
 
 
The Life 1.0x patterns are still on the server, but [http://conwaylife.com/patterns/lif_pattern_backup.zip hidden in a ZIP file]. It seems to me that going forward, the way to make patterns available in non-standard non-RLE formats will be to publish conversion scripts that work on the contents of all.zip.
 
 
 
Anyway, there are some places in the infobox template documentation and other docs that mention Life 1.0x, which I can track down and fix eventually if no one else gets to it first.
 
 
 
3. Let's get rid of that dependency where you have to have '''rle = true''' or '''nofile = true''' before LifeViewer will show up -- as per [http://www.conwaylife.com/forums/viewtopic.php?f=4&t=2298&p=68135#p68135 Nathaniel's recent advice]. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:51, 25 January 2019 (UTC)
 
 
 
: Okay, Nathaniel has done a bulk upload of 387 RLE files, collected by the auto-upload script for every article in the main namespace that referenced a pname and had RLE:{pname} and/or RLE:{pname}_synth articles in the RLE: namespace. That means that as of today, there should no longer be any broken RLE pattern download links (the ones that show up when you say '''rle = true''' in the infobox).
 
 
 
: There shouldn't be a lot of broken '''synthesisRLE = true''' links, either, but those might happen if somebody set that flag to true but then didn't create the RLE:{pname}_synth article.
 
 
 
: I'd suggest that people shouldn't go too wild uploading new glider syntheses, until the next version of Mark Niemiec's database comes out -- and maybe not even then. It would be nice to come up with direct dynamic links to synthesis patterns on Catagolue and/or in Mark's database, so that we don't always have slightly antiquated information copied from those places and uploaded to the LifeWiki pattern collection, where they're kind of hard to keep up to date.
 
 
 
: I guess the next item to tackle is automatic generation of the '''plaintext = true''' .cells files for every article about a pattern that's 64x64 or smaller (let's arbitrarily say). Does anyone have suggestions for other checks and auto-updates that the uploader script might be able to accomplish? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:25, 27 January 2019 (UTC)
 
 
 
:: @Ian07:  Wow, that was a lot of fast Life 1.0x cleanup work. Thank you! I'll see if I can get a bulk upload done for .cells format soon, for all sufficiently small patterns (which is most of them). Then the LifeWiki will suddenly be following a standard policy on pattern formats, fairly universally across all articles. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 20:49, 28 January 2019 (UTC)
 
 
 
== Replacing images with animated viewers ==
 
 
 
I just started on a project to add more animated viewers in place of static images on the wiki. However, I've already started running into some problems, particularly with the [[pushalong]]s in the [[114P6H1V0]] article. I already created an [[RLE:114p6h1v0pushalong]], but I'm not sure how exactly the comments in the '''RLE:pname''' page get translated to the actual files, especially since files like [http://www.conwaylife.com/patterns/block.rle <tt>block.rle</tt>] have comments that aren't in the RLE namespace. I'm worried that I'll unintentionally remove said information from the wiki's pattern collection if I'm not careful.
 
 
 
I'm thinking it might be better for now to just focus on the infobox images and not worry about the rest of the article, especially considering the images in the article have colors and arrows and other things which might be lost with an animated viewer. I'd be perfectly fine with [[RLE:114p6h1v0pushalong]] being deleted for the time being so it doesn't replace [http://www.conwaylife.com/patterns/114p6h1v0pushalong.rle <tt>114p6h1v0pushalong.rle</tt>] in the next bulk upload.
 
 
 
Even then, though, as with the [[Block]] example above, there's still comments in the original files that may or may not be overwritten since I don't know how bulk uploads work. I'd basically just like to know what precautions to take to make sure I don't break anything with this project before I proceed. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 16:06, 2 February 2019 (UTC)
 
 
 
: All good questions.  The main answer is that the auto-upload script is designed so that it never overwrites any files that are already on the LifeWiki server, so you don't have to worry about overwriting anything.  Comments in block.rle are safe, and the addition of [[RLE:114p6h1v0pushalong]] won't damage the existing uploaded file on the server.
 
 
 
: Now, if we deleted 114p6h1v0pushalong.rle from the server, and added these two comment lines at the top of [[RLE:114p6h1v0pushalong]] --
 
 
 
<pre>#O Hartmut Holzwart
 
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.</pre>
 
 
 
: - then the auto-upload script would regenerate a fairly close copy of the file that we deleted.  The #N line would be a little different since the default is now {pname}.rle, and the script produces two URL lines instead of just one:  a link to the article followed by a direct link to the (future location of the) file itself on the LifeWiki server.
 
 
 
: So far I've always looked through the RLE files produced by the script, and hand-edited anything that didn't come out quite right -- order of comment lines, etc.  That's probably a tradition that I'll continue, so that's another line of defense against accidental damage.  With any luck the next run won't be quite so much work, as long as no one goes back to uploading new headerless RLE or other nonstandard stuff that the script doesn't know how to clean up.
 
 
 
: See also [[User_talk:AwesoMan3000#Standardization_of_comment_lines]] for a summary of what should, or could, still be included in comment lines, versus what is auto-generated.  Maybe after that summary gets a good trial run, I can migrate it into the actual documentation.  It will be strange and wonderful for a new LifeWiki editor to actually have a reasonable way to learn how to add new articles with associated LifeViewer-displayed patterns... the docs have been partly stuck in 2009 ever since, well, 2009 I suppose! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:07, 3 February 2019 (UTC)
 
 
 
:: One more detail that isn't clear from the above:
 
 
 
:: The auto-upload script will automatically generate a slightly nonstandard #O line including both the discoverer and the discoveryear from the infobox -- like
 
 
 
<pre>#O Paul Tooke, 2008</pre>
 
 
 
:: for the 114p6h1v0 article.  But that only works for patterns that have infoboxes.  Other patterns may also have pnames, but only show up in embedded viewers in some other article. In those cases the script can't be sure that the discoverer or discoveryear will be correct, so it will just leave that optional line out.
 
 
 
:: Theoretically we could invent some standard way to include attributes in an embedded viewer template to convey that information. But since those attributes aren't actually used by LifeViewer it seems just as easy to make a habit of adding a comment line to the RLE.
 
 
 
:: For example, adding "#O Hartmut Holzwart, May 2009" to [[RLE:114p6h1v0pushalong]] would convey slightly more information (month as well as year) than the auto-upload script manages to collect for main-article patterns. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:19, 3 February 2019 (UTC)
 
 
 
::: Just looked over the first batch of patterns added to the RLE namespace for the convert-static-images-to-LifeViewer project. Everything looks pretty workable. I think I'll adjust the auto-upload script to skip the generation of an #O line if there's one in the RLE already. Usually what's in the RLE will be a more specific date than what the script can produce from the discoveryear parameter.
 
 
 
::: Maybe I should change the script to find the "name" parameter if there is one, and use that instead of '''{pname}.rle''' in the #N line?  It's kind of weird having ".rle" as part of the defined name.  The problem is, there isn't a '''name=''' line in embedded viewers, but there is a '''pname=''' line, and I wanted some information in that first line that could be collected consistently. (?)
 
 
 
::: The only other thing I noticed offhand is that a few RLE files ended up getting comment lines with links: for example, [[RLE:151p3h1v0]] has
 
 
 
<pre>#C http://www.conwaylife.com/wiki/index.php?title=233P3H1V0</pre>
 
 
 
::: There's a shorter form that works just as well:
 
 
 
<pre>http://www.conwaylife.com/wiki/233P3H1V0</pre>
 
 
 
::: But really I don't think there's any need to add article or pattern links to the RLE namespace.  They'll get generated and added automatically by the auto-upload script.  If you're actually looking at an RLE file in the RLE namespace, and wondering which article it goes with, then it's pretty quick to click the "What links here" link in the sidebar to find that out, instead of copying and pasting part of a comment line.
 
 
 
::: Based on experience so far, does there seem to be anything else that really ought to be adjusted for this whole conversion / auto-upload process? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:54, 3 February 2019 (UTC)
 
 
 
::: Oh, one more minor thing:  looking at LifeWiki articles with lots of LifeViewers on them, I'm starting to think that there might be such a thing as too much animation sometimes. If the infobox has an animated spaceship or oscillator in it, it might make sense to leave out AUTOSTART on (some?) embedded viewers in the actual article.  It can be nice to have something on the page that ''isn't'' moving -- or to be able to open in LifeViewer and step through a pattern one tick at a time, without having to disable AUTOSTART first. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 23:12, 3 February 2019 (UTC)
 
 
 
:::: I haven't had any other problems so far, though of course I've only just started this project and have only gotten through around 1% of all the articles. As for the comment lines in RLEs, I'll try and be more consistent with them from here on out. (will double-check the ones I've already made to see if there's anything that should be added or removed) And yeah, I do agree that too many auto-started viewers looks very cluttered, so here's a rule of thumb I'm probably going to use: there should be no more than three AUTOSTART viewers in close proximity to each other. Thoughts? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:50, 3 February 2019 (UTC)
 
 
 
::::: Fine by me.  I've been thinking two animated viewers at once is usually enough action, but it depends on the article. Just maybe something to keep in mind a little bit. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 01:33, 4 February 2019 (UTC)
 

Latest revision as of 14:11, 20 October 2020

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.

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.

CiteDiscord template?

Was thinking about this since User:Dvgrn added a Discord citation to the Max article. Would there be any objections to a template to cite the Conwaylife Lounge Discord server? It is a public server, after all, and there have been quite a few notable discoveries and developments announced there over the years. Ian07 (talk) 17:53, 16 February 2020 (UTC)

Sounds good to me. I'd also like a Templates Cheat Sheet page under How to Contribute somewhere, probably just a section in Help:Templates. There are examples there of how to use some templates, but for many of them I currently just go hunting around randomly in articles until I find a good example of how it's used, and then copy and modify that. As the number of templates increases, this is starting to seem more and more, um, suboptimal. Dvgrn (talk) 15:06, 17 February 2020 (UTC)
I know it's been two months, but Template:CiteDiscord is now up and running on the Max article. Thoughts? Ian07 (talk) 14:12, 17 April 2020 (UTC)

Black ribbon

Briefly popping out of the woodwork to mourn Rich --- I had the idea of adding a black ribbon in the lower right corner of pages. This is added by a bit of code in MediaWiki:Common.js, with some supporting CSS in MediaWiki:Common.css. To turn this off again, simply comment out the line that says

$( document ).ready(function() {
    console.log( "ready!" );
    addMourningRibbon();
});

near the bottom of MediaWiki:Common.js. (Actually, commenting out the call to addMourningRibbon there will be enough.) Leave the rest of the code and the CSS in though; that way the ribbon can be reused next time there is a death in the community. (The link on the ribbon is set a little further up, and can easily be adjusted as needed.)

N.B. --- the ribbon itself is a bit fiddly and doesn't always appear; I suspect this has to do with page caching, but I know too little about Javascript, Mediawiki and all that jazz to get to the bottom of it. Perhaps someone else who knows more can help. Using jQuery (which, thankfully, is included in MediaWiki) fixed this, so we should now have a ribbon on all pages, always. Apple Bottom (talk) 10:13, 11 March 2020 (UTC)

The black ribbon has been there for over ten days now; anyone want to suggest an appropriate total time period for it? I wandered over to MediaWiki:Common.js to see what would have to be done to turn it off, but found that I didn't have permission:
Permissions for editing of sitewide CSS/JS/JSON files were recently separated from the editinterface right.
If you do not understand why you are getting this error, see mw:MediaWiki_1.32/interface-admin.
Luckily I had permission to give myself permission, so I can now comment out the relevant line. The Internet suggests there are common 7-day and 30-day traditional mourning periods. Dvgrn (talk) 21:32, 22 March 2020 (UTC)
10 days seems fine to me. And yes, I had the same issue with permissions. Bit weird that MediaWiki doesn't give the relevant right to admins by default, but perhaps this is so that admins who're not aware of what they're doing won't accidentally break things. Apple Bottom (talk) 21:33, 27 March 2020 (UTC)

LifeViewer and RLE on OCA subpages

I was just looking at some experimental pages that Hunting/Ultimium has put together for LeapLife. For example, the small knightship in LeapLife is called a "lepa", so it's presumably going to go under OCA:LeapLife/Lepa.

But that brings up all kinds of questions. Look at Hunting's experimental Lepa page. If RLE is added in the RLE: namespace for a lepa, and for all the other things Hunting will want to document, then those patterns will end up in the main pattern collection, right? That doesn't seem like such a good idea. It would be nice to be able to put RLE someplace where LifeViewer can still find it, but it doesn't end up in the main LifeWiki pattern collection. We only have a few non-Life patterns so far, like Bomber, but it seems as if things could get out of control pretty fast if people want to add LifeViewer support for OCA pattern articles.

It seems like some different templates might be needed, to point to the alternate RLE namespace (if that gets created), and to get rid of irrelevant stuff like the links to Catagolue syntheses which won't exist for OCA patterns.

Thoughts on this? Would it be better to skip the templates, and just recommend that OCA patterns should keep their RLEs directly in the articles, as part of embedded LifeViewer text? Then I think the "RLE: here Plaintext: here" template won't work too well, and an alternate embedded-LifeViewer template for OCA patterns might be a good idea. (?) Dvgrn (talk) 16:09, 7 April 2020 (UTC)

I think there should be a separate category, say OCARLE: and an option in the template |rle = oca for checking specifically under that header. Either that or one of the three other options:
  • Removing the pattern collection.
  • Creating a new wiki for other cellular automata.
  • Excluding all OCA RLE pages from the collection.
I agree with OCARLE. Ultimium (talk) 03:15, 30 May 2020 (UTC)
Giving a quick search for RLE:bg gives 5 RLE pages as well, all in LeapLife. I think those should be excluded even if the others can't be, especially if I'm going to create more. (and Hunting's too, afaik there's only RLE:Lepa and RLE:Crawfish so that shouldn't be too hard) Bubblegum (talk) 18:25, 29 May 2020 (UTC)
I don't object to either of these ideas, just want to point out that the latter option actually won't require the creation of a new template - if rle is specified instead of pname, the links won't appear. Ian07 (talk) 21:24, 7 April 2020 (UTC)
I prefer to use a seperate collection instead of the RLE embedded in the page, and a template for OCA patterns, for, um, for no reason. I mean they will be easier to access and manage. Ultimium (talk) 06:11, 8 April 2020 (UTC)
So far, the only good way to add patterns to OCA pages is what Hunting/Ultimium has done, e.g., with User:Ultimium/LeapWiki/Crawfish. But this currently means that the crawfish RLE is going to get added to the omnibus RLE collection downloadable from the main page. There are currently 66 OCA patterns scattered in among the 2300+ Life patterns. Might it be a good idea to split out all OCA patterns and provide a separate downloadable collection?

[[RLE

I'm just mimicking Apple Bottom's Day & Night Wiki. I agree, we should split out all OCA patterns. — Preceding unsigned comment added by Ultimium (talkcontribs)
Also it might be worth adjusting the template used there somehow, to clearly label the crawfish spaceship in the infobox as being in a non-B3/S23 rule. (?) Dvgrn (talk) 13:49, 19 April 2020 (UTC)
I like the current idea of adding a new OCA RLE category so they won't get lumped into the B3/S23 stuff. Yes, I think adjusting the infobox template to make it more visible that the pattern is not a CGoL pattern is worth doing. Also, there are some RLEs I'm using in some of my user pages for OCA patterns. They are RLE:Smosmos, RLE:Sakaphipush, RLE:Sakacapush, RLE:Sakaw2, and RLE:Sakasaladc8 if I didn't miss any. Saka (talk) 13:42, 30 May 2020 (UTC)
I've compiled the list of OCA RLE pages here: RLE:Ttetrominotlife, RLE:Pole2rotor, RLE:B36s245replicator, RLE:Pole3rotor, RLE:Pole4rotor, RLE:2x2glider, RLE:Awesoman3000/10p84h2v2, RLE:Lepa (hunting version), RLE:Bglepa (bubblegum version), RLE:Pedestrianlifep106gun, RLE:Mazeperiod2, RLE:Briansbrainp3, RLE:Jellyfish, RLE:Sakaw2 (i was surprised that this works), RLE:Awesoman3000/9p7h2v2, RLE:Replicator (highlife's), RLE:Bgpsgriddleblock, RLE:Tlifegatekid, RLE:2x2linepuffer, RLE:Bgrigel, RLE:2x2stills, RLE:Bgrollor, RLE:Highlifefourboats, RLE:Bomberpredecessor, RLE:Sakasaladc8 (same thing), RLE:Awesoman3000/ant, RLE:Dayandnightbutterfly, RLE:Mazewickstretcher, RLE:Lfodmoon, RLE:2x2period2oscillators, RLE:Awesoman3000/hawk, RLE:Smosmos (saka why these line-break tags with wrong-side slashes), RLE:Gemsc5648, RLE:Dayandnightbug, RLE:Dayandnightfatbug, RLE:Dayandnightsnail, RLE:Replicatorpredecessor (highlife again), RLE:Sakacapush (you know the drill), RLE:Crawfish, RLE:Movepuffer, RLE:Dayandnightflameball, RLE:Drylifeflowergarden, RLE:B36s245spaceships, RLE:Highlifereplicatorxp96, RLE:B36s245-14c300spaceship, RLE:Bgstar, RLE:Sakaphipush (i swear, all of saka's rles do this), RLE:B36s245gun, RLE:Movestilllifes, RLE:Lifehistoryexample (does this count?), RLE:Dayandnightmilkbone, RLE:Dayandnightfireball (please ab get better names), RLE:Jasonsbow, RLE:Dayandnightrocket, RLE:Dayandnightp60fireball (...), RLE:Dayandnightp120fireball (is the fireball like a variable-speed ss or what), RLE:Dayandnighttotempole, RLE:B36s245-28c1200spaceship, RLE:Dayandnightp220fireball (aaa)
I probably missed some so great
Also RLE:1234_synth uses b2s23 instead of b3s23 so that's just lovely Bubblegum (talk) 05:06, 31 May 2020 (UTC)

"Non-Lifelike" CAs -- cleanup suggested

This post by BokaBB got me looking at the rule pages that have been collected in the OCA namespace. Category:Life-like cellular automata includes several isotropic non-totalistic rules (OCA:GlideLife, OCA:Goat Flock, OCA:Just Friends, OCA:Salad, OCA:Snowflakes, OCA:Tlife, and OCA:Wlife, so far, and I might have missed something.) There seems to be standard wording in all of these saying " {Rule R} is a non-totalistic Life-like cellular automaton". But this just plain isn't right: a non-totalistic CA can't be Life-like.

The standard wording links to Non-totalistic Life-like cellular automaton, which shouldn't really exist because technically there is no such thing. I guess the right name for that article should probably be just Non-totalistic cellular automaton, and "Life-like" should also be removed from Isotropic non-totalistic Life-like cellular automaton and Non-isotropic_Life-like_cellular_automaton (both the titles and the article text).

Does anyone have any objection if I do a bunch of editing to fix this, before the problem gets any worse? Or does someone really want to LifeWiki-officially redefine what "Life-like" means? The current definition is so widely accepted that it's even on Wikipedia: "Life-like" implies an outer-totalistic rule, so it's much more limited than the space of isotropic non-totalistic rules.

I'd like to add a couple of new LifeWiki categories (or have someone competent do it for me): one for "Other Cellular Automata" in general (Life-like and isotropic NT rules), and one for isotropic NT rules specifically. At the moment it seems kind of hard to find a category page for all OCA: namespace articles -- you can't just search for "OCA" or "OCA:" (right?)

If we want to be really brave, we could make the isotropic NT category something like "Iso-NT". If that caught on -- big "if" -- then there would finally be a short standard way to say "isotropic non-totalistic". Maybe someday people could just say "isont" or "anisont" and expect to be understood. ("Aniso-NT" would be the equivalent category for "anisotropic non-totalistic", but there doesn't seem to be any point in creating that category since nobody's come up with a rule worth naming in that rulespace yet.)

... If anyone does have an objection, please suggest something we could do instead! Dvgrn (talk) 16:40, 7 April 2020 (UTC)

This is probably a bit late, but I think those bunch of edits are a good idea (Which it appears you have not done yet). And yes, I do agree with defining "Life-like" as strictly for Outer-totalistic rules. Nope, you can't just search "OCA" or "OCA:", so yeah, it's currently impossible to find a category with all the OCA rules and nothing more: The "Life-like_cellular_automata" category doesn't include LTL and multistate rules, while the "Cellular_automata" category also lists a bunch of non-rule pages such as the general articles for rulespaces and the lists of rules investigated on Catagolue (which, aren't they obsolete?).
Back on the definition of "Life-like", the inclusion of IsNT (Isotropic Non Totalistic) rules in the category of Life-like CA on the wiki will probably make new CA-Enthusiasts think that they are included in Life-like CA, which might have an effect on the forum.
Also, over on the Discord the standard way to write "Isotropic Non-Totalistic" quicker seems to be "INT", and Heavpoot suggested (somewhat jokingly?) "AINT" for "AnIsotropic Non-Totalistic" (Perhaps "AiNT" is better), or we could just refer to them as "MAP Rules", although yeah, that isn't very good, as MAP includes Isotropic and totalistic rules as well. Saka (talk) 14:04, 30 May 2020 (UTC)
Not only Discord uses this name - "INT" is also well known on the forums. Ultimium (talk) 22:00, 4 June 2020 (UTC)

Expanding Covered OCA Rules

Does anyone think that having articles for rules beyond Life-Like and Isotropic Non-totalistic should be on here, like Wireworld or Langton's Ant? These would still go under the OCA namespace, obviously. If anyone has any thoughts on this, that would be great. AforAmpere (talk) 5:02, 16 April 2020 (UTC)

As far as I'm concerned, articles for any reasonably well-known rule would be very welcome in the OCA namespace. Wireworld and Langton's Ant definitely count as good examples.
A big reason for inventing the OCA namespace was to provide a place for this kind of information, without accidentally cluttering up the "Life" part of the LifeWiki. Dvgrn (talk) 14:08, 19 April 2020 (UTC)
I would like to contribute to these pages. Ultimium (talk) 02:00, 20 April 2020 (UTC)

Mmm, a similar discussion took place three years ago, see LifeWiki:Tiki bar/Archive/2017#Lists_of_rules. Speaking of articles for other cellular automata, how about those red links in the list of Generations rules? There are a variety of rules, and therefore it will be a huge amount of work if we want to write a page for each. Or should we consider their historical/current significance first? Need Generations experts here. (I dislike red links...Wait, I shouldn't show personal feelings here.) GUYTU6J (talk) 16:50, 13 May 2020 (UTC)

Personal feelings? Nah, that's just on the actual article pages. I really like red links, because they encourage other people to do documentation work... It would make sense to me to add a page for each of the major Generations rules in the old MCell 4.20 collection, just for starters. There's usually some descriptive text that could be lifted out of Mirek's representative {RULENAME}.mcl file, as a starting point.
The named Generations rules in the MCell pattern collection are Banners, Bombers, Brain 6, Brian's Brain, Burst, BurstII, Caterpillars, Chenille, Ebb&Flow, Ebb&FlowII, Faders, Fireworks, Frogs, Glisserati, Nova, Rake, SediMental, Snake, Spirals, StarWars, Sticks, Swirl, Transers, TransersII, Wanderers, and Worms. There's also an "Other Rules" folder, but it has just a couple of patterns in it -- one in the Star Wars family, and an unnamed explosive one (345/24/25) with a side-effect production of some Rule-90-ish behavior. Dvgrn (talk) 15:08, 30 May 2020 (UTC)
Right, I've made attempts to write for Star Wars. It still needs some content about various constructions before releasing to the OCA namespace, but I lack time now. (EDIT: I've released it on June 22, further compositions welcome!) GUYTU6J (talk) 03:21, 19 June 2020 (UTC)

By the way, putting a somewhat off-topic request here: can we integrate a LifeViewer equipped with command RANDOMIZE in Template:Rule? The command is for generating a random 64×64 soup upon launching the viewer (or refreshing the page):

x = 0, y = 0, rule = B3/S23 ! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ RANDOMIZE THUMBLAUNCH OFF THUMBNAIL THUMBSIZE 2 ]]
An example soup in rule B3/S23 (click above to open LifeViewer)

It works well with 2-state rules. For rules with more states, like Generations, more commands is needed to specify which state to use. GUYTU6J (talk) 06:05, 22 June 2020 (UTC)

Criteria for notable INT rules

The discussion at LifeWiki:Tiki bar/Archive/2019#Non-notable isotropic rules inspired me to move OCA:Wlife to User:Evin/Wlife. Previously the reason for proposed deletion was "non-notable rule; forum thread only has 9 posts in total". Sounds reasonable, right?

But then here come the questions. Can we develop some universal criteria for a section in LifeWiki:Notability about an INT rule? Which rule warrants an article on OCA namespace, and which rule is at most qualified for a User subpage? Rules differ greatly in behaviour and potential for interesting technology, but still I think "Well-explored syntheses", "Turing-complete", "Orthogonoid/Demonoid engineered explicitly", or something along these lines, may suffice for the judgement.

Related, should we encourage users to write about their custom INT rule in their User subpage first, and move it to the official OCA namespace after reaching a consensus that it is well-developed and notable enough according to some guideline? GUYTU6J (talk) 02:52, 3 June 2020 (UTC)

I don't think that a rule has to be Turing-complete and have a Orthogonoid/demonoid to be interesting / to warrant their own wiki page, but that's just my opinion. Making a universal definition for interesting INT rules will be hard, as is making a strict definition of interesting anything. But if we do make one, maybe we could judge the rule by it's activity as well? Number of active explorers, number of (useful / constructive) posts in the rule's thread (that are related to the rule, not off-topic chatting), that kind of stuff. One problem I can see with that approach, however, is that some genuinely interesting rules do get unnoticed, but maybe that's outside the scope of this... discussion?
On the last part, yeah, I think that's a good idea. Related to that, is the wiki O.K.a.y. with a bunch of pages under the userspace? We already have a good amount, and if we encourage that we'll have some more. Also, maybe encourage users to write a page under their username if they think their rule is interesting enough (Maybe that will slightly decrease the number of user subpages?).
I don't think we should have strict guidelines but rather a board / panel of people that will decide if a rule warrants a wiki page.
EDIT: I forgot, I do think that the current Wlife page is a bit too empty to be in the official™ OCA namespace. Saka (talk) 04:55, 3 June 2020 (UTC)
Well, the activity of a rule is indeed another possible consideration, though more subjective. Besides quantity, explorers and posts are also of different quality, which is more related to the rule's known interestingness. Also time is an important factor here, as understandings usually cumulate over time. (Of course, given infinite time and adequate utilities, genuinely interesting rules are bound to be realized and explored in-depth, eventually warranting an OCA article.)
Pages under User namespace are not offical, they cannot be found in the simple search on the main page unless you add "User:". They record semi-interesting stuff with potential to be officially notable. For notable rules this can be a primary filter. But wait, what if someone wants to contribute to a rule under someone else's user space?
If the secondary filter for notable rules were to be a group of people, there could sometimes be conflicts of intererst and other complex issues. GUYTU6J (talk) 07:50, 3 June 2020 (UTC)
Sorry for non-constructive comments, but well-developed syntheses seems like a personal bias rather than an actual factor of rules' interestingness. Others seems good enough to me. Ultimium (talk) 11:01, 4 June 2020 (UTC)

2-state rule cleanup

Yet another discussion on the non-Life part of the wiki... I noticed that User:Ian07 deleted a few pages (Tq6, Movingstrings and Lotsofdots) under Rule namespace on Feb 15 due to "2-state rule, no ruletable needed".

At the time of writing there are 73 pages with 2-state range-1 rules on a 2-dimensional square grid. Since they can all be described with MAP strings, I suggest discarding these pages like the previous examples. We need to do the following:

  1. Look into the rule tables and figure out their MAP strings,
  2. Submit the rule names as aliases of the MAP strings, or edit the (if) very few instances mentioning the manes names on the forums.

Does anyone want to help? GUYTU6J (talk) 15:47, 4 June 2020 (UTC)

Here are a couple of initial contributions:
1) For a few of these rules, the thing that makes them rule-table-worthy might be not the rule but the associated icons. HexLife and Pentagonhood are examples, I think.
2) I think that the "figure out the MAP strings" part can be done fairly simply with a version of this MAPper Lua script, by installing each rule in Golly, running the script, and copying out the reported MAP string.
Thanks for working on this! Rule namespace maintenance is a big job for one person, but hopefully many hands can help lighten the work. Dvgrn (talk) 18:48, 4 June 2020 (UTC)
Once the aliases are submitted LifeViewer will prefer them to any Rule namespace definition. Regarding Icons: at some stage I'll add support for Icons but it won't be any time soon. For Hex neighbourhood rules there is a MAP format that supports these and will cause LifeViewer to use hexagonal cell display. There's also a VN MAP format but visually it uses square cells like Moore. Help->Info->Pattern will let you know whether LifeViewer is using a Rule namespace definition (there will be a Type of @TABLE or @TREE if so). Chris Rowett (talk) 03:52, 5 June 2020 (UTC)
Good. Besides a spelling fix, I have a few minor questions:
Is there a page which lists those aliases, so that one can search (with Ctrl+F) through/copy them?
The rule tables were added to LifeWiki in an "auto-import project". Where can I see the details of the project? Can it be modified so that 2-state rules are not collected?
Do we need to archive the references on the rule pages? GUYTU6J (talk) 06:47, 5 June 2020 (UTC)
You can see the list of aliases in LifeViewer with Help->Aliases. While the Help is displayed pressing Ctrl-C copies the topic to the clipboard.
For the auto-import project Dvgrn wrote the script to scan the forums and find the rules. I then used the output from this to create the required rule definitions (adding @TREE sections where missing) which he then uploaded to the Rule namespace. Built-in rules (like B3/S23 etc) and existing LifeViewer aliases were filtered out. Chris Rowett (talk) 09:11, 6 June 2020 (UTC)
Re: auto-import scripts --
That project was a one-time effort, and nobody is currently planning on ever running those scripts again. They were a combination of one-off Python scraper scripts and some Selenium automation trickery. From now on, as new rules get created, there will be a strong incentive for anyone posting new-rule patterns to the forums, to just throw a copy immediately into the Rule namespace, so that LifeViewer can display those patterns. So -- at least according to my theory -- there's no need to run any further automated surveys to try to pick up new rules posted on the forums. We'd get a lot of duplication and possible conflict headaches, for no obvious benefit.
A survey that could be done is to run back through old posts and look for old-style rule tables. There are a few of those that were missed because they don't have the @TABLE keyword at the top of the code block. But I think most of the commonly used rules have long since been converted to @TABLE format, so this would just pick up a few out-of-fashion rules from the early 2010s.
The auto-import script that _is_ run semi-regularly, every month or two, is the one that takes new embedded and infobox patterns from the RLE namespace and turns them into commented patterns added to the all.zip LifeWiki pattern collection. Dvgrn (talk) 15:29, 19 June 2020 (UTC)
Alright, I'm done. Here's the list of aliases I created:
  • Bigship - B2ei3eiqry4ny5ajkr/S23ajkr4jnry5inq
  • WolfVN-W50_B14_S34V - B2an3cjr4acij5nqy6ak/S2cn3cqy4cny5e
  • B2ex3-lS23 - B2en3-a/S23
  • randomnn - MAPA1Az8wMAqgAAUADAAAAAAAAAgMAAAIAAgICAwAAAgAAAAAAAiACqAAAAAAAAAAAAAACAAIgAgACAgIAAAACAAA
  • water - MAPABAbrwAA//8AQltdAAD+/8Aa/f8AAP//YgD//wAA//8AAP//QAD//wBA//8AAP/fAgD3+wKA//8AIPZ/AAD//w
  • B45_S034_N21 - B2ei3-ce4cny/S02-cn3cinqy4c
  • HexLife (Saka) - B3o/S234-o6
  • rules6 - MAPAgl/+0Ug/fVAIv/9AADdPwDi9/uAQft5qIDtlQgA/b8gAP//AAD//wAQv/8AAP7+AhD/+gAA/f8EAv//AID//w
  • x-rule - MAPBSB64CCTqARFBImEADAGBSCTgICTSIAAADCFCSTAAAANAMEUBCKEBchCE00YAE3IACSFACCIQQDIIF4UIIAGSA
  • pentagonhood - MAPEWYRZmaIZogRZhFmZohmiGaIZoiIAIgAZohmiIgAiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB
  • B578_S4567_N31 - B3-ce4aikqtwz5e/S2-cn3-ce4cny5e
Notes:
  • B45_S034_N21 was anisotropic as a .rule file, but intended to be isotropic.
  • The original name of HexLife (Saka) was just HexLife.
  • B578_S4567_N31 simply did not work as intended. The inferred rule preserves everything described except the r-pentomino, which should just be an error in the original. I don't know.
I'd say HexLife (Saka) and pentagonhood should stay where they are due to their @ICONS sections and everything else could be cleaned up.
Also hey, did you know you can customise your signature? bubblegum-talk|contribs 00:33, 29 July 2020 (UTC)

Topics article suggestion

Some thread-digging found a post listing the topics in Game of Life. Anyone putting it on the LifeWiki? I have little time on this. GUYTU6J (talk) 06:10, 18 June 2020 (UTC)

It would be really interesting to try to come up with a list of all of the esoteric sub-fields of Conway's Life that have been studied over the last five decades, including whatever links and references are available for each topic. OCA topics should have their own list, no doubt, for stuff like record-breaking RROs, Spaceships Made of Spaceships, the 5S project, micro-Orthogonoids, etc., etc.
Let's see, here's one more list for Conway's Life to be integrated. Also two more lists of topics have now been cleaned up a bit and dropped in User:Dvgrn/Life_Topics. Dvgrn (talk) 20:21, 18 June 2020 (UTC)
That's a wonderful toplevel design! Actually the list in my quote was adapted from that in yours. By"LLLS" in volume VII it means LSSS, right? Also, where would Project von Neumann and existing tutorials on LifeWiki go in this scheme? GUYTU6J (talk) 03:44, 19 June 2020 (UTC)
Ha, yes, LLLS is a typo, now fixed. Project von Neumann hasn't progressed far enough yet to deserve a place on the list, probably. Maybe give it a few more years. I at least won't be spending time on it until the Life textbook is all wrapped up and out the door.
Good suggestion on the tutorials. I've gone through the outline and added a few items, and added links to tutorials when they're available. Will try to go back and annotate everything else that's mentioned in the outline, a volume at a time... might take a while.

Except for "Volume 1", which will actually become a generally-available PDF sometime in 2021, I suppose the outline is kind of heavy on specific patterns and light on general theory. Maybe the "list of topics" should really be an article, separate from my "outline of explanations of large constructions" (which probably doesn't rate an article). As I add more "volumes", I guess some of the later ones get more into covering higher-level topics, but it's probably a confusing way to organize things for a general audience. Dvgrn (talk) 12:40, 19 June 2020 (UTC)

Embedded-viewer variant collections

I just tried some experiments with using embedded viewers floating to left, right and center, in the Fx77 article.

It looks like it's always going to be a little tricky to get this kind of viewer stamp collection to flow correctly on the page, cooperating with the infobox -- at least, unless someone can put together some very very clever templates. It seems to be far beyond my web layout skills.

I found that the old trick of adding

<div style="clear:both;"> ... </div>

almost worked well for flow control -- for example, to force the centered Fx77+R64 to drop below the two Hersrch Fx77 variants, Fx77S and Fx77SW. This looks okay on a small laptop screen, but produces ridiculous amounts of whitespace on a larger monitor, so I removed it. The clear:both trick is particularly unwieldy when a pattern has a very lengthy infobox, because all the following text drops below the entire infobox -- not just below the most recent embedded viewers.

Also, it seems as if I often get stuck having just one left-aligned, one right-aligned, and one center-aligned embedded-viewer thumbnail. I'm thinking that there are a number of medium-sized stamp collections that it would be good to get into LifeWiki articles, e.g., maybe representatives of the sixteen classes of glider timing adjustment circuits. I've never gotten a midsized collection like that to look any good on multiple monitors, but maybe if they all just float left with THUMBNAIL THUMBSIZE 3 in LifeViewer, that will be about the best we can do?

I did find that captions could be improved by centering with

<div style="text-align:center;">first-line caption<br /><br />extended-caption<br /><br /></div>

Does that look tolerable to everyone else? Unless this is added, EmbedViewers with position=center will have centered caption text, but position=left and position=right EmbedViewer captions will both have left-justified text, which doesn't look so good. The automatically-added last two lines still end up left-justified in those two cases, unfortunately; I didn't attempt to fix that for the Fx77 article.

In general, if anyone has better suggestions for dealing with page flow issues like these, please let me know! Dvgrn (talk) 15:51, 1 July 2020 (UTC)

Link to Discord server on navbar?

So today ApChrKey joined and said something about how the invite link was really hard to find. It is on links but at the very bottom. (I don't know how that affects it but whatever) Macbi suggested that we could put it up top on the navbar or whatever it's called. Given that we already have a way to cite it I don't see why we can't have a direct way to access it. Bubblegum (talk) 22:56, 10 July 2020 (UTC)

Time to delete Template:LinkWeisstein?

At this point, I think it's unlikely that the site is going to be updated so that this template can be re-enabled. As it stands, all this template does is produce an ugly piece of whitespace in articles such as toad. Any objections to deleting it? (note that I can semi-automatically remove all the occurrences beforehand with AutoWikiBrowser) Ian07 (talk) 16:40, 18 October 2020 (UTC)

Excessive barberpole articles

In light of the recent merging of Template:Vessel articles, we should probably consider merging some of the larger barberpoles as well, as most people seem to agree that going up to quindecapole is pretty excessive. However, this raises the question of what the new cutoff point should be. I'd say we should keep at least everything up to heptapole, since all of those have shown up naturally. Note that although duodecapole does not have any sample soups in any symmetry, tredecapole does, making that the largest semi-natural barberpole. Ian07 (talk) 14:11, 20 October 2020 (UTC)