LifeWiki:Tiki bar

Taka Tiki Break

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

Click here to start a new Tiki bar discussion.

Welcome to the Tiki bar

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

Archived discussions

• See LifeWiki:Tiki bar/Archive/2016 for Tiki bar discussions started in 2016.

Pattern infobox: "Identifiers" section

Following private discussion with User:Dvgrn, I've added a new "Identifiers" section to pattern infoboxes, intended to collect identifiers (numbers, IDs, codes etc.) for a pattern in the various pattern collections floating around. Right now, it handles three identifiers:

• apgcodes, as used on Adam P. Goucher's Catagolue;
• Niemiec IDs, as used on Mark Niemiec's website (codercontest.com/mniemiec/);
• Pentadecathlon IDs, as used on Heinrich Koenig's Game of Life Object Catalogs (pentadecathlon.com).

apgcodes and Pentadecathlon IDs additionally link to the respective sites. The new section currently appears last in the pattern infobox, but this could easily be changed. The section's also hidden when no identifier is specified for a pattern.

On the technical side, this is implemented with a new helper template, Template:PatternIdentifiers, modelled after and based on Template:PatternDownload. New identifiers should be added here.

Existing pattern templates have been updated to use this new template. The following new parameters are available on all pattern templates:

• apgcode=
• niemiecid=
• pentadecathlonid=

What remains to be done:

• Add these new parameters to pattern templates where appropriate.
• Think about and add additional identifiers (e.g. for jslife or Dean Hickerson's stamp collection).
• Use the Niemiec ID (where available) to link to glider syntheses on Mark's website.
  • User:Dvgrn mentions that the filenames for the synthesis RLEs don't always match the objects' IDs; but there is a limited number of exceptions that could be handled using an additional "converter" template.
• Anything else?

Comments etc. welcome.

-- Apple Bottom (talk) 12:17, 11 January 2017 (UTC)

Since there's been no objections, I've gone ahead and added apgcode= parameters to all still life, spaceship and oscillator pages. (I do apologize for the sheer number of edits there, BTW.)

All pages thus edited also use Template:LinkCatagolue to provide links to the objects' Catagolue pages (if they didn't before, they do now), and I've been thinking that this might confuse the uninitiated -- doesn't this new infobox parameter essentially duplicate information? The answer is no. The infobox parameter exists to capture a piece of information about an object; it also links to Catagolue, but only for convenience's sake. The external link template, meanwhile, exists to link to Catagolue, and it's mere coincidence that one could also extract an object's apgcode from it.

I have vague future visions of machine-parsable microformat data for patterns, automatically generated by infobox templates; the various object ID parameters will be used for that. Link templates, for obvious reasons, cannot, since the generation would happen server-side on the wiki, rather than requiring special software on the client's side.

Getting back to the topic of ID parameters as such, I've been thinking that for jslife, it would perhaps be best to have a jslife20121230= parameter taking a filename (e.g. osc/o0015.lif), and perhaps an optional comment detailing where the object can be found in that file. That said, there are several objects appearing in more than one file in jslife (e.g. in the x-*.lif files). Assuming we want to link to the jslife files, rather than just indicating where an object is found, I'm not sure yet how to best handle this case. -- Apple Bottom (talk) 22:07, 1 July 2017 (UTC)

The pentadecathlonid= parameter seems to be bugged. - AwesoMan3000 (talk) 15:25, 2 July 2017 (UTC)

Thanks for the report. This was apparently caused by the parser not interpreting |- as new table rows, as it should have.

The deeper reason is that unfortunately in MediaWiki syntax, the pipe character is used both for templates (and parserfunctions) and for wikitables. When generating wikitables (complete or snippets), it's thus common to replace literal pipes with a call to a special template, conventionally Template:!, that contains nothing but a single pipe character. This way, e.g. table rows are given as {{!}}-, and this keeps the MediaWiki parser from interpreting the pipe characters while transcluding tables.

However, once all templates are transcluded, wikitables (and other wiki syntax) should still be interpreted on the result, and this wasn't happening here. I don't know why; it definitely worked in the past, as the two test pages I used for the identifier parameters (Boat on snake and 112P51) looked fine then. They didn't anymore now, suggesting that something, somewhere, changed, either MediaWiki or perhaps the underlying software stack.

In any case, I replaced the wiki tables on Template:PatternIdentifiers with equivalent HTML tables, which neatly bypasses this problem entirely. Apple Bottom (talk) 20:22, 2 July 2017 (UTC)

OEIS templates

I've added two templates mirroring OEIS data, Template:A019473 and Template:A056613, holding data for the number of strict/pseudo still lifes of a given population respectively.

I did this because I the same figures are used in different places, notably in the Still life and Catagolue articles (and several times in the latter), as well as in a few DYK items. Using these templates ensures that if numbers change (e.g. Mark Niemiec's 24-bit still life count, which Simon Ekström corrected) or if new data comes in, we'll only have to update the figures in one place.

Thoughts welcome! If you'd like to add more templates along these lines, just use either of these as a blueprint. They use MediaWiki's {{#switch:}} statement, which is more readable than a larger number of nested {{#if:}}s. Apple Bottom (talk) 12:21, 14 January 2017 (UTC)

I looked over the OEIS template changes to the Did-You-Knows -- seems like it works well! I have yet to think of other applications for this trick, but no doubt something will turn up eventually. -- Dvgrn (talk) 01:45, 4 May 2017 (UTC)

Direct links to syntheses

Following up on Apple Bottom's good work on Template:PatternIdentifiers a while back -- I've been wondering how much work it would be to provide direct links to Mark Niemiec's synthesis file for an object, whenever that is available in his database, along with or in place of the pname_synth.rle files that we're currently checking in one by one. Probably the new link would end up in the Glider Synthesis section, not the pattern-ID section, though in a way it's another kind of pattern ID.

We might not want to tackle that for the current version of the database, as there are rumors that some of the synthesis filenames will be getting adjusted soon. But I'd like to be ready to implement the idea when the next version of the database rolls out, if it's not too hard to do. As it is, a copy of Mark's synthesis file is what actually ends up getting checked in anyway, half the time -- might as well have it be the up-to-date one at conwaylife.com/ref/mniemiec...? Or maybe an automatic synthesis builder page along the lines of chris_c's, for whatever categories of objects that that might be made to work for.

The other interesting trick would be to check the smallest number of gliders for each object synthesis against the value in Niemiec's database, and report discrepancies in either direction. Maybe an adjustment could be made to applebot.pl -- Dvgrn (talk) 01:45, 4 May 2017 (UTC)

That's a great idea. I actually considered linking to Mark's files when creating said template, but didn't because you couldn't generate a link from the ID alone, you also needed to know in which directory on the web server the file resided. (Of course one could just add an extra template parameter for that.)

If Mark's gonna reorganize his DB, waiting's probably not a bad idea, yes. OTOH it wouldn't take much work on our side to add these links. Having them in the Glider Synthesis section of the infobox is probably sensible.

I've gone ahead and added links to chris_c's synthsis builder to the still life infobox; other pattern infoboxes can be adapted by changing the Template:PatternDownload inclusion to pass the apgcode parameter, at our leisure. Of course this will only work on pattern pages where the apgcode parameter is passed to the infobox in the first place, which right now aren't many. (Since many pages have Template:LinkCatagolue external links, though, adding them wouldn't be difficult, just tedious. Hmm, I wonder if this would be a task for User:Apple Bot as well.)

Re: updating the "fewest gliders" count, yes, the bot could do that as well. In principle, anyway; it's all a matter of actually implementing it. :) (And then running the bot, of course.)

BTW, I didn't know Mark's DB also lived at conwaylife.com/ref/mniemiec . Is this different/separate from the one at codercontest.com/mniemiec , or are they just different URLs for the same underlying site? -- Apple Bottom (talk) 11:23, 7 May 2017 (UTC)

Well, currently they're identical. In the long run I think the conwaylife.com/ref/mniemiec one will get updated, and the codercontest.com one will probably go away, after a period where comparisons of the two versions might be useful, for debugging purposes maybe. The GitHub repository for the latest and greatest versions of all the conwaylife.com/ref material is here -- at least according to the current plan. Dvgrn (talk) 17:33, 8 May 2017 (UTC)

Ah, thanks, I see. Template:PatternIdentifiers already uses Template:LinkCatagolue and Template:LinkPentadecathlonObject; if/when we decide to go ahead and link to Mark's files we'll also want to update Template:LinkNiemiec as necessary and use that. That way, when the move happens, we'll only have a single switch to flip. (Some stray links on talk pages etc. nonwithstanding.)

Thanks also for the link to the github repo! Apple Bottom (talk) 21:15, 10 May 2017 (UTC)

Creating "standard" images, RLE:pname pages, and where to use LifeViewer

I just pointed new trusted user User:wwei23 to the Pattern pages. I then noticed with some embarrassment that the checklist below "howto in a nutshell" still says images should be created "in Conwaylife". How long has it been since that was possible? I guess the time can't be measured in decades quite yet...!

1) Apparently Apple Bottom uses a script to make LifeWiki-style pattern images quickly, whereas I usually just use screenshots from Golly (but have to change Golly's default grid color to match LifeWiki images) or sometimes just sneakily hand-edit an existing image. What would be a good modern easy way to generate images -- maybe online via some variant of LifeViewer?

LifeViewer has the ability to open a screenshot (by using hotkey "o") in a separate browser window (if you allow popups) which could be saved as an image. Chris Rowett (talk) 03:33, 31 May 2017 (UTC)

That might be a good start. But often the things that images are needed of, aren't in the LifeWiki yet. So we'd really need a new image-maker page, where a user could paste in some RLE, adjust the zoom and dimensions to the right size (usually smaller than LifeViewer's current minima), produce the required .png file, and I guess save it to the local hard drive but only so that it can be uploaded right back to LifeWiki.  :: It would be wonderful to be able to generate the entire text of one of these image tags, for copying and pasting straight into an article --

[[Image:toadsucker.png|framed|center|One particular toad sucker -- the arrow indicates 30 generations of evolution<br />{{JavaRLE|toadsucker}}]]

-- where the process of uploading patname.png and patname.rle was made as easy as possible. Or at least patname.png and an "RLE:patname" page, I suppose, if we come up with some way for admins to convert RLE:patname pages to uploaded patname.rle files in bulk... without security issues, since that's the reason that Nathaniel limited access to the pattern and script upload functionality in the first place. Seems like a tall order to wrestle MediaWiki into shape to do this kind of thing easily, though. (?)

Also of course I had to add a "[*.]conwaylife.com" exception under Privacy > Content Settings in Chrome, to avoid the "Could not open Image window!" error when I tried the 'o' hotkey. It's so easy to get used to the LifeViewer just popping up and working, that that might slow people down quite a bit on average, without a hint about how to placate popup blockers. Dvgrn (talk) 12:32, 31 May 2017 (UTC)

Screenshots can now be create inline in the page if it contains an <img id="screenshot"> tag (rather than in a separate pop-up window). See here for an example page where you can enter RLE in a text box, click View to see it in LifeViewer, zoom and pan and run the pattern and then press hotkey 'o' when you want to create a screenshot image that you can then save from the page (right click on the image and "Save Image As..."). Chris Rowett (talk) 17:59, 3 June 2017 (UTC)

Any ideas for solving the image size part of the problem? It would be nice to be able to crop to particular dimensions rather than being stuck with a fixed-size image. I suppose the text box could feed LifeViewers of a dozen or so standard sizes, all showing the same pattern. Having a set of standard sizes might not be such a bad idea, really -- and if anyone wants to take the extra time they could always Save As and select a custom size in Paint or whatever.

However, what would be really nice would be to somehow completely avoid the Save As and then immediate re-upload steps. Starting from an inline LifeViewer display that has been panned and zoomed and themed and GPS-set and everything, maybe there's some automated way to produce the exact equivalent images and provide the new article text and formatting to match? Or do we maybe not need to do that? A LifeViewer with a setting that tells it to behave like an image might work just as well...? Dvgrn (talk) 21:12, 3 June 2017 (UTC)

[[ VIEWONLY ]] ? Chris Rowett (talk) 21:55, 3 June 2017 (UTC)

Yeah, maybe [[ VIEWONLY THUMBNAIL HEIGHT hhh WIDTH www (etc.) ]], or some replacement for THUMBNAIL that just removes the toolbars without shrinking the image, and also allows for a much smaller minimum height and width. Sometimes an illustration just doesn't need very much screen real estate.

That's a lot of configuration to have to copy in for every little illustration, though, and I didn't put in the gridline or theme stuff to match the "standard" images on LifeWiki. Maybe something like [[ WIKI ]] could lock down most of those settings to LifeWiki standards, while loosening up the height and width requirements?

Might even want to disable zooming and panning (and expanding-from-thumbnail), unlike the [[ VIEWONLY ]] tag. At least it doesn't have to be easy to pop LifeViewer out of image-display mode, for this use case, though there could be a sneaky shortcut... Dvgrn (talk) 02:32, 4 June 2017 (UTC)

Added [[ NOGUI ]] which disables all controls and menus and removes height and width restriction (since the restrictions were there to allow the gui to fit). See here for an example. Chris Rowett (talk) 14:05, 4 June 2017 (UTC)

In the next build hopefully you'll be able to click on the screenshot and it will automatically copy the RLE into the clipboard. This probably won't work on older browsers though. Chris Rowett (talk) 15:47, 6 June 2017 (UTC)

In LifeViewer build 230 when you mouse over a [[ NOGUI ]] image an "RLE" link appears which when clicked copies the pattern's RLE to the Clipboard. See here for an example. Chris Rowett (talk) 13:09, 10 June 2017 (UTC)

2) We should probably add some detail to the howto, about how best to use the RLE:pname workaround for making pattern files available without officially uploading them -- how to handle RLE header lines, etc. It does seem as if that has turned out to be a good idea -- right?

3) The question has also come up of whether to use static images or the LifeViewer for still lifes. See User talk:wwei23 for example links. Almost all still life articles are currently supplied with static images, but there are a few exceptions, and maybe some possible future-functionality reasons to use the LifeViewer everywhere... easy copying-out of a pattern without navigating to the RLE page? Maybe an option to edit and experiment in a new browser window, someday? -- Dvgrn (talk) 16:36, 30 May 2017 (UTC)

Since you mentioned it -- yeah, I'm using a script to generate images (though the process is only partially automated for animated GIFs, I do some manual post-processing on these). I keep meaning to release it, but it's a half-finished mess held together by little more than duct tape and prayers. Perhaps I'll get around to beating it into shape some time. Apple Bottom (talk) 12:16, 3 June 2017 (UTC)

The latest builds (229+) of LifeViewer are probably a good option for static images. The new [[ NOGUI ]] script command allows an image to be displayed of any dimension greater than or equal to 64x64 pixels. Additionally clicking on the image will automatically copy the RLE to the Clipboard (on most modern browsers). Chris Rowett (talk) 21:32, 11 June 2017 (UTC)

Change the pattern files back!

Remember the old pattern files in the same font as that appears in the edit box? Well, now it has changed, and now the Megacells are rendered useless! When I try to paste it in, Golly complains that the rule is invalid! I have to spend hours and hours reverting these changes. Surely, that's not what you want, right?-wwei23 3:39PM 7/2/2017 NY time

I'm sorry, but could you elaborate on what you mean? The "old" pattern files, as in uploaded files (not on-wiki RLE snippets), are still here, and are still linked wherever they used to be. For instance, 112P51 still links to this RLE file. I've also just checked P1 megacell and OTCA metapixel, the RLE files are fine for both.

What, specifically, are you trying to paste into Golly that is causing problems? -- Apple Bottom (talk) 20:28, 2 July 2017 (UTC)

Unable to replace old synthesis files?

I recently did a wave of adding syntheses to talk pages of certain articles, which was promptly followed by Apple Bottom uploading them (thanks!). However, it seems that some of them still have the old file, such as Elkie's p5, jam, cis-fuse with two tails, caterer, smiley, fore and back, griddle and block, Coe's p8, and copperhead. What could be causing this problem?

-- gmc_nxtman (talk) 20:03 UTC, Jul 15 2017

Hmm. I just checked, and indeed had the same problem on Elkie's p5 (but not the others): when I clicked on the synthesis file link, I got the old synthesis. Reloading that, however, then showed the new one.

Taking a closer look — my browser at least sends a If-Modified-Since header to the server, and the server accordingly replies with a 304 Not Modified if the file hasn't been touched since then.

It may be that this doesn't work properly with newly-uploaded files for some reason, perhaps (this is a complete shot in the dark, mind) if the file has been uploaded the same day that it's being requested. I can see the server (wrongly) replying with a 304 code instead of 200 OK (as it does otherwise), and the browser then concluding that the file it has cached is still valid, even though it is stale.

But my gut feeling is that this is unlikely, and that the browser is the culprit, somehow — presenting a cached (stale) version of the file without actually checking with the server to see if it expired. I'd have to investigate more to see what's really going on, but – TL;DR – a soft reload is enough to fix this, for me. Perhaps it will be for you, too.

--Apple Bottom (talk) 20:30, 15 July 2017 (UTC)

Listing multiple discoverers in pattern infoboxes

I added some extra parameters to the various pattern infoboxes to allow listing up to five discoverers for each pattern. The new parameters are named discoverer2, discoverer3, discoverer4, and discoverer5, in line with the already existing discoverer. The limit of five is arbitary, of course, but the maximum of discoverers we have listed at the moment is four (for the Half-baked knightship), so I don't foresee us needing six or more for a while.

I've also updated articles as necessary — those that had been manually put into discoverer categories, anyway. If there are articles that did not do this even though the article text itself may list several discoverers, they've not been updated yet.

There are two articles that I haven't touched: Heavyweight volcano, and Pre-pulsar spaceship. Both list several discoverers, but the discoveries refer to later improvements to or variants of the base pattern, rather than true collaborations, contribution of components, or prompt optimization of a new pattern after its discovery.

I'm leaning towards listing multiple discoverers in the infobox on both; with the Heavyweight volcano, the variants seem to be considered just that -- variants of the same basic pattern --, and with the Pre-pulsar spaceship, the different versions are no more fundamentally different than (say) the different Schick engines, but I'd like to put this up for discussion first and see what the consensus is. (FWIW, the Heavyweight volcano's variants were also discovered in different years, so I might have to further extend the pattern templates to allow specifying multiple years of discovery, too. But that doesn't feel quite right, and leads to further questions of what exactly these templates are to inform about anyway: specific individual patterns, or families of patterns?) -- Apple Bottom (talk) 11:25, 18 July 2017 (UTC)

Niemiec IDs in pattern infoboxes

I've started filling in ID number for Mark Niemiec's pattern database in pattern infoboxes. Still lifes are done, with the following exceptions:

• Still lifes with population eight or less do not have numbers, and are instead referred to by name in Mark's DB.
• Still lifes with population twenty-five or greater do not have numbers. This affects:
  • Cloverleaf interchange, Professor, Cthulhu, Omnibus with tubs, Eater 4, Cis-mirrored worm siamese cis-mirrored worm, House on house siamese table-on-table weld hat-siamese-hat, Very^9 long boat.
• A few still lifes with population twenty-five or greater nonetheless appear in the DB, without ID numbers. These are:
  • Omnibus, Tetraloaf I, Mickey Mouse.
• A number of still lifes with population between nineteen and twenty-four are not identified by the search widget. These are:
  • Very^8 long boat, Very^7 long boat, Very^6 long boat, BTS.
• A number of still lifes with population eighteen are similarly not identified by the search widget; since Mark provides complete lists of these, they could theoretically be found. These are:
  • R-mango and house, Longhook and dock, Cap and dock.

One more thing I noticed: Super loaf has two ID numbers in Mark's DB, 17.3188 (the regular number) and 17#266. Does anyone know what list the second number refers to? I initially thought it might be from Pentadecathlon, but 17.266 on there is a different object.

Similar ideas also exist for other still lifes in Mark's DB; for example, Shillelagh siamese open house siamese snake is listed as both 16.312 and 16#17. Any ideas? -- Apple Bottom (talk) 12:13, 20 July 2017 (UTC)

Lists of rules

There's been some contention about what rules should and shouldn't be added to the various lists that the LifeWiki currently has. Broadly speaking, we have two kinds of lists of rules:

1. lists of examples embedded in articles such as Larger than Life, Generations etc.; and
2. lists of rules living in their own article, e.g. List of Generations rules.

(List of rules investigated on Catagolue is a special case, insofar as that it aims to provide a service that Catagolue itself doesn't: a comprehensive list of rules investigated on there. If such a list were available on Catagolue, this article would not be necessary.)

It's my belief that the former kind of list should not be comprehensive, but rather just list a few (important, interesting) examples to give readers an initial idea of and feeling for the kind of rules making up a given kind of CA. I further believe that this is not a matter of contention.

The latter kind of list can be more expansive, but I don't know if we should try to list every single last rule that anyone's ever come up with: not all rules are equally interesting, after all. And the fact that people have an (understandable) tendency to overestimate the significance of their own creations and will prominently put these into those lists might give readers a skewed impression of how notable certain rules really are (or aren't).

But edit wars are unpleasant, an in order to rectify this situation I'd like to propose three things.

1. The "lists of rules" articles we have should continue to focus on notable rules.
2. Since what is or isn't "notable" is difficult to capture, people should simply refrain from adding their OWN creations, the same way people are asked to refrain from writing articles on their own discoveries. If a rule is notable, someone else will eventually add it.
3. Finally, since there clearly is a desire to have a comprehensive list of rules that everyone can freely add to, maybe we should create one.

We'd still have to figure out what form that comprehensive list should take and what namespace it should live in -- or whether it should live on the wiki at all, or whether the forums might not be a better place. If it should indeed live on the wiki, we'd also have to figure out its relationship to the lists of notable rules we currently already have.

All of this is just food for thought, right now. And perhaps I'm overthinking things, and a rule of "don't add your own rules" is all we really need, just like "don't write about your own patterns" has worked well for keeping the pattern articles uncluttered.

Thoughts? Apple Bottom (talk) 12:10, 7 August 2017 (UTC)

I'd certainly go and search in a comprehensive-list-of-rules page, once it got comprehensive enough. It would be very convenient when I inevitably forget what someone means by "salad", or "{a-z}life", or whatever.

The wiki is a little more appropriate as a location, I think... or at least it would be if the process of getting trusted didn't take so long (still working on that detail). It would work almost as well if someone made a dedicated forum thread and then kept the top posting up-to-date. But that's pretty awkward when potential contributors just want to be able to sneak in and add a name/alias pair on the spur of the moment.

Seems like the table will need a rule string, a list of aliases (hopefully a short list, but there might be more than one sometimes), any classification columns like "Character" (but probably keep those to a minimum), and a place for a link to a rule table posted on the forums. And maybe a separate link to a forum thread or posting or external URL, if any, documenting interesting discoveries in that rule? Dvgrn (talk) 13:50, 15 August 2017 (UTC)

OK, let's put it on the wiki then, that's probably the most sensible place to have it. The "Nathaniel-doesn't-scale" problem with trusting users appears to be fixed now, too, so everyone can and will indeed be able to add to this. :)

I agree that it would be best to not put too much information into this list, and instead just use it as a hub linking to other places. I'd lean towards keeping things like "Character" out of this list, but that's me. We'd definitely want to include the rulestring, name(s) and any relevant links, to forum threads or otherwise.

I've already got a script that parses downloaded copies of the "Other rules" forum's thread overview pages, extracts rules from thread titles and associates threads with each rule; this could be used to seed this article, since the script could easily output in different formats.

There's the issue of keeping this list up-to-date, of course. Do we commit to trying to do so, or do we just say "we've created this list, but we're not making any claims as to completeness, and it's up to the larger community to add to it"? (I'm leaning towards that; I don't want to commit to keeping this up to date by hand, and while semi-automated updating works for List of rules investigated on Catagolue it wouldn't mesh well with an article that is hopefully going to see lots of human editing.)

Another issue we'd have to take into account is that different rulestrings might in fact represent the same CA: for example, B2-cek/S23 is the same as B2ain/S23. So we should (probably) try to normalize rulestrings in some way, and I can see two obvious ways of doing that:

1. Don't allow negated conditions in the canonical rulestring. This is what my scripts do internally to handle non-totalistic rules.)

   Upsides: relatively easy to determine.

   Downsides: with B4 and S4 in particular, negation-free rulestrings can get quite long and unwieldy.

2. Normalize the same way that Catagolue does, however that is.

   Upsides: shorter canonical rulestrings; no proliferation of different methods of canonicalization on different sites.

   Downsides: not necessarily so easy to figure out. Does not extend to classes of CAs Catagolue doesn't cover.

In any case we'll definitely want to support multiple rulestrings in the same entry, as different people might express (and search for) the same rule in different ways. We could either do this by having a "canonical rulestring" column and then an extra "rulestring aliases" column, or eschewing the former in favor of just the latter. Having only the latter column feels cleaner to me; I'm a little concerned about duplicate entries, but perhaps that's not such a big concern in practice. (If it only happens sporadically, it can be mopped up easily enough, by us or by other editors.)

There's also the question of whether it would make sense to separate forum thread links from other links. (Probably not.) We'd probably want Catagolue links as well on this page. (And of course if we happen to actually have an article on a rule, we'd definitely want to link to that.)

That's about what I can think of right now. Apple Bottom (talk) 21:02, 15 August 2017 (UTC)

A first stab is up at User:Apple Bottom/Sandbox/List of rules. All of this is auto-generated by a script looking for threads that appear to have rules in their title.

What the script doesn't do, right now:

1. Handle Larger than Life rules. Fortunately none seem to be mentioned in thread titles so far; there's a general LtL thread, but no dedicated threads for specific LtL rules.
2. Fill in rules' character. This would need another (hand-curated) datafile to draw on.
3. Recognize rules only mentioned by name (e.g. in thread 1852, "Day and Night puffer").

The script DOES detect certain edge-cases where it isn't sure whether something is a rule or not. (There is, unfortunately, some inherent and unresolvable ambiguity in rule notation. Does e.g. "6c/123" refer to a spaceship speed, or the cellular automaton B123/S6c? It's not possible to say for sure without context.)

I'm also not particularly happy with the formatting yet; tweaks welcome. The generating script (quite dirty, especially the parts I tweaked just now to generate a wikitable) is here.

One final note: I should reiterate that there's no plans on my part to keep this list updated when/it it goes live. In particular, I'd not try and splice links to new forum threads into the list after it's been edited manually.

I'd also like to suggest that the final version, if created, should live in the LifeWiki: namespace. Apple Bottom (talk) 20:53, 26 August 2017 (UTC)

LifeViewer image display and pattern copy functionality

Build 233 of LifeViewer is now live here on the Wiki and includes a couple of helpful new features:

1. LifeViewer can now be used to display static images with the [[ NOGUI ]] script command. You can right click on the image to save it (Save Image As...).

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! [[ NOGUI THEME 6 GRID HEIGHT 128 WIDTH 128 ]]

Images can be as small as 64x64 pixels:

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! [[ NOGUI THEME 6 GRID HEIGHT 64 WIDTH 64 ]]

2. LifeViewer can now copy the pattern source RLE to the clipboard. For a [[ NOGUI ]] LifeViewer, simply mouse over the image and click on it when "Copy" appears. For a standard LifeViewer click on it to interact and then use Control-C.

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! [[ THEME 6 GRID HEIGHT 240 WIDTH 480 ]]

You can disable the Copy functionality with the [[ NOCOPY ]] script command:

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! [[ NOGUI NOCOPY THEME 6 GRID HEIGHT 128 WIDTH 128 ]]

Chris Rowett (talk) 19:11, 15 August 2017 (UTC)

Fantastic news! This might be the (beginning of) the end of manually-created and -uploaded images for pattern infoboxes. :D So the way forward would be, I think:

1. Decide on the "standard" size images in pattern infoboxes. Something like 256x256? That should be neither too big nor too small. (Whatever we decide on here should be kept in some configuration Template: so that if we decide to adjust it later, we'll only have to do so in one place.)
2. Rig Template:Pattern etc. to check for an RLE snippet by default, and use that to display an image if it exists; otherwise, fall back to the old way of displaying uploaded files.
3. Perhaps introduce a new template parameter to override this and force the display of a manually-uploaded image; I'm thinking of articles like 26-cell quadratic growth there. Granted, that one doesn't have an RLE snippet anyway, but there might be situations where we want a "special" image.

While we're at it we may also want to change the "View static image" and "View animated image" links in the infoboxes to also additionally link to the files' description pages; but that's not directly related.

Am I right, BTW, in assuming that NOGUI viewers will always auto-adjust to fit the pattern? Apple Bottom (talk) 21:12, 15 August 2017 (UTC)

Yes, they use exactly the same rules as standard viewers. By default they will auto-adjust to fit the pattern but you can overrule this with script commands:

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! [[ NOGUI NOCOPY THEME 6 GRID HEIGHT 128 WIDTH 128 ZOOM 4 X 10 ]]

Chris Rowett (talk) 04:47, 16 August 2017 (UTC)

5s Project Transfer Possibility

I have been asked if it was possible for me to put the spaceships (in some format) from the 5s project on the forums here, so that everyone with a "trusted account" could edit and add new speeds or improve previous size records. Is this a feasible thing to do? If so how could this be implemented? I figured I'd ask here before doing anything.

Should be quite doable — Collaborative editing is what wikis are all about, after all! I see you've already created a subpage in your userspace for this; I think that's indeed the best way to go about it. (The main article namespace, being mostly focussed on Conway Life and general CA-related glossary, would be a poor fit.)

Have you seen LifeWiki:Game of Life Status page, LifeWiki:Spaceship Search Status Page and User:Sokwe/Spaceship searches? These might provide some ideas as how to structure the 5s status page. (Personally, BTW, I'd just keep all periods on one page, and not create separate pages for p1-10, etc.)

If anyone wants to contribute but doesn't have the Trusted flag, just have them post in the "Massive spam attack" thread (after creating an account on the wiki if necessary). All wiki admins can hand out the flag nowadays, so there shouldn't be too many delays.

(Also, for the benefit of anyone else reading this, the 5s project thread is here.)

Apple Bottom (talk) 11:06, 18 August 2017 (UTC)

LifeWiki:Smallest Spaceships Supporting Specific Periods seems like the logical idea, since the other project pages are hosted in said namespace.

Personally I would prefer it if the project was laid out with different pages for each period, with each period being linked to from the page linked above; this way, periods could be "completed" (i.e. every single speed, direction, etc. combo of that period is known, and all examples have exactly 3 cells), and this could be clearly marked on the main page with the list of periods. I also had a much more complex idea, involving sorting the ships by direction and then perfectness of speed (c/n, 2c/n, 3c/n...), but I don't think a lot of people would like said idea. Also, I feel as though keeping every single spaceship on the one page (or three pages, assuming the direction categories will be separate) would get cluttered very easily, and not as easy to navigate as a list of periods.

- AwesoMan3000 (talk) 12:36, 18 August 2017 (UTC)

Maybe it could combine those, as I said in the 5s thread, that it could be split into multiple pages, but with multiple periods on each page. Can the page be under the LifeWiki tag? I think LifeWiki:Smallest Spaceships Supporting Specific Speeds p1-10 could work, making pages for each set of 10 or so periods, adjusting based on number of spaceships per period. I don't think putting a page for each period would be a good idea, as it would be way too many pages.

- AforAmpere (talk) 15:49, 18 August 2017 (UTC)

LifeWiki:Smallest Spaceships Supporting Specific Periods sounds good to me. If you want to break this up by individual period (or group of periods), I'd suggest using subpages of that page, e.g. LifeWiki:Smallest Spaceships Supporting Specific Periods/Period 1 or LifeWiki:Smallest Spaceships Supporting Specific Periods/Period 1-10 etc.

Transclusion is not limited to templates, BTW, all pages can be transcluded, so the "main" page for this project could have both an overview, and then transclude its subpages so that viewing the "main" page would still give readers all information at one glance. The syntax for transclusion is e.g. {{LifeWiki:Smallest Spaceships Supporting Specific Periods/Period 1}} — same as for templates, except you have to explicitely give the namespace. It's also possible to use the usual template tags, such as noinclude, includeonly and onlyinclude, to control what does/doesn't get transcluded.

My personal feeling is that unless you expect the page to grow very large (say, >100 KB) this would be overkill, but I don't have a horse in this rodeo. Apple Bottom (talk) 10:52, 21 August 2017 (UTC)

This could potentially happen (even and especially to the smaller periods) if we include Larger than Life rules in the list. Are you sure you want to keep multiple periods grouped on the same page? - AwesoMan3000 (talk) 20:36, 23 August 2017 (UTC)

Newer DYK items

There's been an influx of DYK items recently. I've not updated the count on the Main Page in a while, primarily because I'm not convinced they all belong on the list; I'd planned to simply postpone this for another while, but the question was raised on the forums earlier today, so here's my thoughts on the items not currently being shown (#92-100):

#92 needs rewording; unless you already know what it's talking about, it really isn't very clear.

#93 is fine.

#94 is fine.

#95 ... I don't even know. Certainly not worth a DYK item on the Main Page, IMO.

#96 needs an article describing the open question it's talking about.

#97 is fine.

#98 is fine.

#99 is fine. (But let us stop here and not fill half the list of DYK items with still life counts.)

#100 is definitely NOT fine with the Bugs article being in the state it's currently in. (User:AwesoMan3000: you started it, you finish it.)

Also, re: #92 and #100, the LifeWiki (and by extension the DYK section) is primarily about Conway Life. General information relating to other classes of CAs is fine (such as #93), but I'm on the fence about adding DYK items on specific patterns/pattern families in other CAs. Where would we stop?

That's just MY two bits, of course. Thoughts? Apple Bottom (talk) 20:34, 23 August 2017 (UTC)

This matches my sense of the intended purpose of the LifeWiki. It makes a lot of sense to -- for example -- list Life-like and isotropic rule strings and aliases on a user page somewhere, because that's a good place for people from the forums to do collaborative editing. And for some specific rules like HighLife, which have old and deep connections to the Lifenthusiast community, it certainly doesn't hurt to have a page up on LifeWiki -- especially since you could say that it's doing a kind of compare-and-contrast, referring back to B3/S23 Life.

However, this is definitely the LifeWiki, not the CAWiki. If someone wants to host a CAWiki somewhere else, that's certainly fine, but I'd rather not see just rare occasional miscellaneous non-B3/S23 CA items scattered randomly through all of the existing detailed B3/S23 content. It seems like this is a problem not just for the Did You Knows, but for regular articles as well. Suppose you read under "Spaceship" that the maximum possible orthogonal speed is c/2, but then you go to the spaceships list and find a link to a lightspeed photon, and maybe another link to a 50c Larger Than Life spaceship.

-- That seems like it's just plain going to be too confusing... and it will get more confusing as more non-B3/S23 articles and definitions are added. Can we please just not go there? User namespaces seem like a fine place to keep general CA content. Dvgrn (talk) 00:19, 24 August 2017 (UTC)

Also I personally think we should mercilessly kill off most of the still-life-count Did You Knows, just as soon as we have more interesting trivia items to replace them with. Dvgrn (talk) 00:22, 24 August 2017 (UTC)

That's probably sensible. They were interesting right after being computed, but they have not aged well, as it were.

I've gone ahead and edited, deleted, and rearranged items as necessary, so right now the list (down to 92 items) looks OK to me. I've updated the DYK count on the Main Page, too.

More DYK items would be cool to have of course, so long as they're a) related to Conway Life and b) sufficiently interesting. Perhaps in the future, instead of just adding them right away, we should instead post them here on the Tiki bar for discussion first, to see what others think? Apple Bottom (talk) 10:21, 25 August 2017 (UTC)

Changing protection levels

I've just changed the protection level on a number of pages, usually down from semi-protected (or, sometimes, fully protected) to unprotected. I should've perhaps discussed this here beforehand instead of afterward, but I tend to shoot from the hip. ;) However, I'd like to provide some reasons for this. The biggest and most important one is:

1. Lack of necessity. LifeWiki editing, these days, is already limited to trusted users who have to be approved by hand. Semi-protection, in particular, is pretty much entirely irrelevant as a result, and full protection isn't necessary either, at least where it's intended to protect against vandalism and other bad-faith edits.
   • Protection can also protect against innocent mistakes made by inexperienced editors, but I don't think we currently have anyone who's both a) very inexperienced (in particular, so inexperienced they do not know how to revert their own edits), and b) prone to editing complex templates etc.

There are other reasons:

1. Consistency. In a lot of cases, protection was not applied consistently, e.g. to pattern templates, pattern categories and so on; these would sometimes be semi-protected, sometimes fully protected, and sometimes not protected at all. It would have been possible to apply semi- or full protection to all of them instead of unprotecting them, but the other reasons listed here made me prefer unprotection them.
2. Ineffectiveness. This is a fairly big one, I think. The LifeWiki uses a lot of templates, e.g. for pattern categories. Without either protection on these templates, or cascading protection enabled on the transcluding categories, these categories could still be changed by editing these templates.
   • It would of course have been possible to instead protect all templates and categories, but see the next point.
3. Maintainability (content). Although many categories etc. (e.g. Category:Oscillators with volatility 0.55) may not have to change, we may well want to change e.g. the navbox used on that category in the future (say, to add new subcategories or related articles), and this shouldn't require an admin bit to do.
4. Maintainability (infrastructure). As noted above, there wasn't a whole lot of consistency with regard to which templates/categories/articles were or weren't protected, and to which extent. Settling on semi-protection or full protection now would've fixed the lack of consistency for the moment, but would've required ongoing admin work to keep everything consistent.

(There may be other reasons that aren't on my mind right now.) All things considered I thought it was best to unprotect most of the (semi-)protected pages. Note that that's MOST — the Main Page is still protected of course, as are any pages it transcludes, a few guidelines, the ToS, some deep infrastructure templates that should never, ever change (Template:! and friends), and a few others I didn't feel 100% comfortable unprotecting right now. See Special:ProtectedPages for an overview of what's currently still protected. Apple Bottom (talk) 13:12, 27 August 2017 (UTC)

Strict volatility

Template:Oscillator now supports an sv= parameter for an oscillator's strict volatility (i.e. the share of cells oscillating at the full period).

This is set automatically for all oscillators of prime period. (Prime periods are checked using Template:isPrime, which currently only goes up to 1000, but we don't have articles on oscillators with higher periods than that anyway.) For other oscillators it should be specified manually, and I've done this for every oscillator entry we currenlty have. When creating a new article, editors can use e.g. Oscillizer:

Just like regular volatility, this should be given as a regular fraction rather than a percentage, and rounded to two decimal digits, so "strict: 1.10%" would become |v=0.01. New categories should be created as needed, using Template:OscillatorStrictVolatility to fill in category pages as follows: {{OscillatorStrictVolatility|sv=0.55}}. The tracking category for oscillators with unknown (unspecified) strict volatility is Category:Oscillators with unknown strict volatility.

One note: some oscillators have very small strict volatilities that would round to 0.00, but I thought it was important to only display strict volatility as zero if it really is exactly zero. I've therefore used three decimal digits (rounded, again) instead of two on those pages where using two would round to 0.00. If we want to stick to exactly two decimal digits we could instead round to 0.01 in those cases.

(FWIW, although we have no entries on oscillators with a non-strict volatility below 0.08, how are we handling this for volatilities approaching one? Do we always round down for oscillators with non-empty stators, or do we not care about distinguishing true statorless oscillators from nearly statorless ones?) Apple Bottom (talk) 16:53, 31 August 2017 (UTC)

Pentadecathlon IDs for strict still lifes

All our strict still lifes now list Pentadecathlon IDs in their infoboxes, assuming of course they are in the pentadecathlon.com database. The relevant parameter, pentadecathlonid=, was introduced a while ago already, but not widely used until now.

Strict still lifes lacking this field are tracked in Category:Still lifes with no Pentadecathlon ID. Right now, it contains the following nine entries, all of which are not present in the PD database:

• Cis-mirrored worm siamese cis-mirrored worm
• Cloverleaf interchange
• Cthulhu
• Eater 3
• Eater 4
• House on house siamese table-on-table weld hat-siamese-hat
• Omnibus with tubs
• Professor
• Very^9 long boat

Other objects also can and should receive Pentadecathlon IDs. (Anyone up for the task?)

There is an implicit assumption in all this that the IDs given on PD are stable. They should be for still lifes up to 24 bits, which are completely enumerated on the site, but Heinrich's Definitions page, which talks about creating sorted lists of objects, has me wondering if larger objects might end up getting renumbered when -- if -- the site's DB ever gets updated with the exhaustive lists of still lifes up to 32 bits computed by Simon Ekström, Nathaniel Johnston and me. The LifeWiki doesn't have too many articles on larger still lifes however (...yet!), so in the event that this should happen these could easily be updated.

The pentadecathlonid= parameter is also used to link to PD's object synthesis pages, so as a side effect a lot more information re: using objects as sources for/results of reactions is now readily accessible from the LifeWiki. Linking to Mark Niemiec's DB remains an open question; the Life Search page works locally using Javascript. (Any ideas on how we could tackle this?) Apple Bottom (talk) 14:53, 20 September 2017 (UTC)

"Forum Username" on "Person" Template?

What about a "forum username" section on the person template? Maybe there could be a "Identifiers" dropdown? So Dave Greene;s would be "dvgrn" and so on. — Preceding unsigned comment added by Saka (talk • contribs)

This would be possible, sure, but: why? Apple Bottom (talk) 21:45, 9 November 2017 (UTC)

Why not? This could be nice for beginners that want to see if they can talk with legendary GoLpeople™ Saka (talk) 12:49, 11 November 2017 (UTC)

LifeViewer inline patterns versus JavaRLE

As discussed 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 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?

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?

It still seems good to have copies of these patterns available in the downloadable ZIP file, though. Does 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.

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. Dvgrn (talk) 15:27, 26 November 2017 (UTC)

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.

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:

{{Oscillator

|name = Prancing Ponies

|pname = prancingponies

|p = 49

...

|rle =

x = 20, y = 17, rule = B3/S23

...

|... = ...

}}

...would work, or whether it might break because there's equal signs in the value of the rle 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 {{=}}, but users will forget this, and if it then doesn't work they will not understand why.)

The above applies equally to the synthesis RLE, of course. On that note, having the synth RLE for pname live in RLE:pname_synth or Synth:pname 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.)

As always, TIMTOWTDI (There Is More Than One Way To Do It)...

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 several pages are already using it), even if that template's still got room for improvement.

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

(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...) Apple Bottom (talk) 21:29, 28 November 2017 (UTC)

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 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 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 {{GetRLE|Glider}}, and it would grab the RLE from the pattern template on the "Glider" page. Nathaniel (talk) 17:42, 1 December 2017 (UTC)

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.

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

• keep RLE in wiki pages, in the existing RLE namespace or a new one (say "RLE synth"); or
• 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.

Apple Bottom (talk) 22:02, 9 December 2017 (UTC)

Is it time to make an executive decision about supporting RLE:pname_synth or Synth:pname, with the infobox template rigged to add a raw-RLE link if that page exists? Either option seems fine to me.

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.) Dvgrn (talk) 22:04, 21 February 2018 (UTC)

Yes, let's Make It So! And automatically copying on-wiki RLE into the pattern collection? Yes, please.

Still not sure whether RLE:pname_synth or Synth:pname 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 RLE: page lingering in the Main namespace right now that is being shadowed by an RLE: namespace counterpart.) So yeah, leaning towards RLE:pname_synth right now.

As for what should be included in RLE snippets, I think ideally it should be this, at least:

#N Pattern name
#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.

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?

One way around this would be to put a suffix on the files generated from on-wiki RLE snippets, so that e.g. RLE:ponyexpress would become ponyexpress_wiki.rle, or some such thing. Conflicts could then be handled by simply assuming that any file whose name is suffixed _wiki 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?

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.

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

But that's enough rambling from me! Apple Bottom (talk) 09:08, 22 February 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
#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.

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 Category:Pages_with_raw_RLE_code_but_no_uploaded_pattern_files and 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? Dvgrn (talk) 11:46, 22 February 2018 (UTC)

Deleting superseded oscillators

Sokwe recently proposed a few oscillators for deletion that used to be (?) the smallest of their period but aren't anymore: 114P84, 122P80.1, 126P78.1, and Twin bees shuttles hassling blinker.

I think we should keep these, myself. I wouldn't encourage people to create pages on oscillators such as these, but OTOH once they exist I see no harm in keeping them. They're on-topic for the LifeWiki, and the amount of DB space they take up is negligible. (Not to mention that deleting an article doesn't free up the DB space it takes up anyway; MediaWiki keeps it around behind the scenes to allow undeletion.)

How do others feel about this?

(As usual, I'd also propose that since these are good faith, prima facie useful articles, they be moved out of the main article namespace to subpages of their creators' userpages, rather than deleted outright.)

Apple Bottom (talk) 18:44, 21 December 2017 (UTC)