Difference between revisions of "LifeWiki:Tiki bar"

From LifeWiki
Jump to navigation Jump to search
(→‎Next Steps: pname fixes and .cells creation mystery)
(76 intermediate revisions by 9 users not shown)
Line 9: Line 9:


==Archived discussions==
==Archived discussions==
:''Note: active discussions are not archived.''
:''Note: active discussions are never archived while still active.''


* See [[LifeWiki:Tiki bar/Archive/2016]] for Tiki bar discussions started in 2016.
* See [[LifeWiki:Tiki bar/Archive/2016]] for Tiki bar discussions started in 2016.
* 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.


== LifeViewer inline patterns versus JavaRLE ==
== Conduits and converters ==
 
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...".
 
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."
 
It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to go.  When 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.
 
[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.]
 
... And we can probably get rid of [[Template:Reflector/Doc]] while we're at it, no?
 
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)
 
: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)
 
:[[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)
 
:: It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to go.  There 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)
 
:::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)
 
== Lexicon tags ==
 
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.
 
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.
 
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.)
 
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.
 
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].
 
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.
 
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.
 
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.
 
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.
 
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.
 
Thoughts? [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:49, 18 July 2018 (UTC)
 
: 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.
 
: 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.
 
: That's a lot of small changes to a lot of articles with every Lexicon release, though.  Does 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?
 
: 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)
 
::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.
 
::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.
 
::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.
 
::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?
 
::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.
 
::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.
 
::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.
 
::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.
 
::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 07:50, 19 July 2018 (UTC)
 
::: 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 more.  We 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.
 
::: 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)
 
::::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.
 
::::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.
 
::::Our options there would include at least the following:
 
::::# 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.
::::# 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.
 
::::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.
 
::::<small>(And by "we", I mean whoever's willing to do that job.)</small>


As discussed [http://www.conwaylife.com/forums/viewtopic.php?f=&p=53183#p53183 in a questions thread on the forums] -- do we know enough about LifeViewer, and is it stable enough for all users on all browsers as far as we know, that we should adjust the [http://www.conwaylife.com/wiki/LifeWiki:Pattern_pages Pattern Pages] howto and checklist to explain how to do inline RLE for secondary images in an article, without the nuisance of getting pattern files uploaded as a separate admin-only step?
::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 18:16, 20 July 2018 (UTC)


More ambitious: might there be some clever way for non-admin users to contribute the baseline pname.rle and pname_synth.rle files directly, using a similarly easy inline-RLE method? This is already possible by creating a raw RLE page for the pname pattern, but it doesn't work for pname_synth, does it?  Could those RLE chunks be hidden in the actual article text somewhere, in some standard location?
:::::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.)


It still seems good to have copies of these patterns available in the downloadable ZIP file, thoughDoes that mean we also need a mechanism to assign a pname to each LifeViewer inline pattern?  And then some (semi-automated?) way do the upload, and note in the article that that has been done.
:::::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 onesBut 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.


A vaguely related note: the pattern-file admin maintenance page is getting a little unwieldy as the number of patterns goes up -- it lists every pattern in one page, which is so long now that the load time is really noticeable sometimes, at least on my system[[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:27, 26 November 2017 (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 articleSeems 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.


:You're right, pname_synth isn't currently recognized. This could be changed; all we'd need to do is update the pattern templates accordingly.
:::::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)


:I'm not sure I'm a fan of putting the RLE into the article text proper. The most natural place for it would be an infobox parameter, but that might run into subtle parsing issues. For example, I'm not sure if this:
::::::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)


::<tt><nowiki>{{Oscillator</nowiki></tt>
:::::::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.
::<tt><nowiki>|name  = Prancing Ponies</nowiki></tt>
::<tt><nowiki>|pname = prancingponies</nowiki></tt>
::<tt><nowiki>|p    = 49</nowiki></tt>
::<tt><nowiki>...</nowiki></tt>
::<tt><nowiki>|rle  =</nowiki></tt>
::<tt><nowiki>x = 20, y = 17, rule = B3/S23</nowiki></tt>
::<tt><nowiki>...</nowiki></tt>
::<tt><nowiki>|...  = ...</nowiki></tt>
::<tt><nowiki>}}</nowiki></tt>


:...would work, or whether it might break because there's equal signs in the value of the <tt>rle</tt> parameter. I ''think'' MediaWiki is smart enough to handle this these days, and a similar parameter to [[Template:EmbedViewer]] has not caused any trouble yet as far as I'm aware, but this sort of thing still makes me nervous. (The safe way of handling this would be to escape all equal signs in the value passed using an appropriate template, as <tt><nowiki>{{=}}</nowiki></tt>, but users ''will'' forget this, and if it then doesn't work they ''will'' not understand why.)
:::::::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.


:The above applies equally to the synthesis RLE, of course. On that note, having the synth RLE for <tt>pname</tt> live in <tt>RLE:pname_synth</tt> or <tt>Synth:pname</tt> or so would be saner. But it would make the RLE less accessible (though of course the pattern templates could also be rigged to check whether the RLE exists, and show a big red "click here to add the missing RLE" link if not.)
:::::::[[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 08:31, 28 July 2018 (UTC)


:As always, TIMTOWTDI (There Is More Than One Way To Do It)...
== Object frequency classes ==


:For secondary patterns currently using [[Template:JavaRLE]] I think migrating to an on-wiki solution is definitely sensible though. [[Template:EmbedViewer]] already exists and can be used (and [[Special:WhatLinksHere/Template:EmbedViewer|several pages are already using it]]), even if that template's still got room for improvement.
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).  


:I do agree that the ZIP file containing all uploaded patterns is valuable and should be kept if at all possible. (Do we have statistics on how often that's downloaded, BTW?) As I said on the forums, generating it from on-wiki RLEs would just be a matter of adjusting the generator script, but someone's got to do it, and unless someone else has shell access to conwaylife.com's hosting, it'd probably have to be Nathaniel (who I understand is busy these days with rather more important matters).
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.


:(Might be a good time to bring up (again?) an old idea of mine, namely that of a Conway Life Foundation that could take some of the responsibility and workload off of Nathaniel's shoulders. Hey, it's worked for N. J. A. Sloane and the OEIS, and Larry Wall and Perl, and Jimbo Wales and Wikipedia...) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 21:29, 28 November 2017 (UTC)
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.


:: Just a note on the technical side of things -- an equals sign within a template parameter indeed won't cause any problems (as long as the parameters are named, as is the case in the pattern infobox templates). The only problem that might arise is if the RLE has vertical bars | in them, but I don't think there's any reason that should ever happen.
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.


:: I agree that RLE data should be separated from the main page data in some way, since it is somehow more important and/or should be more "static". We could keep using pattern files, but that has the not-admin-friendly downside. We could use the RLE namespace, which in my opinion isn't bad (maybe slightly clunky). Perhaps a more elegant alternative would be to use the new [https://www.mediawiki.org/wiki/Extension:Cargo Cargo extension] that has recently been made available for MediaWiki. I've tested it out on another wiki that I run, and it works pretty fantastically (though I'd have to update MediaWiki here to a more recent version before it'd work). It introduces a bit of server overhead, but not *too* much based on my testing with it. What it does is makes data entered into templates query-able across the wiki, so on any page of the wiki we could write code that looks something like <nowiki>{{GetRLE|Glider}}</nowiki>, and it would grab the RLE from the pattern template on the "Glider" page. [[User:Nathaniel|Nathaniel]] ([[User talk:Nathaniel|talk]]) 17:42, 1 December 2017 (UTC)
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.


::: The Cargo extension looks interesting, but it's a couple of steps removed from what we can do today.  Maybe what we should do is to keep implementing Infobox patterns using uploaded pattern files or the RLE: namespace, whichever one we have -- but also document how to set up subsidiary patterns in an article using LifeViewer and inline RLE, since that's the only way that non-admin users can add such patterns without admin help.
...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)
::: The inline LifeViewer method doesn't require the additional patterns to have their own unique pnames, but the docs should ask for one and give a standard way of recording the pname.
::: Whenever we come up with a better method, and hopefully while there's still only a manageable number of LifeViewer-with-inline-RLE patterns, we'd probably want to commit to an admin-led effort to convert all trial-format pages to the new long-term format.
::: That seems like one possible way to keep moving forward in smallish steps, while also avoiding the current problem of confused and mystified potential contributors.  Thoughts? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:39, 1 December 2017 (UTC)


:::: Sorry for the late reply... I agree with Dvgrn, Cargo looks neat, but I'm not convinced it'll help us here. For making it easier for non-admins to contribute/edit RLE files I still think the best current way to do this is to either:
(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.)


::::* keep RLE in wiki pages, in the existing RLE namespace or a new one (say "RLE synth"); or
: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:
::::* use regular on-wiki file uploads for RLE files. I've never tried this, but the File: namespace isn't just for images, so I'm sure it could be made to work.


:::: [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 22:02, 9 December 2017 (UTC)
<pre>
:::::Is it time to make an executive decision about supporting <tt>RLE:pname_synth</tt> or <tt>Synth:pname</tt>, with the infobox template rigged to add a raw-RLE link if that page exists?  Either option seems fine to me.
#!/usr/bin/perl
:::::This evening I'm feeling brave enough to start editing the Help: files to tell J. Random User step-by-step how to add patterns for use with LifeViewer.  That means deciding what to say about including/not including RLE header lines, comments, etc. The possibility of adding _synth files this way seems like a minor remaining question mark.
:::::Eventually I think all these added patterns in the RLE: namespace should be automatically vacuumed up somehow and added to the pattern collection -- presumably with some kind of comparison tool to make sure that patterns already in the collection are the same as the versions in the RLE: namespace.  (Will work on building that tool later.) [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:04, 21 February 2018 (UTC)


::::::Yes, let's [http://i.pinimg.com/originals/86/76/ad/8676ad94c53937330a085a7d0a9bc13a.jpg Make It So]! And automatically copying on-wiki RLE into the pattern collection? Yes, ''please''.
# usage eg.:
# perl ../frequencyclasses.pl b3s23.C1.txt >frequencyclasses.txt


::::::Still not sure whether <tt>RLE:pname_synth</tt> or <tt>Synth:pname</tt> would be the better choice; I'm actually leaning toward the former right now. It'll make the script that little bit less complicated; it fits our existing naming scheme for pattern files, images, etc.; and it won't require a new namespace to be configured. (Of course you can create prefixed pages without a namespace as well, with the prefix just being part of the regular title, but that interacts badly with things like [[Special:RandomPage]]; and moving pages over ''after'' a new namespace has been created... well, there's still at least ghost <tt>RLE:</tt> page lingering in the Main namespace right now that is being shadowed by an <tt>RLE:</tt> namespace counterpart.) So yeah, leaning towards <tt>RLE:pname_synth</tt> right now.
use Modern::Perl '2016';


::::::As for what should be included in RLE snippets, I think ideally it should be this, at least:
# only patterns with more than $cutoff occurrences should be considered.
# mark all other patterns with an asterisk.
our $cutoff = 10;


#N Pattern name
# throw away header line
#O Discoverer
<>;
#C One-line description
#C Wiki-page link
(actual pattern)


::::::We probably can't reasonably expect random users to adhere to that, always --- but guidelines are good having, and if it's on-wiki it's easy to edit.
my %objects = ();
my $mostcommon = -1;
my $mostcommoncode = "";
while(<>) {
    chomp;
    next unless m/^"([^"]*)","(\d+)"$/;


::::::The only issue I can see right now is conflicts. Suppose you have an RLE file, and an on-wiki RLE snippet, and they're not the same. How do you tell whether a) the RLE file was uploaded by an admin (and should thus presumably ''not'' be overwritten), and b) the RLE file was generated from an earlier revision of wiki page, and thus ''should'' be overwritten?
    my ($apgcode, $count) = ($1, $2);
    $objects{$apgcode} = $count;


::::::One way around this would be to put a suffix on the files generated from on-wiki RLE snippets, so that e.g. <tt>RLE:ponyexpress</tt> would become <tt>ponyexpress_wiki.rle</tt>, or some such thing. Conflicts could then be handled by simply ''assuming'' that any file whose name is suffixed <tt>_wiki</tt> was imported from the wiki and is fair game for being overwritten (and if it was not, then the uploading admin only has themselves to blame). But is this ideal?
    if($count > $mostcommon) {
        $mostcommon = $count;
        $mostcommoncode = $apgcode;
    }
}


::::::Flagging files externally would also be possible, but the flags should be visible on the mod panel in some way, and they should reset if a file is manually uploaded there.
my %frequencies = ();
foreach my $apgcode (keys %objects) {
    my $frequencyclass = sprintf("%.1f", (log($mostcommon / $objects{$apgcode})) / log(2));
    $frequencies{$frequencyclass}->{$apgcode} = $objects{$apgcode};
}


::::::Alternatively we could declare this to be a non-issue and say "the wiki takes precedence, period". This would be the way to go if we want to deprecate the mod panel in the long term. If we did this, of course, we (and by "we" I mean you, heh) should audit the uploaded RLE snippets we've got to make sure we'd not be overwriting any existing RLE files with inferior content. (Comparing conflicting files to see which ones are actually different could also be done programmatically, of course.)
foreach my $frequency (sort { $a <=> $b } keys %frequencies) {
    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>


::::::But that's enough rambling from me! [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:08, 22 February 2018 (UTC)
:(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)
:::::::Sounds good -- RLE:pname_synth it is, then.  I'll see if I can dig up a sample or two to add on-wiki, with a suitably modified header:


#N pname_synth
::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?
#O Discoverer, optional date (?)
#C Description -- can be one or multiple lines
#C Wiki-page link
#C http://www.conwaylife.com/patterns/{pname_synth}.rle
{actual pattern}
#C LifeViewer config


:::::::I like having the date, if it can be collected, but there's never been a really good place to put it. It sort of ought to have its own tag, like #D {date}, but #D traditionally meant something else in old Life32 files, and it's a little awkward having it take up its own line anyway, so I usually just put it in the description.
::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)
:::::::It's also nice to have the direct link to the actual pattern file, when that exists.  That might cause headaches because it '''won't''' exist until the hypothetical periodic upload happens, and then it will exist.  So probably both the wiki-page link line and the pattern link line really ought to be added programmatically, to signal that the upload has happened.  I think I have the tools to do that, but it's a bit ugly -- will experiment and (eventually) report back.
:::::::Another awkwardness is the question of whether or not to include a LifeViewer config line, when ''that'' exists, in the uploaded RLE pattern.  This is looking forward a little, but I'd like to programmatically grab that and throw it in also.  Mostly this is because lifeviewer.lua is a thing, and it may eventually allow LifeViewer-like displays in Golly if the config line has been carried over.  Just tried it on-wiki and it's a bad idea to have it in the RLE: namespace due to conflict error messages.
:::::::Next question:  we have [http://conwaylife.com/wiki/Category:Pages_with_raw_RLE_code_but_no_uploaded_pattern_files Category:Pages_with_raw_RLE_code_but_no_uploaded_pattern_files] and [http://conwaylife.com/wiki/Category:Patterns_with_RLE_snippets_but_no_LifeViewer_configuration Category:Patterns_with_RLE_snippets_but_no_LifeViewer_configuration], but that only applies to articles with an associated primary pattern, not articles with one or more subsidiary LifeViewer illustrations.  What's the best way to get a link list for everything in the RLE: namespace? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 11:46, 22 February 2018 (UTC)


::::::::Looks good! I just realized that due to MediaWiki's underscore conversion, <tt>RLE:${pname}_synth</tt> will become (i.e. look like <tt>RLE:${pname} synth</tt>). I don't know what title MediaWiki saves the page under internally, so it may be a good idea to code conservatively and convert spaces to underscores.
:::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)


::::::::Re: dates: what does <tt>#D</tt> traditionally mean, then? BTW, we might be able to use <tt>#T</tt> (for "timestamp") or so instead.
::::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)


::::::::LifeViewer-config embedded in the RLE file itself, that's certainly doable; if this is done we may eventually want to remove the relevant infobox parameter, it shouldn't be needed anymore then. (The "default configs" could then also go, in a second step.)
==Infobox vs. EmbedViewer==
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 forth. The most recent example of this kind of imported Lexicon article is [[line crosser]].


::::::::Re: pattern file links not being "live" until files are uploaded: as you say, this should be fine if those links are added (and the files uploaded) programmatically. Perhaps the script could also update the on-wiki pattern file?
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)


::::::::Getting a list of all <tt>RLE:</tt> pages -- you can do that on-wiki using [[Special:AllPages]], specifically [[Special:AllPages/RLE:]] ([http://conwaylife.com/w/index.php?title=Special%3AAllPages&from=&to=&namespace=3792 here's a better link]). From a script, you're probably better off using the [https://www.mediawiki.org/wiki/API:Main_page MediaWiki API]. I've no experience with this, but the [https://www.mediawiki.org/wiki/API:Allpages <tt>allpages</tt> query] looks promising (you can pass a parameter indicating which namespace you're interested in).
: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)
... What does #D mean?  You'll be sorry you asked.  Summary [http://cranemtn.com/life/blog/RLEFormat.htm here].
Xlife tag -- #D x,y: coordinate differences from
the previous point, separated by newlines
Life 1.05 format -- comment, instead of "#C".
"D" stands for "description".
Life32 format -- initial tag in every saved pattern,
containing an ugly hexadecimal checksum.


Hmm, we start with putting standardized comments in the RLE, and now maybe just move the LifeViewer config line there too? I almost wouldn't mind thatIhe viewerconfig is generally a lot bigger and uglier than any of the other infobox parameters.
::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 LexiconRather 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)


My first thought was that it was a bad idea, because if we wanted to use the same pattern in a different article with a different LifeViewer animation (highlighting a different reaction, or whatever) then we'd have to duplicate the RLE, name it something different, and add a different config line.
== Semi-automated collection of raw RLE ==


But considering how often pattern re-use has actually happened so far -- approximately never (?) -- I don't think a tiny amount of duplication would be a problem if the case did eventually arise.  Should I be brave and start moving config lines into RLE, or is this a good time to hunt for third opinions?
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.


On the #T timestamp idea -- I wouldn't mind that too much, but unless the discovery date is going to be filled out really reliably with a #T tag, I don't entirely see why we need a new #T conventionWe could equally well say that the new #O convention is #O {discoverername}[, {discoverydate}].  I'm happier when there are fewer half-empty mandated comment lines; the date fits perfectly well on the same line with the discoverer.
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 additionsSince this was a mostly automated process, the script may have picked up a few patterns that shouldn't really be part of the collectionIf anyone wants to do a quick independent review, I'd appreciate it!


-- Yeah, there are some possible parsing problems with commas if there are multiple discoverers, which could probably only be solved by standardizing the date formatBut again, is anyone really ever going to be expecting to find a discovery date reliably with a comment-line parsing script?
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 eventuallyTo 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.


Thanks for the pointer to "All pages"The amount of wikistuff I don't know still greatly outnumbers the amount I do knowI see the redirects are helpfully italicized. Um... "RLE:Merzenichsp644blockshassling2beehivesand2rpentominos"?  What exactly is that doing in there? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:09, 23 February 2018 (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 reportIt'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.


:Ah, so the answer re: <tt>#D</tt> is "it's complicated". Gotcha. ;) And OK, let's just extend what <tt>#O</tt> covers, that's probably the most sensible approach.
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)
: [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)


:Re: LifeViewer config -- yes, it seems we're not actually reusing patterns in different places, so moving the viewerconfig into the pattern seems sensible.
== Oscillator mods ==


:FWIW, what we're currently lacking is a mechanism for "prioritizing" LifeViewer config parameters. Having a mechanism to assign different priorities to different <tt>#C [<nowiki />[ ... ]]</tt> lines would open up a variety of use cases. Imagine the pattern looks like this:
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)


  #N Amazingpattern
: 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)
#O Cathy Sue Lifeenthusiast, November 2017
#C https://conwaylife.com/wiki/Amazingpattern
#C [<nowiki />[ TRACKLOOP 30 -1/10 -1/10 GPS 15 ]]
x = 48, y = 52, rule = B3/S23
...


:Now imagine that we want to use this pattern somewhere, with a different viewerconfig, and that we could simply say:
:: 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.


{<nowiki />{EmbedViewer
:: 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)
|pname        = amazingpattern
|viewerconfig = #C [<nowiki />[ PRIORITY 1 GPS 1 ]]
|caption      = Cathy Sue's Amazing Pattern in slow-motion
}<nowiki />}


:And the explicit viewerconfig would (partially) override the embedded one, by virtue of having a higher <tt>PRIORITY</tt> (the default if none was specified would be 0).
== Conduit orientations and ghost Herschels==


:Further imagine that there was a default viewerconfig that said e.g.
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.


#C [<nowiki />[ PRIORITY -1 THUMBLAUNCH THUMBSIZE 2 GRID GRIDMAJOR 0 THEME 6 ]]
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)


:...thus setting a number of sensible defaults at a lower priority, allowing any viewerconfig embedded in the pattern file or passed explicitely to a template to override it.
: 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)


:Wouldn't that be neat? Perhaps Chris Rowett could be persuaded to add something along these lines. (Right now, IIRC, LifeViewer throws the towel in the face of conflicting configuration commands.)
:: 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.


:Finally, re: [[RLE:Merzenichsp644blockshassling2beehivesand2rpentominos]] -- that's apparently a redirect left over from when I moved a page from a previous improper name. I'll delete that, we don't need the redirect.  
:: 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.


:'''EDIT''': I've also deleted all other redirects in the <tt>RLE:</tt> namespace; none was necessary, and none had any pages linking to it (except for [[RLE:Lightweight spaceship]], which was linked to as an example of ''not'' to name RLE: namespace pages). [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 10:45, 24 February 2018 (UTC)
:: 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)


:: After looking at the ugliness of competing viewerconfig lines, I was thinking somewhat along the same lines. Another option that would allow many of the same use cases would be a simple command to allow later configs to override earlier ones:
== 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:


::viewerconfig = #C [<nowiki />[ OVERRIDE GPS 1 THEME 3 ]]
<code><nowiki>{{#ifeq:{{NAMESPACE}}|User||[[category:patterns]]}}</nowiki></code>


:: However, at the moment all such use cases require quite a bit of imagination -- we don't need to do any such thing with any current patterns, and there's a perfectly good workaround that involves adding RLE:cathysueamazingpatterninslowmotion. And since I'd much rather Chris worked on some waypoint and point-of-interest stuff, and/or support for Larger than Life which is also in the works, maybe I'll just leave this note here and see if he notices it --!  [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 13:06, 24 February 2018 (UTC)
This would categorize a non-user page as a pattern, but would do nothing on a user page.


:::That works, too -- though an explicit <tt>OVERRIDE</tt> tag would have the disadvantage that you'd explicitely have to spell it out. Say we've got a default viewerconfig for oscillators that should be overridden by more specific viewerconfigs in individual RLE files; then all these files would have to use the <tt>OVERRIDE</tt> tag. And if you then wanted to use the same pattern in several places, and tweak its viewerconfig further, as in the "slow-motion" example above, you'd have to <tt>OVERRIDE</tt> the embedded viewerconfig as well.
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)


:::Worse, it's not immediately obvious to me what the result would be in the face of conflicting <tt>OVERRIDE</tt>s. Say, the three viewerconfigs (default, embedded-in-RLE, and explicitely-passed) amount to something like the following:
== Documenting 12-Bit Still Lifes ==


  #C [<nowiki />[ GPS 4 ]]
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.
  #C [<nowiki />[ OVERRIDE GPS 30 ]]
  #C [<nowiki />[ OVERRIDE GPS 1 ]]


:::would the final <tt>GPS</tt> be 30 or 1? I'm tempted to say "1" -- but one ''could'' disagree. And besides, if it is 1, we'd be back to square one; the final result would depend on the order of the lines again, and all we'd have done is a "please don't ignore this line" tag. (<tt>PLEASE ABSTAIN FROM IGNORING</tt>... the INTERCAL version of LifeViewer?) At that point we might as well do away with the tag again and say "later values overwrite earlier ones, so the last value takes precedence".
A number of issues have appeared that I'd be interested in trying to get some kind of consensus about:


:::But yes, let's leave it for Chris. As you say, we can just upload different version of the same pattern ''if'' this ever becomes an issue in practice. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:21, 25 February 2018 (UTC)
# 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).
::::"'''later values overwrite earlier ones'''" is how LifeViewer works today. It just throws errors to tell you that's what happened. If you wrote:
# 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.


  #C [<nowiki />[ GPS 4 ]]
===Next Steps===
  #C [<nowiki />[ GPS 30 ]]
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.
  #C [<nowiki />[ GPS 1 ]]


::::LifeViewer would say:
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.


Script errors
Comments, concerns, suggestions? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:23, 21 December 2018 (UTC)
GPS 30 overwrites 4
: Also, AwesoMan3000 put the following in checkin comments for [[beacon on dock]]:
  GPS 1 overwrites 30
<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)


::::and set GPS to 1.
::'''Re: Made-up names'''


::::Two level config makes sense to me: a baseline (level 1 config) which is the default style for LifeViewer in the Wiki, and then specific extras (level 2) per pattern or class of pattern. In this case you do want "later values overwrite earlier ones" but to be able to suppress the error message the ''first time'' a later script command overwrites something defined in the baseline. The reason for ''first time'' is I'd still want to know if there are multiple definitions of the same parameter in the level 2 script since this is likely an error.
::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.
::::This suppression could be as simple as a new script command added at the end of the level 1 config.  


#C [<nowiki />[ THUMBLAUNCH THUMBSIZE 2 GRID GRIDMAJOR 0 THEME 6 SUPPRESS ]]
::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.


::::For three level config I'm not clear on how this would work. Are the config levels strictly hierarchical? [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 07:51, 26 February 2018 (UTC)
::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.


:::::I'll prefix this by saying I don't know exactly how LifeViewer parses its configuration lines -- is it line-based, or are all the lines treated as one continuous stream of config commands internally?
::And would this gain us anything?


:::::I've been assuming the former, and on that assumption my initial idea was that config lines like the following:
::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).


#C [<nowiki />[ LOOP 60 GPS 30 ]]
::I think I'm in the latter camp myself. I like named objects.
#C [<nowiki />[ THEME 6 THUMBLAUNCH THUMBBSIZE 2 GPS 3 PRIORITY -1 ]]
#C [<nowiki />[ GPS 1 PRIORITY 1 ]]


:::::would be parsed into a data structure like the following:
::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.


$VAR1 = {
:: 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.
          'GPS' => {
                      '-1' => 3,
                      '0' => 30,
                      '1' => 1
                    },
          'LOOP' => {
                      '0' => 60
                    },
          'THEME' => {
                        '-1' => 6
                      },
          'THUMBLAUNCH' => {
                              '-1' => 'true'
                            },
          'THUMBSIZE' => {
                            '-1' => 2
                          }
        };


:::::...which would, in a second step, be tranformed by eliminating the middle layer:
::The best solution I have is what one might call a four-eyes approach, where


$VAR1 = {
::# New names are valued in principle;
          'GPS' => 1,
::# But the person proposing them can't be the one naming the object on the Wiki;
          'LOOP' => 60,
::# If someone wants to add page for a (notable) object that doesn't yet have a name, they should use the object's apgcode.
          'THEME' => 6,
          'THUMBLAUNCH' => 'true',
          'THUMBSIZE' => 2
        };


:::::...thus producing the final configuration to use. Of course, this rests on the assumption that the specified <tt>PRIORITY</tt> would apply to the entire line, rather than just one parameter.
:: 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).


:::::If LifeViewer ''does'' treat all config commands as one continuous stream internally and if you don't want to change that, then yes, it may actually be enough for our purposes here to have a flag to suppress (certain) errors. We'd then just take care to assemble the various config lines in the right order in the templates, subsequent parameter values would overwrite earlier ones, and thanks to the flag, there'd not be any complaints that we had two <tt>GPS</tt> specifications, say.
::'''Re: pname changes, Life 1.05/... support'''


:::::I think the flag could suppress all errors (relating to config values being overwritten, anyway), too. After all, it would only come into effect if explicitely specified -- caveat emptor. Also, it shouldn't suppress ''all'' errors, and LifeViewer could still collect these messages and display them on request, so long as it didn't present them as script errors by default. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 11:25, 26 February 2018 (UTC)
::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.


::::::LifeViewer treats all config commands as one continuous stream and as such line breaks have no special meaning. You could still have commands that define priority or error suppression in that stream. Examples of this are the Waypoint commands [<nowiki />[ T ]] and [<nowiki />[ PAUSE ]], and the [<nowiki />[ POI ]] command. These commands signify the start of a new Waypoint or POI and the following commands define that Waypoint or POI, until another Waypoint or POI command is hit. For example:
::As for pname changes in general, they're still a pain. I'd suggest that
{{EmbedViewer
|rle = x = 28, y = 5, rule = B3/S23
o2bo2b4o2bo5bo6b2o$o2bo2bo5bo5bo5bo2bo$4o2b3o3bo5bo5bo2bo$o2bo2bo5bo5bo5bo2bo$o2bo2b4o2b4o2b4o3b2o!
|viewerconfig = #C [[ PAUSE 2 X 0 Y -10 ZOOM 6 T 100 X -100 Y -30 ZOOM 2 T 200 X 0 Y 5 ZOOM 8 LOOP 400 AUTOSTART ]]
|caption      = [[Waypoints example]]
}}
#C [<nowiki />[ X 0 Y -10 ZOOM 6 T 100 X -100 Y -20 ZOOM 2 T 200 X 0 Y 5 ZOOM 8 ]]


::::::Means start the camera at x = 0, y = -10 with zoom 6. By generation 100 get the camera to x = -100, y = -20 at zoom 2. Then by generation 200 get the camera to x = 0, y = 5 at zoom 8.
::# Whoever changes a pname is responsible for cleaning up the resulting mess; and
::# pname changes shouldn't be mandatory without a good reason.


::::::This could also have been written for clarity as:
::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).


#C [<nowiki />[ X 0 Y -10 ZOOM 6 ]]          initial camera position
::'''Re: infobox parameters'''
#C [<nowiki />[ T 100 X -100 Y -20 ZOOM 2 ]]  first waypoint
#C [<nowiki />[ T 200 X 0 Y 5 ZOOM 8 ]]      second waypoint


::::::But to LifeViewer the two are identical.
::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.


::::::So in the same way a PRIOIRTY or SUPPRESS keyword could apply to all following commands or all previous commands. My intention with SUPPRESS was that it would only suppress "overwrite" errors and not all errors. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 12:05, 26 February 2018 (UTC)
::'''Re: RLE files and raw RLE snippets'''
:::::::I certainly wouldn't object to a SUPPRESS keyword -- it's simple, and simple is good (and easier to test, too).
:::::::On the other hand, in some sense its function is to hide problems that maybe don't need to be hidden.  ''If'' we can just make a decision and stick to it, about viewerconfig lines belonging at the bottom of the RLE:{pname} pages and nowhere else, then there's really not much potential for conflicts that need to be SUPPRESSed.
:::::::Theoretically I like the idea of abstracting out some general LifeViewer settings that deal with an overall LifeWiki "look and feel", putting them in say the Pattern template, and then being able to change those settings in one place and have it change immediately everywhere.  If we want that functionality, then I guess it would be good to have at least the SUPPRESS keyword, to allow for overriding those defaults without seeing errors.
:::::::In practice, though, what settings could we possibly set at the general level and then alter later, that wouldn't break a whole bunch of carefully configured LifeViewer instances?
:::::::We're currently adding "#C [<nowiki />[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART ]]", right?  Can someone remind me where exactly that's coming from again?  After finding it in the copied text for Glider, Blinker, etc., I just looked through the Spaceship and Oscillator and Pattern templates, and did searches on "THEME" and "GRID GRIDMAJOR" and "THUMBLAUNCH AUTOSTART".
:::::::Couldn't find the source of that appended viewerconfig line anywhere.  But I did find that all these settings, including THEME, are in fact mentioned specifically in viewerconfigs here and there.  In [[Tanner's p46]], for example, the THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART is supplied automatically in the infobox, but has to be explicitly included in the glider-gun illustration in the article.  How should that illustration _really_ be done -- is there a more standard way? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 19:18, 26 February 2018 (UTC)


Chris -- thanks for the clarification re: linebreaks (not) having a special meaning!
::I'll leave this in your capable hands. :)


Dave -- these days, all pattern templates transclude [[Template:InfoboxStart]], passing the <tt>defaultconfig=</tt> parameter; that template then handles all the boilerplate code to open a pattern infobox, including the embedded viewer. The default LifeViewer configuration is loaded from <tt>Template:LifeViewer config/${defaultconfig}</tt>, assuming that exists. You can find a list of current default configurations [http://conwaylife.com/w/index.php?title=Special%3APrefixIndex&prefix=LifeViewer+config%2F&namespace=10 here], by way of [[Special:PrefixIndex]] (another handy [[Special:SpecialPages|special page]] to know about).
::'''Final note'''


How were these default configurations decided? Truth to be told, I think we simply put whatever seemed like a good idea at the time into them, the goal being (again) to cut down on boilerplate and not having to specify, say, a theme for every pattern but getting something nice and good-looking by default.
::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.


The whole mechanism could be reworked as necessary, of course. We can change these default viewer config as desired, and we can also remove them altogether and instead stipulate that all uploaded RLE snippets should include their own, including all theming.
::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.


I don't have any horses in this race, and I don't know much about the technical side of LifeViewer, so I'll just leave this to the two of you. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 19:32, 26 February 2018 (UTC)
::(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)
: Any suggestions as to how best to set up a default config for secondary illustrations, such as the one in [[Tanner's p46]]?  I think "THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART" is really pretty good as a standard.


: It seems reasonable
::: Thanks for the thoughtful review. A couple of template issues have come up where some expert advice would be helpful:
:# to assume all of those config settings in a LifeWiki context (in nearly all cases -- maybe with a slight change for still-life patterns, omitting the AUTOSTART), and
::: 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?
:# to '''not''' include any of that outside of a LifeWiki context
::: 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.
:: (so that those details won't get exported and distributed with patterns in The Future LifeWiki Pattern Collection)
::: Here's an example of an update currently in process:  we used to have an uploaded eateronboat.rle --
: -- whereas things like HEIGHT and WIDTH and GPS '''should''' be included, so they'll go at the end of the RLE:{pname} entry.
#N Eater on boat
: Seems like that strikes a reasonable balance, and avoids adding lots of THEME 6 BLAH BLAH BLAH boilerplate to each and every RLE:{pname} pageGuess I'll start gradually getting the viewerconfig lines out of existing infoboxes, and see if any unforeseen difficulties crop up. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 20:48, 26 February 2018 (UTC)
#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 articleAnd 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.


The double-square-brackets around THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART has made it the second-most [[Special:WantedPages|wanted page]] on the LifeWiki. If it's good enough as a standard, should this wanted page be created to explain that THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART is a sequence of LifeViewer commands used to give the familiar LifeWiki appearance for embedded patterns? It seems almost too tempting to resist. [[User:Calcyman|Calcyman]] ([[User talk:Calcyman|talk]]) 21:17, 26 February 2018 (UTC)
::: 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.


: Now it's the first most-wanted page, but thanks to the template changes, the request is for just plain AUTOSTART.  Probably might as well wait a while and see what else changes, before trying to explain anything... but eventually a walkthrough would be really nice, to show exactly how to build a good multi-illustration article. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:58, 27 February 2018 (UTC)
::: 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.


The style stuff should probably be in a single default config that's inherited by all the others. The current default appears to be:
::: (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]].)
THEME 6      (alive cells are black, dead cells are white, and no history colours)
GRID        (draw gridlines)
GRIDMAJOR 0  (no major gridlines)
THUMBLAUNCH  (show LifeViewer as a thumbnail that launches when clicked)


As Dave suggested AUTOSTART is not needed for still-life patterns. It'll just burn CPU cycles for no reason.
::: Okay, so here is where the difficulty shows up!


Perhaps we should have "LifeViewer config/default" that contains just the style stuff above and is always loaded and then one of the specific configs (which now in most cases would just contain AUTOSTART except for the config/stilllife which would be empty).
::: '''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.


{{EmbedViewer
::: 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.
|rle = b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o!
|viewerconfig = #C [[ AUTOSTART THUMBLAUNCH GRID THEME 7 GPS 5 ZOOM 32 HEIGHT 800 TRACKLOOP 10 0 -1/10 ]]
|caption      = Colour history
}}


If we wanted to globally change the THEME colours or GRID default we just edit "config/default". For example I quite like THEME 7 since it has colour history but it's not good for LOOPing patterns (since on reset there is no history).
::: 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.


Also just a note: as it stands EmbedViewer assumes THUMBLAUNCH in the config since the embedded Viewer has the text "click above to open LifeViewer". See the Waypoint example above. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 21:32, 26 February 2018 (UTC)
::: 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)
: Hmm, so that THEME 7 LOOP issue is an argument for the ability to jump instantaneously to a waypoint at an arbitrary (X, Y, T) spacetime location, with non-zero T, and start the LOOPing from there. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 04:20, 27 February 2018 (UTC)
::Yes, perhaps a requirement for PLAYFROM and possibly LOOPTO commands. PLAYFROM would replace POIT as a non-POI specific version. LOOP or TRACKLOOP would loop back to the PLAYFROM generation. LOOPTO or TRACKLOOPTO would allow looping back to an arbitrary generation. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 07:15, 27 February 2018 (UTC)


:Replying to Chris's earlier suggestion re: [[Template:LifeViewer config/default]]: I've gone ahead and created that, and made [[Template:InfoboxStart]] use it in addition to the more specific configurations. I also edited those to remove the common config. Some ([[Template:LifeViewer config/inductioncoil|/inductioncoil]], [[Template:LifeViewer config/methuselah|/methuselah]], [[Template:LifeViewer config/pattern|/pattern]], and [[Template:LifeViewer config/stilllife|/stilllife]]) are empty now, the rest just contain the <tt>AUTOSTART</tt> command.
:::: 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)


:The order in which the various bits of LifeViewer config are assembled in [[Template:InfoboxStart]] still needs reworking, I think, but that's something that can be tackled later. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:50, 27 February 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)


::Looks good. I'd like to use [<nowiki />[Template:LifeViewer config/default]] in secondary illustrations in various articles like [[Tanner's p46]] -- or I might make a [<nowiki />[Template:LifeViewer config/defaultactive]] and add the AUTOSTART.  Not clear exactly how to invoke the template in that context. If someone does a sample The Right Way once somewhere, though, I'm a good copycat.
:::::: 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.


::Also, what template changes need to be made so that [[RLE:Snakewithfeather_synth]] shows up as a "raw RLE" link in the [[Snake with feather]] glider synthesis section of the infobox? Up at the top of this thread it says "all we'd need to do is update the pattern templates accordingly"... [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 14:49, 27 February 2018 (UTC)
:::::: (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).


:::Re: using [[Template:LifeViewer config/default]] -- that should just require an edit to [[Template:EmbedViewer]].
::::::: 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.


:::Re: "raw RLE" links for uploaded syntheses -- that'll require tweaking [[Template:PatternDownload]].
::::::: 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?


:::Neither should be difficult to do, I'll see what I can do in a moment.
::::::: 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"].


:::'''EDIT''': done on both counts. Pages using [[Template:EmbedViewer]] will need to be updated so that LifeViewer doesn't throw a wobbly over <tt>THEME 6</tt> overriding <tt>THEME 6</tt>, and all that. [[Template:PatternDownload]] seems to be working (see e.g. [[Snake with feather]]) -- knock on wood! Pages with on-wiki syntheses but no uploaded synthesis files are tracked in [[:Category:Pages with raw synthesis RLE code but no uploaded synthesis files]]. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:17, 28 February 2018 (UTC)
::::::: 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.


::::Looks good.  Can you add a newline so that, when you hit Ctrl+C in the launched LifeViewer, you get both #C comment tags at the beginning of two lines, instead of piled onto a single line?  Not that it matters a bit, as far as functionality goes.
::::::: 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).
::::It appears there are seventy EmbedViewer uses that will need to be checked and have their viewerconfigs probably reduced. I just cleaned up [[Telegraph]], and am planning to sort LifeViewer commands into some kind of standard-ish order for each use, while I'm at it.  Probably AUTOSTART then THUMBSIZE then WIDTH then HEIGHT then ZOOM, then X then Y (if needed), then GPS 20 then LOOP (if any). [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:33, 28 February 2018 (UTC)
::::-- Hang on, though.  Supposing one really wanted to use an embedded viewer with THEME 7, let's say, like the example above.  How to avoid the ugly error, exactly?  Do we need a LifeViewer with a SUPPRESS command, or a separate EmbedUnconfiguredViewer template, or what?
::::I'm finding that separating the viewerconfig from the article is significantly awkward, because to make a viewerconfig look just right I usually have to preview it many times.  But I can't preview the RLE:pname page and see any changes on the [<nowiki />[pname]] article page...
::::So what I have to do is to create the RLE:pname page later.  First I put rle= and viewerconfig= lines into the EmbedViewer curly braces, and preview and change viewer commands to my heart's content.  Then cut the rle and viewerconfig lines and paste them into a new RLE:pname page (without the rle= and viewerconfig= tags, of course), and save that.  Then preview one more time to make sure the article still looks the same, and save.
::::It's workable, but more than a little awkward, as I said. Not sure yet if it will make me reconsider the Grand Plan of moving viewerconfig lines into the RLE: namespace. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 18:11, 28 February 2018 (UTC)


:::::Yes looks like we will need SUPPRESS. I'll put it in the next build. We'll then need to update config/default to end with the SUPPRESS keyword. I'll keep you posted. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 21:38, 28 February 2018 (UTC)
::::::: 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.


::::::Seems like we would only need SUPPRESS very rarely, e.g., for the broken LifeViewer above in this section, where we want to override a setting in config/default. No need to include SUPPRESS in the default string -- it would just suppress errors that you might want to see, like a setting at the beginning of a long config string duplicated by a setting at the end of the string. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:58, 28 February 2018 (UTC)
::::::: 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)


:::::::The function of SUPPRESS would be to allow '''one''' overwriting of each setting defined in the commands '''before''' the suppress keyword. So if, for example, config/default specified [<nowiki />[ '''THEME 6 ZOOM 4''' ]] I'd want to add SUPPRESS to the end of that because it's always OK for posters to override those default values and I don't want them needing to know about SUPPRESS to do so.
:::::::: 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)
:::::::[<nowiki />[ '''THEME 6 ZOOM 4 SUPPRESS''' THEME 7 ]] would be valid.
:::::::[<nowiki />[ '''THEME 6 ZOOM 4 SUPPRESS''' THEME 7 THEME 4 ]] would throw the error "THEME 4 overwrites 7".
:::::::I wouldn't expect posters to use the SUPPRESS command themselves but there may be edge cases where that's valid and useful. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 04:56, 1 March 2018 (UTC)


::::::::SUPPRESS is implemented in LifeViewer Build 238. Test case is [http://lazyslug.no-ip.biz/lifeview/plugin/suppress.html here]. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 08:33, 1 March 2018 (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.


Excellent -- how do we get this on the wiki? I don't remember, is Nathaniel the only one who can touch the wiki's LifeViewer code, or do others have the necessary rights?
::::::::: 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.
:Not sure - I think Nathaniel has to do it. Looks like it's kept at [http://www.conwaylife.com/js/lv-plugin.js http://www.conwaylife.com/js/lv-plugin.js]. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 09:08, 1 March 2018 (UTC)


Dvgrn-- I've also added linebreaks to [[Template:EmbedViewer]] to hopefully help you with debugging, as you requested. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 08:53, 1 March 2018 (UTC)
::::::::: 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)


LifeViewer build 238 is now up here and on the forums. You'll need to refresh your browser (on Chrome CTRL-F5). Release notes are [http://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&p=57182#p57182 here]. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 05:21, 3 March 2018 (UTC)
Resetting indent back to zero, but still talking about kind of the same thing:


== Stability of Pentadecathlon IDs ==
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."


Maybe I should be asking Heinrich Koenig about this instead of posting here, but here goes-- does anyone know whether Pentadecathlon's ID numbers are actually stable?
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.


The reason I'm asking is that when adding missing info to some patterns, I come across three patterns (out of about three dozen) whose numbers on PD differed from ours. Our 44P12.2 is now [[44P12.3]]; our 42P10.1 is now [[42P10.3]]; and our [[44P7.2]] is now 44P7.3.
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 somewhere for reporting the actual latest synthesis for each object would certainly be a step up from the current perpetually out-of-date synthesis files.


I moved the first two to match their new PD IDs, but not the third. After all, once is happenstance, twice is coincidence, but three times is enemy action; I figured I'd better make sure these ID numbers are stable/reliable to begin with. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 12:38, 25 February 2018 (UTC)
-- 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)


== [[:Category:Toplevel category]] ==
: The problem of deciding what to do about glider syntheses is still where it was in January. I'm still leaning toward leaving things pretty much as they are until Mark Niemiec's new synthesis database becomes available, and then figuring out how to link directly to the relevant Niemiec synthesis page, for any object that has a LifeWiki article -- and removing those _synth files from the Patterns folder.  Most of the Niemiec-derived _synth files that have been uploaded will probably be subtly out of date when the new version comes out. Anyone have any better ideas?


Following some discussion at [[Talk:AUTOSTART]], I've moved a few categories from [[:Category:Toplevel category]] to [[:Category:Everything else]] -- several were already in both --, to make the decision of what's in the latter and what's in the former a little less arbitrary.
: In other news, [[User:Dvgrn/Plaintext_files]] documents the 695 new plaintext-format .cells files that are available on the server now. This means that a lot of articles' infoboxes could now be updated to say '''|plaintext        = true''' along with '''|rle              = true'''. If nobody wants to tackle making these several hundred edits manually, I might eventually look into setting up some kind of automated search-and-replace functionality, based on this kind of article list. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 22:45, 17 February 2019 (UTC)


In fact, it should be pretty much entirely ''non''-arbitrary now. [[:Category:Everything else]] states that it "''contains all pages that are not about specific patterns''", so I moved all content categories collecting CA content (CCCCC?) to that category -- except for [[:Category:Pattern categories]], of course.
:: I noticed once again that there are quite a few patterns with capitalization in their names, most of which ([http://www.conwaylife.com/w/index.php?title=RLE:P52G3to4&action=history with a few exceptions]) were created by [[User:Entity Valkyrie]]. Even [[RLE:ModelD]] is still in that list despite having been deleted and moved over a week ago, so those should probably be fixed. Something more confusing, though, is that certain small patterns (such as [[44P14]] and [[44P12.3]]) were labeled as being too large despite easily fitting within the 64&times;100 limit. What's up with that?


What's left in [[:Category:Toplevel category]] now is the following:
:: As for adding these to the infoboxes, I'll probably get to that eventually but I'm a bit too busy at the moment. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:14, 17 February 2019 (UTC)


* [[:Category:Administrative categories]] -- self-explanatory, I hope; a 2nd-level root category for everything relating to the inner workings of the LifeWiki (the plumbing, as it were, as opposed to the porcelain).
::: Many thanks for the review.  I believe I've patched all the remaining instances of pnames with capital letters: 68p16.cells/.rle, 76p8.cells/.rle, 113p18.cells/.rle, 209p8.cells/.rle, p130shuttle2.cells/.rle, l156reactions.rle, p24lwss.rle, and p52g3to4.rle. Obviously in the future the auto-upload script should check for capital letters and complain.
* [[:Category:Everything else]] -- CA-related content that isn't patterns.
* [[:Category:Images]] -- self-explanatory.
* [[:Category:Pattern categories]] -- self-explanatory.
* [[:Category:Tutorials]] -- self-explanatory.


I left [[:Category:Tutorials]] in [[:Category:Toplevel category]] on account of its contents not ''describing'' CA-related subject matter, as such; I feel it should be treated the same as (say) [[:Category:Images]], which clearly also belongs [[:Category:Toplevel category]]. (FWIW, I think Tutorials could actually well get their own namespace, but that's a different discussion.)
::: I haven't yet looked into why a few small patterns didn't get .cells files created properly. Will figure it out and fix that bug along with adding the capitalization check. That one isn't too worrisome -- anything that got missed in the first round we should be able to pick up on the next auto-upload. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 19:54, 18 February 2019 (UTC)


Long story short, I think [[:Category:Toplevel category]] is much less cluttered now, and the placement of content categories is much less arbitrary. All we still need to do now is keep it that way. ;) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 15:56, 4 March 2018 (UTC)
== The list(s) of rules investigated on Catagolue ==


== Image generation and upload ==
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.)


I looked at [[Help:Images]] this morning, and I think it might make sense to do a complete rewrite.  Rather than suggesting Golly and Print Screen as a source of screenshots, we should probably create a special page in some namespace or other, that has one or more NOGUI LifeViewers in it, and link to that from Help:Images.
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)


(This is based on [http://www.conwaylife.com/wiki/LifeWiki:Tiki_bar/Archive/2017#LifeViewer_image_display_and_pattern_copy_functionality last year's discussion about using LifeViewer to capture images].)
: If we are to retire the [[List of rules investigated on Catagolue]], how should we do this? Add a notice at the top saying:


The text of this hypothetical image-gathering page might suggest editing the page, replacing the sample RLE with the desired pattern, and hitting Preview (actually saving the changes won't be necessary). The page can include a list of the relevant LifeViewer scripting commands -- no waypoint stuff, but X Y ZOOM HEIGHT WIDTH, and how to hit 'I' to read that information after manually setting the view up exactly right.
: "This page is no longer actively maintained in favour of the [https://catagolue.appspot.com/rules equivalent Catagolue page]."


When the image looks right, probably after multiple previews, a user can right-click and save it, then upload it to the relevant article.
: or words to that effect?
{{LV:Viewer|bo$2bo$3o!
#C [[ NOGUI THEME 6 GRID GRIDMAJOR 0 WIDTH 128 HEIGHT 128 ZOOM 12 ]]}}
... This is certainly somewhat simpler than fiddling with Golly settings to get the colors right, and for most small patterns it allows a wider range of sizes than Golly's simple powers-of-two system can provide.


Still seems like it could be easier, though!  In particular, if you have the NOGUI command set, of course you can't adjust the view, and the 'i' information doesn't pop up. So you have to remove NOGUI and then add it back when you want the screenshot.
: 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)


Any suggestions for how to capture an image without having to figure out the scripting commands or go through multiple Preview cycles to get everything right?  Obviously plain Print Screen on the first Preview page is an option, as Help/Images currently suggests, but then it becomes necessary to edit the image in some Paint-type program.
:: 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)


Do all modern OSes have something equivalent to Windows' Snipping Tool, and we could mention those as a way to grab the image directly?
== Time for a consensus decision on pnames? ==


... Yes, in many cases we can now just use a NOGUI LifeViewer, and never upload an image at all. So we should say that clearly in [[Help:Images]]. But it's still good to have the option to upload images, for cases like the green-annotation image in [[Blockstacker]].  And it seems like a nice idea to have a static image available as backup, anyway, so let's not get rid of the "View static image" links yet!
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 other awkwardnessfulmost detail is when you want to generate an image in a different-shaped rectangle than what the LifeViewer provides by default.  You pretty much have to figure out the scripting system enough to add WIDTH and HEIGHT tags -- and if you've removed the NOGUI tag, as you kind of have to to do any experimenting, in many cases you'll fall foul of the mysterious minimum and maximum values allowed for LifeViewers with GUI controls.
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>


I'm also fishing for options that might allow for dodging the two-step save-file/upload-file.  Is there any way for this hypothetical image-gathering page to pop up immediately when someone clicks on an image redlink -- with a text box to paste RLE into, a LifeViewer frame that's resizable by clicking and dragging, and some button or link on that page that magically collects the current image from LifeViewer when the user says it's ready to be collected?
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:


-- I think that would be just about the minimal, easiest to use design.  What's the closest setup to that, that's actually practical to implement?
# '''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.


TL;DR:  Sorry about the long essay.  What exactly should the Help tell people about how to make standard LifeWiki images? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 15:03, 5 March 2018 (UTC)
* [[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.


:Good points all around -- perhaps the best solution would be to have an online RLE-to-image converter where people could simply paste an RLE snippet (or point to a remote RLE file to be fetched), and which would then spit out a bespoke image, suitable for immediate uploading to the LifeWiki (or further editing as desired). Something vaguely along the lines of Oscillizer is what I'm imagining there.
* 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.


:For extra brownie points, it could also offer a few form controls to tweak common options, such as live cell/dead cell/grid color, cell size, and so on; all with sensible defaults, of course.
====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.


:Speaking of which, what should those defaults be? Cell size in particular -- right now quite a few still images (those I made anyway) are smaller than the animated ones, my thought at the time having been that they needed to fit into infoboxes without blowing those up too much. Now that we've entered the age of embedded LifeViewers, this isn't (that much of) a concern anymore.
====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.


:I'm thinking 15x15 pixels for a single cell, plus 1 pixel for the border. Color-wise, we seem to have settled on [http://www.perbang.dk/rgb/C0C0C0/ (192, 192, 192)] (#C0C0C0) as our border color of choice. We've also used [http://www.perbang.dk/rgb/C0EFC0/ (192, 239, 192)] (#C0EFC0) as a light green color for highlighting cells, and [http://www.perbang.dk/rgb/52C052/ (82, 192, 82)] (#52C052) as a dark green, for the border of those highlighted cells:
-- 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.)


[[File:Neighborhood 1c.png|center]]
====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.


:Getting back to how to create images... I don't know what support the various OSes do offer. I do, however, think that a two-step process, where you save an image locally and then upload it in a second step, isn't that bad, so long as generating the image in the first place is easy, straightforward, fast, and convenient. (Ideally, all four!)
Comments, suggestions, disagreements? Please post 'em here! [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 17:56, 15 January 2019 (UTC)


:Oh, and experimenting with LifeViewer, its config commands, and the limits it imposes? Oh yes, I know ''exactly'' what you're talking about there! WIDTH and HEIGHT will surely be the death of me some day. :) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 22:00, 5 March 2018 (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.


:'''EDIT''': oh, and BTW -- perhaps in addition to a default size for images, we should define standard small(er) sizes as well? For instance, I'm imagining that <tt>Cathysuesamazingpattern.png</tt> might use 15x15 cells, whereas <tt>Cathysuesamazingpattern_small.png</tt> might use 7x7, and <tt>Cathysuesamazingpattern_tiny.png</tt> might use 3x3, all with a 1 pixel border. Or something along those lines, anyway.
: 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 would make it easier to select the right image on-wiki when a specific size is needed, and it would also mean that we could keep all the current images using smaller (e.g. 7x7) cells; we'd just have to rename them. [[Template:InfoboxStart]] could easily be tweaked to display links to all sizes that exist, or only to the largest size that exists, or whatever else we might find best. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 22:04, 5 March 2018 (UTC)
: 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


::Just because both of you mentioned it here are the mysterious LifeViewer width and height rules:
: A couple other tasks are admin-only --
::1. Common rules:
# If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
:::1.1 Width is always (silently) rounded down to a multiple of 8 pixels.
# 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.)
::::Why? Because it makes drawing faster.
# 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.
:::1.2 Maximum width is 1024 pixels.
::::Why? Arbitrary decision. Could be any multiple of 8. Pick one.
:::1.3 Maximum height is 800 pixels.
::::Why? Arbitrary.


::2. With GUI rules:
: 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).
:::2.1 Minimum width is 480 pixels.
::::Why? Any smaller and the GUI wouldn't fit horizontally.
:::2.2 Minimum height is 480 pixels or 240 pixels.
::::Why? 480 for the full GUI to fit vertically. 240 if you don't mind losing the navigation controls.


::3. NOGUI rules (for image display):
: 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)
:::3.1 Minimum width is 64 pixels.
::::Why? No GUI to draw. Arbitrary.
:::3.2 Minimum height is 64 pixels.
::::Why? Seemed like a good idea to make it the same as the minimum width.


::4. meta tag
==Special pages broken?==
:::4.1 Some LifeViewer settings can be set by putting a <meta name="LifeViewer" content=""> tag in the <head> section of the HTML page.
I have noticed several oddities in a few of the maintenance pages:
:::4.2 If the meta tag doesn't exist, or exists but has the word "limit" in the content="" string then the maximum width is constrained to the width of the element containing the pattern source (typically a textarea or similar containing RLE).
* [[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.
:::4.3 For the conwaylife.com forum the meta tag doesn't exist so all Viewers are limited to the width of the HTML element containing their RLE.
* [[RLE:Loafer]] is listed in various places (such as [[Special:ShortPages|Short pages]]) despite being in the wrong namespace.
::::Why? It stops Viewers escaping out of the central column.
* [[ConwayLife.com:About]] is listed as in [[Special:DoubleRedirects|Double redirects]] despite not having any redirects.
:::4.4 For the Wiki the tag does exist, but doesn't contain "limit", so the maximum width is not constrained by the HTML element containing their RLE.
* [[Special:FewestRevisions|Pages with the fewest revisions]] isn't even close to being correct.
::::Why? Because on the WIKI the RLE is typically not displayed.
* [[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.


::5. Errors
Anyone know what's up with these? [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 23:35, 15 January 2019 (UTC)
:::5.1 If WIDTH or HEIGHT are specified outside of the ranges defined above then the window is sized to be at least the minimum width and height.
::::Why? So you can see the script error message.


::6. Defaults
==Rulespace info for eaters, reflectors, conduits, etc.==
::::6.1 The default width and height for an embedded Viewer are the size of its HTML canvas element. Silently, the minimum width and height are enforced and the width is rounded down to multiple of 8. Currently, no maximum width and height are enforced - I suspect I forgot.
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)
::::6.2 The width and height of the popup Viewer are fixed to be 560 x 480.
:::::Why? The top and bottom row of GUI controls are 40 pixels each so the display area is 480x480 square.


::Hopefully the rules are less mysterious now. Feel free to suggest better Arbitrary values or any other improvements. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 01:03, 6 March 2018 (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.)


:::Thanks for the explanations! We don't have a [[Help:LifeViewer]] page yet -- making one is one of the many items on my to-do list --, but perhaps we could start one now, and seed it with this information.
: 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)


:::While I'm at it, one question: when using THUMBLAUNCH, is it possible to independently set the width and height of the thumbnail, and the full viewer you get when clicking it? Getting the best possible viewer size/shape in pattern infoboxes can be fiddly, and I've found that playing carelessly with WIDTH/HEIGHT can make the full viewer look funny. Is there such a thing as THUMBWIDTH and THUMBHEIGHT? (If not, I think there really should be!)
==[[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)


:::Thanks for all your work on LifeViewer BTW, it really is an excellent piece of software to have, and makes Life (if not life) so much easier and more accessible to newcomers. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 10:20, 6 March 2018 (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)


::::There are actually two thumbnail commands: one for embedded Viewers: THUMBNAIL, and one for popup Viewers: THUMBLAUNCH. In both cases they render the Viewer at 1/2, 1/3 or 1/4 of its width and height depending on the value of "THUMBSIZE <2..4>". The default is 1/4 size ("THUMBSIZE 4").
== Help Wanted with templates and general review ==
:::::The THUMBNAIL command will resize the Viewer in place when clicked. If you hover the mouse over the Viewer it will say "Expand". The Viewer can be returned to the thumbnail state with hotkey "n" or by clicking the shrink button (top left in the navigation menu assuming the height is at least 480).
{{LV:Viewer|bo$2bo$3o!
#C [[ THEME 6 GRID GRIDMAJOR 0 WIDTH 640 HEIGHT 480 THUMBNAIL ]]}}
:::::THUMBLAUNCH will launch the popup window. If you hover the mouse over the Viewer it will say "Launch". The popup Viewer size is fixed at 560x480 and ignores WIDTH and HEIGHT settings.
{{LV:Viewer|bo$2bo$3o!
#C [[ THEME 6 GRID GRIDMAJOR 0 WIDTH 640 HEIGHT 480 THUMBLAUNCH ]]}}
:::::So I believe that means you are free to use WIDTH and HEIGHT and THUMBSIZE to define the size of the thumbnail for THUMBLAUNCH, knowing that when clicked the popup Viewer will always be 560x480.


::::If you create a [[Help:LifeViewer]] page it's fairly likely I'll update it over time. There's already some documentation on the forum in the [http://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=0 Pattern Viewer for forum threads] thread. For example [http://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=0#p17014 this post] describes how to use LifeViewer in your own web page including details on the meta tag discussed earlier. There's also [http://golly.sourceforge.net/Help/lifeviewer.html documentation in Golly] for the Lua version of LifeViewer which is a subset of the HTML version functionality but still valid.  [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 10:59, 6 March 2018 (UTC)
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:


:::::I like defaulting to the pop-up LifeViewer for wiki purposes, mostly because it doesn't force an ugly re-flow of the text around a thumbnail image, and it's guaranteed to appear always in the same place and entirely on the screen (unless you're looking at a very small screen). The inline viewer that shrinks and expands is often more annoying to use in wiki articles, because either
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.
:::::# the Play/Pause controls at the bottom expand to offscreen and you have to scroll to get to them;
:::::# the Play/Pause controls are visible, but the very top of the viewer is offscreen, in which case the first click on the viewer moves the Web page so that the whole viewer is visible, but doesn't actually activate the control you clicked on.  And now whatever you clicked is suddenly not under your mouse any more, so you have to go find it and click again.


:::::The popup viewer is a bit taller than it is wide, so 480x560This does cause some trouble on very small laptop/tablet/phone screens when the window is 480 pixels high -- you have to scroll to make the controls usableI wonder if it would make sense to reduce the popup window to a square 480x480?
2. As of this morning, Nathaniel has officially removed the Life 1.05 and Life 1.06 patterns from the LifeWiki patterns directoryThat means the infobox template probably ought to be adjusted to stop showing those linksWe 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.


:::::Along the lines of Apple Bottom's THUMBWIDTH and THUMBHEIGHT comment above, I've sometimes wanted to set the popup viewer to landscape format, so to speak. E.g., when opening the secondary illustration in [[Telegraph]], you don't really need the extra height, but more width would be okay. I guess this would really be POPUPWIDTH and POPUPHEIGHT, since the thumbnail size is specified by regular WIDTH and HEIGHT.
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.


::::: I '''would''' like to bump up the maximum height and width, to be able to use LifeViewer in more or less full-screen mode. 2048x1600?  Or is there any downside to just saying something like 4096x4096, with the understanding that if that causes memory issues then that's the problem of whoever set the size that big? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:35, 6 March 2018 (UTC)
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.


::::::I like the idea of POPUPWIDTH and POPUPHEIGHT. That would also solve the popup height (560 pixels) since you could put POPUPHEIGHT 480 in config/default if you wanted it to be a site wide standard.
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)
::::::I'll increase the maximum width and height to 2048. Though I'll probably cap it at the actual screen size or we'd be in Viewer half off screen purgatory.
::::::The issue with clicking on a Viewer that's half off the screen is thorny. I remember taking a brief look at it a year or so ago when you last mentioned it. I'll take another brief look. Perhaps two brief looks is enough for inspiration to strike. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 18:15, 6 March 2018 (UTC)


:::::::The second brief look was fruitful. See if you like the behaviour in [http://lazyslug.no-ip.biz/lifeview/plugin/extendedcommands.html build 241]. Click on a Viewer that's not fully scrolled onto the window. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 20:54, 6 March 2018 (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).


I've added POPUPWIDTH and POPUPHEIGHT in Build 242. Test cases are [http://lazyslug.no-ip.biz/lifeview/plugin/popup.html here]. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 21:39, 8 March 2018 (UTC)
: 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.


:Wonderful, thanks. :) (I'll still need a tutorial at some point so I'll understand how to give the LifeViewer the right size, e.g. in infoboxes...)
: 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.


:Other things I noticed earlier today: there's some arbitary (?) limits left. "ZOOM 64" produces an error, as does "WIDTH 400". And "GRID" cannot be overridden, AFAICT; there's no "NOGRID". [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 12:14, 10 March 2018 (UTC)
: 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)


::For InfoBox I think you just need to set WIDTH and HEIGHT to 4x the size you want (since it uses THUMBLAUNCH which will divide the defined size by 4 by default, or by 2 or 3 if you specify THUMBSIZE 2 or THUMBSIZE 3).
:: @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)


::ZOOM is limited from 1/16x to 32x
: I've just added THUMBSIZE 2 as a [[Template:LifeViewer config/default|default option for the viewers]] to save myself some trouble. As for item #3 in your list, the solution probably in [[Template:InfoboxStart]] though I'd rather leave that to someone more experienced with templates. [[User:Ian07|Ian07]] ([[User talk:Ian07|talk]]) 22:12, 13 February 2019 (UTC)
::WIDTH and HEIGHT are limited as described in detail above (see the mysterious LifeViewer width and height rules)
::Correct, GRID can not currently be overridden. There are a number of commands like that (for example AUTOSTART). They were defined that way since the LifeViewer default is OFF, so all I needed was something to switch various modes ON. On the Wiki we now have config/default which defines GRID (ON) so I'll have to add GRID OFF to compensate. I already added STOP OFF and LOOP OFF in a previous build. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 14:24, 10 March 2018 (UTC)
:::AUTOSTART OFF and GRID OFF are in Build 243. [[User:Rowett|Chris Rowett]] ([[User talk:Rowett|talk]]) 14:43, 10 March 2018 (UTC)


::::Wonderful, thanks. I love how quickly you always implement new things! Now we'll just have to wait for this build to be available on the wiki. (Or does the wiki automatically use the latest these days?) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 19:41, 10 March 2018 (UTC)
== Replacing images with animated viewers ==


:::::No, that's still something that someone has to get Nathaniel's attention for. That usually doesn't take too long.  But now I think we're waiting for a few more minor alterations and a Build 244.
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.
:::::Meanwhile, the addition of a waypoint script in the [[2-engine Cordership]] article has exposed a flaw in the idea of including viewerconfig lines at the bottom of the pattern text in the RLE: namespace. As things are now set up, the default config line '''#C [[ THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]]''' is intended to show up before any overriding commands in the '''RLE:pname''' text.  But as you can see if you launch a viewer on the slow-salvo pattern and hit Ctrl+C, the default config is currently being appended to the end of the RLE text.
:::::The obvious way around this is to put the default config first, so it shows up as an initial comment line. But that's kind of non-traditional, not to say ugly, since it puts the LifeViewer command lines in two widely-separated places.
:::::I had to make multiple edits to the viewerconfig to get things looking okay, mostly because there's no reasonable way to preview before saving changes. I'm pretty close to being persuaded that it's just plain not that good an idea to include viewerconfig lines in the RLE: namespace.  It's much easier to fix and test viewer behavior if the commands are in a viewerconfig= line in the article itself. Thoughts? [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 21:55, 11 March 2018 (UTC)


::::::Without having taken a close look -- I'm not sure I see the problem with ugliness you're mentioning. The RLE snippet from the RLE: namespace is a "black box" as far as assembling the RLE (including all the various viewerconfig lines) passed to LifeViewer is concerned, isn't it? Where ''inside'' that black box the snippet-internal viewerconfig line is found shouldn't matter -- right?
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.


::::::But you're the LifeViewer wizard, not me, and I'll defer to your superior experience. :) If you think keeping viewerconfig lines out of RLE: snippets, I'm fine with that. If you think we can make including them there work, that's fine with me as well. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:51, 12 March 2018 (UTC)
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)


:::::::Yeah, true, it doesn't matter a whole huge amountI've gotten in the habit of putting viewerconfig lines after the RLE, away from the other comments and all together in a consecutive series of lines.  But they can equally go in as the first lines in the RLE: snippets, and then the default config could be dropped in ahead of everything and it would all end up reasonably readable.
: 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 anythingComments in block.rle are safe, and the addition of [[RLE:114p6h1v0pushalong]] won't damage the existing uploaded file on the server.


:::::::The main reason to put '''viewerconfig=''' back into the article text is that it makes it significantly easier to explain in the Help how to use LifeViewer.  Put in '''viewerconfig=something''', hit Preview, keep previewing until it looks right, and then save.
: Now, if we deleted 114p6h1v0pushalong.rle from the server, and added these two comment lines at the top of [[RLE:114p6h1v0pushalong]] --


:::::::Otherwise, especially if you want to adjust a viewer that already has viewerconfig in its RLE:pname page, it's a big pain to test changes -- either save the RLE:pname page multiple times and refresh the article page each time until you get it right (this can take dozens of test cycles for a good animation)... or take out the viewerconfig lines temporarily, put them back in the article under viewerconfig=, preview there, and then finally copy the successful viewerconfig back into the RLE:pname page and save again.
<pre>#O Hartmut Holzwart
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.</pre>


:::::::Those methods aren't all that difficult really, but they seem like an unnecessary barrier to successful editing, for people who might want to learn how to use LifeViewer.
: - 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.


:::::::If it's easy to adjust the template to put the default config first, before the RLE:pname content, then maybe I should try playing around with that for a while before deciding to banish viewer config back to the infobox (or EmbedViewer) section againBut really it seems pretty clear that the advantages of keeping the viewer config with the article outweigh any disadvantagesBonus:  we'll be back to not needing multiple copies of the same RLE to use it multiple different ways, or in different articles. [[User:Dvgrn|Dvgrn]] ([[User talk:Dvgrn|talk]]) 16:50, 12 March 2018 (UTC)
: 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, etcThat's probably a tradition that I'll continue, so that's another line of defense against accidental damageWith 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.


== Permission to edit high-risk pages ==
: 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)
[[Talk:Main Page]] has apparently been protected from recreation due to too much spam in 2010, and the main page itself, as well as [[LifeWiki talk:Did you know/35‎]] are protected as well, conceivably for the same reason. But since editing has been generally restricted in 2016 to "trusted" users only, this appears not necessary anymore. Could those pages now be allowed to trusted users, please? [[User:Micromegas|Micromegas]] ([[User talk:Micromegas|talk]]) 00:51, 11 March 2018 (UTC)


:Strange, but [[Talk:Main Page]] doesn't show up on [[Special:ProtectedPages]]. I'd have unprotected previously otherwise, there really is no reason for it to be protected, especially in this day and age of "trusted" flags. If you come across any other such pages, let me know.
:: One more detail that isn't clear from the above:


:[[LifeWiki talk:Did you know/35]] is not protected, but [[LifeWiki:Did you know/35]] is, by virtue of cascading protection: any pages transcluded on the [[Main Page]] (which is protected with cascading protection enabled) are automatically protected as well. This is by design so that protected pages cannot be edited "through the back door", as it were.
:: The auto-upload script will automatically generate a slightly nonstandard #O line including both the discoverer and the discoveryear from the infobox -- like


:I'm not going to unprotect the [[Main Page]] itself; even in the absence of spammers and with only good-faith editors around, there's several I don't trust to exercise the necessary care. But editing the [[Main Page]] or its transclusions should be a rare event in any case, and you can always ask a sysop to do the necessary edit. [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 09:51, 11 March 2018 (UTC)
<pre>#O Paul Tooke, 2008</pre>


== Image update ==
:: 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.
Can someone update [[:File:Spaceship ford circles.png]] to include c/10, 3c/7 and 31c/240? It may also be worth colouring in all circles below c/4 a dark yellow, signifying their existence as trivial caterloopillar constructions.


In addition, could diagonal and knightship variants of said image be created? - [[User:AwesoMan3000|AwesoMan3000]] ([[User talk:AwesoMan3000|talk]]) 16:57, 12 March 2018 (UTC)
:: 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.


== Redirects ==
:: 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)
Apologies if I am asking this question in the wrong place, but how do I create redirects? I recently got into LifeWiki and there doesn't seem to be any formatting tutorial... [[User:Cognaso|Cognaso]] ([[User talk:Cognaso|talk]]) 01:12, 16 April 2018 (UTC)


:Like this:
::: 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.


::<tt><nowiki>#REDIRECT [[Target article]]</nowiki></tt>
::: 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. (?)


:Yeah, our help/project pages are not as complete and all-encompassing as they should ideally be. So in general you may want to look at the documentation [https://meta.wikimedia.org/wiki/Help:Editor on meta.wikimedia.org], or [https://en.wikipedia.org/wiki/Help:Wikitext on the English-language Wikipedia]. The latter also has a [https://en.wikipedia.org/wiki/Help:Cheatsheet handy cheatsheet] for common formatting. Some of it may be project-specific of course, e.g. certain templates, or syntax relying on extensions we don't have installed on the LifeWiki. (I don't think you'll be able to enter hieroglyphs here, say, not that I've tried.) [[User:Apple Bottom|Apple Bottom]] ([[User talk:Apple Bottom|talk]]) 08:45, 16 April 2018 (UTC)
::: 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


== Conduits and converters ==
<pre>#C http://www.conwaylife.com/wiki/index.php?title=233P3H1V0</pre>


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...".
::: There's a shorter form that works just as well:


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."
<pre>http://www.conwaylife.com/wiki/233P3H1V0</pre>


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.
::: 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 scriptIf 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.


[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.]
::: 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)


... And we can probably get rid of [[Template:Reflector/Doc]] while we're at it, no?
::: 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)


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)
:::: 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)


: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)
::::: 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)

Revision as of 19:54, 18 February 2019

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.

Conduits and converters

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...".

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."

It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to go. When 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 conduits.

[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.]

... And we can probably get rid of Template:Reflector/Doc while we're at it, no?

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. Dvgrn (talk) 15:26, 8 May 2018 (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.
~Sokwe 07:08, 9 May 2018 (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? Apple Bottom (talk) 05:25, 7 June 2018 (UTC)
It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to go. There 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. Dvgrn (talk) 14:48, 7 June 2018 (UTC)
Definitely agree! Unfortunately writing documentation is one of things I'm hopelessly.. well, hopeless at. ;) Apple Bottom (talk) 10:33, 9 June 2018 (UTC)

Lexicon tags

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.

Some of that has been handled in an ad-hoc manner 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.

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.)

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.

The Nethack wiki does something similar; for instance, take a look at their 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 this template.

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.

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.

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.

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.

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.

Thoughts? Apple Bottom (talk) 07:49, 18 July 2018 (UTC)

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.
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.
That's a lot of small changes to a lot of articles with every Lexicon release, though. Does it make sense to have the default Lexicon tag be just Template:LexiconLatest or some such, with a template to display on the page whatever the latest Lexicon release number actually is?
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 Template:LexiconLatest? Dvgrn (talk) 22:15, 18 July 2018 (UTC)
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.
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.
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.
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?
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.
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.
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.
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.
Apple Bottom (talk) 07:50, 19 July 2018 (UTC)
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 more. We 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.
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? Dvgrn (talk) 18:49, 19 July 2018 (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.
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.
Our options there would include at least the following:
  1. 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.
  2. 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.
  3. 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.
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.
(And by "we", I mean whoever's willing to do that job.)
Apple Bottom (talk) 18:16, 20 July 2018 (UTC)
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.)
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.
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.
Sound reasonable? And could you have a look at Template:NeedsLexiconUpdate and see if it has everything in it that this plan might need? Dvgrn (talk) 21:02, 20 July 2018 (UTC)
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... Dvgrn (talk) 21:57, 26 July 2018 (UTC)
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.
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.
Apple Bottom (talk) 08:31, 28 July 2018 (UTC)

Object frequency classes

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).

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 2X times more common. X need not be an integer; to strike a balance I'd suggest using one decimal digit.

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 ≈ 218.17517 times more common, and the twin hat's frequency class is 18.2, rounded to one decimal digit.

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.

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.

...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. :) Apple Bottom (talk) 17:56, 1 September 2018 (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.)

Replying to myself, I've started doing this; there is a new template parameter, fc=, 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 ≤ 10.0. The script used to generate the necessary data from Catagolue's textcensus is this:
#!/usr/bin/perl

# usage eg.:
# perl ../frequencyclasses.pl b3s23.C1.txt >frequencyclasses.txt

use Modern::Perl '2016';

# only patterns with more than $cutoff occurrences should be considered.
# mark all other patterns with an asterisk.
our $cutoff = 10;

# throw away header line
<>;

my %objects = ();
my $mostcommon = -1;
my $mostcommoncode = "";
while(<>) {
    chomp;
    next unless m/^"([^"]*)","(\d+)"$/;

    my ($apgcode, $count) = ($1, $2);
    $objects{$apgcode} = $count;

    if($count > $mostcommon) {
        $mostcommon = $count;
        $mostcommoncode = $apgcode;
    }
}

my %frequencies = ();
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) {
    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}";
    }
}
(I'm sure there's better ways of doing this, but this worked for me.) Apple Bottom (talk) 18:52, 1 September 2018 (UTC)
Another reply to myself --- Goldtiger997 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?
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 fc= as "frequency in [c]atagolue". Apple Bottom (talk) 09:08, 2 September 2018 (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 fc parameter for those two articles, or should they just be left as they are? Goldtiger997 (talk) 09:26, 2 September 2018 (UTC)
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 >10 to the script above; patterns not reaching that cutoff are marked with an asterisk. Apple Bottom (talk) 09:35, 2 September 2018 (UTC)

Infobox vs. EmbedViewer

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 forth. The 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. Dvgrn (talk) 09:45, 12 September 2018 (UTC)

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. Apple Bottom (talk) 07:54, 13 September 2018 (UTC)
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... Dvgrn (talk) 11:20, 13 September 2018 (UTC)

Semi-automated collection of raw RLE

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.

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!

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.

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.

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. Dvgrn (talk) 14:21, 23 October 2018 (UTC)

Link! 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. 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 unknown mod list later and add in all the mods if no one objects to it. 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! 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. 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 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. Apple Bottom (talk) 21:27, 3 November 2018 (UTC)

Similarly, 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. 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? 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:

{{#ifeq:{{NAMESPACE}}|User||[[category:patterns]]}}

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?
~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. 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 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:

  1. 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).
  2. 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.
  3. 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?
  4. 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 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? Dvgrn (talk) 17:23, 21 December 2018 (UTC)

Also, AwesoMan3000 put the following in checkin comments for beacon on dock:
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
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. 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, … 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
  1. New names are valued in principle;
  2. But the person proposing them can't be the one naming the object on the Wiki;
  3. 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
  1. Whoever changes a pname is responsible for cleaning up the resulting mess; and
  2. pname changes shouldn't be mandatory without a good reason.
What is a "good reason"? A typo, say --- "pname = 2enginecrodership" would obviously require correction. OTOH, if Beluchenko's p51 has "pname = 112p51", 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.) 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 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". 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 pretty outdated version of it. 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. 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™ 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 "0/6hv.rle", and the path to a beehive on cap synthesis is "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 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? 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. 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. 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 somewhere 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. Dvgrn (talk) 22:25, 24 January 2019 (UTC)

The problem of deciding what to do about glider syntheses is still where it was in January. I'm still leaning toward leaving things pretty much as they are until Mark Niemiec's new synthesis database becomes available, and then figuring out how to link directly to the relevant Niemiec synthesis page, for any object that has a LifeWiki article -- and removing those _synth files from the Patterns folder. Most of the Niemiec-derived _synth files that have been uploaded will probably be subtly out of date when the new version comes out. Anyone have any better ideas?
In other news, User:Dvgrn/Plaintext_files documents the 695 new plaintext-format .cells files that are available on the server now. This means that a lot of articles' infoboxes could now be updated to say |plaintext = true along with |rle = true. If nobody wants to tackle making these several hundred edits manually, I might eventually look into setting up some kind of automated search-and-replace functionality, based on this kind of article list. Dvgrn (talk) 22:45, 17 February 2019 (UTC)
I noticed once again that there are quite a few patterns with capitalization in their names, most of which (with a few exceptions) were created by User:Entity Valkyrie. Even RLE:ModelD is still in that list despite having been deleted and moved over a week ago, so those should probably be fixed. Something more confusing, though, is that certain small patterns (such as 44P14 and 44P12.3) were labeled as being too large despite easily fitting within the 64×100 limit. What's up with that?
As for adding these to the infoboxes, I'll probably get to that eventually but I'm a bit too busy at the moment. Ian07 (talk) 23:14, 17 February 2019 (UTC)
Many thanks for the review. I believe I've patched all the remaining instances of pnames with capital letters: 68p16.cells/.rle, 76p8.cells/.rle, 113p18.cells/.rle, 209p8.cells/.rle, p130shuttle2.cells/.rle, l156reactions.rle, p24lwss.rle, and p52g3to4.rle. Obviously in the future the auto-upload script should check for capital letters and complain.
I haven't yet looked into why a few small patterns didn't get .cells files created properly. Will figure it out and fix that bug along with adding the capitalization check. That one isn't too worrisome -- anything that got missed in the first round we should be able to pick up on the next auto-upload. Dvgrn (talk) 19:54, 18 February 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 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! 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 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. 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). 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 guidelines for creating pnames say very clearly:

pname	(required) The name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed.

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:

  1. 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.
  2. 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 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! 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:
  1. decide whether the pname should change to match the article name
  2. new synthesis copied from Talk:{name} to RLE:{pname}_synth, either updating or replacing any RLE that's currently there
  3. fix "synthesis = {n}" in infobox
  4. add to infobox:
    viewerconfig     = [[ THUMBSIZE 2 ]]
  5. remove Life1.05 and Life1.06 lines (optional)
  6. double-check that article name matches article text and Catagolue link -- there's often something wrong there
  7. 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 --
  1. If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
  2. 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.)
  3. 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. Dvgrn (talk) 12:33, 21 January 2019 (UTC)

Special pages broken?

I have noticed several oddities in a few of the maintenance pages:

Anyone know what's up with these? 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. 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. 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. 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. 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 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 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 Nathaniel's recent advice. 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? 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. Dvgrn (talk) 20:49, 28 January 2019 (UTC)
I've just added THUMBSIZE 2 as a default option for the viewers to save myself some trouble. As for item #3 in your list, the solution probably in Template:InfoboxStart though I'd rather leave that to someone more experienced with templates. Ian07 (talk) 22:12, 13 February 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 pushalongs 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 block.rle 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 114p6h1v0pushalong.rle 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. 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 --
#O Hartmut Holzwart
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.
- 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! 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
#O Paul Tooke, 2008
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. 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
#C http://www.conwaylife.com/wiki/index.php?title=233P3H1V0
There's a shorter form that works just as well:
http://www.conwaylife.com/wiki/233P3H1V0
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? 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. 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? 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. Dvgrn (talk) 01:33, 4 February 2019 (UTC)