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)

LV:Viewer

Thanks to User:Nathaniel's and Chris Rowett's efforts, the LifeViewer applet's now available on the LifeWiki:

2bo4bo2b$2ob4ob2o$2bo4bo

So how do we best integrate this into our existing articles? Ideally I'd like for all articles on spaceships, oscillators, guns etc. to have (at least) one of these so people can easily see patterns in action; but I'd also like for the result to look good. Simply embedding the viewer applet, like I did here on Copperhead, works, but it isn't very pretty.

Since we already have infoboxes for pattern, it would be natural to reuse those. Embedding the viewer applet may make them too wide, but we could introduce an extra section (akin to "Rules", "Glider Synthesis" etc). Alternatively, we could add a second tab at the top of the box, allowing the user to switch between a static image and a viewer applet.

For specifying an object's RLE code, we could introduce a new infobox template parameter. However, that might get unwieldy with large patterns, so instead I'd suggest introducing a new namespace, RLE:, using the pname infobox parameter as the page title. To wit: since Copperhead's pname is copperhead, its RLE page would be called RLE:copperhead and would contain only its RLE code, b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o. This would keep pattern pages from ballooning in size, as well as make it easier to edit RLE codes. It could even be used to auto-generate downloadable pattern files in the future.

Thoughts? Apple Bottom (talk) 11:09, 13 June 2016 (UTC)

It would be nice if it came in a new Infobox section. Of course, with a [show] button on it so it doesn't clutter everything up, and when it is shown it should be scaled down a bit as to not stretch the infobox.

Another idea would be to add it as an external link, similarly to the "View animated image" link. Is could either direct to a blank page with just the LifeViewer applet, or make it pop up like on the forums.

Finally, we could dedicate a section to it. Since slapping it at the start of the page is kind of unsightly, it might be better if it (or a scaled down version of it) was placed in the Gallery section.

-AwesoMan3000 (talk) 12:20, 13 June 2016 (UTC)

The idea that's been floating around in my head is to keep the static images as the "main" images in the infoboxes still, but add a second link (either above or below the current "View Animated Image" link) that says something like "Show in Viewer", and opens a LifeViewer overlay akin to the forums. But if people would prefer having a (smaller) LifeViewer right in the infobox, we can go that route too. Also, using a new RLE: namespace to store the RLE code seems like a great idea. Nathaniel (talk) 12:57, 13 June 2016 (UTC)

I agree that it's often good to start with a static image in the info box, and link from there. It's also nice to be able to define a waypoint animation that illustrates some particular use of a pattern -- a slow-motion loop showing a buckaroo reflecting a glider, or whatever. In that case it might be better to have the viewer inline, and maybe even started automatically with AUTOSTART, making it a higher-function equivalent of an animated GIF.

But maybe in many of these cases the viewer could be initially minimized with the THUMBNAIL tag, so it doesn't take up too much space unless a user wants a closer look? I haven't discovered how to make waypoints or tags work yet. Also, here's a mystery for y'all: why does the image below show a glider instead of a pentadecathlon, if I include a standard RLE header line? (Mystery solved, see below.)

x=10, y = 3 2bo4bo2b$2ob4ob2o$2bo4bo! #C [[ THUMBNAIL AUTOSTART GPS 2 ZOOM 30 ANGLE 45 THEME 4 WIDTH 480 HEIGHT 600 ]]

Also, unrelated -- is it possible to embed the viewer in a way that allows text to flow around it to the left or right? Dvgrn (talk) 13:41, 13 June 2016 (UTC)

Ah! The pentadecathlon/glider issue is caused by the RLE code starting with "x=". MediaWiki interprets this not as "make the first parameter 'x = 10, y = 3, ...'", but rather as "make the x parameter '10, y = 3, ...'". I'll try to get a workaround for this and the tags not working. Nathaniel (talk) 14:00, 13 June 2016 (UTC)

Both issues are now fixed. To make text float around a Viewer, it might be easiest to put a floating DIV around it like this (view this page's source code):

x=10, y = 3 2bo4bo2b$2ob4ob2o$2bo4bo! #C [[ THUMBNAIL ]] #C [[ AUTOSTART GPS 10 ]]

This is a LifeViewer that floats to the left of its text.

Nathaniel (talk) 14:31, 13 June 2016 (UTC)

Looks good! I've adjusted my example to try some other LifeViewer script tags, and everything seems to work now. You can hit 'N' to get back to a thumbnail view after a viewer has been expanded. Is there an obvious way to clue in new users about keyboard shortcuts like this? Maybe it's simpler to just expect people to refresh the page when they want to reset the viewers.

A div style="clear:both" tag stops the text from flowing around the viewer panel, for a paragraph that starts a new topic, like this.

Might it be a good idea to put in a warning or a placeholder for LifeViewer, when a browser is non-HTML5-compatible? I tried turning Javascript off in Chrome just now, and the viewer panels disappeared completely, with no sign that there was supposed to be anything there. Dvgrn (talk) 15:26, 13 June 2016 (UTC)

Has anyone considered my ideas yet?

My personal favourite is the basic link one, as it takes up a lot less space. However, embedding the viewer into a new section on the infobox definitely seems like the fanciest idea.

I've also created three pages under the RLE namespace, namely for the three elementary spaceships which don'r link to an RLE.

- AwesoMan3000 (talk) 17:16, 13 June 2016 (UTC)

I like the idea of putting a link in the infobox that'll pop up a viewer applet when clicked best. I made a mockup of this, shown on the right — the links a bit larger and bolder so it'll stand out to people (font-size: larger; font-weight: bold). Clicking this link would then create an overlay on the page with the viewer applet so people could play with the pattern; pressing Escape should close the applet again.

Of course there needs to be a graceful fallback for users who have Javascript disabled, as Dvgrn has pointed out. I think the easiest way to achieve that would be to:

1. Create a new page in the LifeWiki: or perhaps Help: namespace explaining that the viewer applet will only work with Javascript
2. Have the "View in LifeViewer" link point to that by default, and
3. Use Javascript to change the target of said link dynamically (so that if it's not enabled, the link would keep pointing to the explanatory page).

Alternatively the link could be inserted using Javascript in the first place, but the downside would be that users who have Javascript disabled would not become aware that there is a LifeViewer applet in the first place.

Regarding the RLE: namespace: so far it's not a proper namespace but rather a title prefix that pages in the main namespace happen to have. If we want to move ahead with this I'd suggest we have Nathaniel add the namespace to the wiki's configuration, and only then begin creating RLE: pages.

It may be worth semi-protecting the entire namespace so only autoconfirmed users can edit it by default, but it may equally well be unnecessary.

Either way, once we have it set up, we can start adding RLE snippets there. This would then allow us to automatically include links using {{#ifexist:}} and ?action=raw, without sysops having to manually add RLE files for patterns (same for glider synthesis RLE snippets, of course). I imagine one could also write a MediaWiki extension that could be used to automatically convert RLE patterns to Plaintext, Life 1.05 and Life 1.06 format, if desired; this would give automatically give us all patterns in all file formats. (That said, is anyone still using those?)

The only downside I can see is that there wouldn't be a handy way of compiling the collection of all pattern files that's linked on the Main Page anymore. But Nathaniel could presumably set up a cron job that goes through Category:Patterns to collect all the files. (Alternatively, perhaps it would be possible to have every edit in the RLE mainspace reflected in a matching RLE file outside the wiki so the cron job would only have to collect those in a zip file.)

Finally, regarding instructions for the LifeViewer — there is a Help Button, but if we're going to go the overlay route we could just as well include the most useful keys in the overlay. Apple Bottom (talk) 20:52, 13 June 2016 (UTC)

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! #C [[ THEME 6 GRID COLOR GRID 229 229 229 COLOR GRIDMAJOR 229 229 229 ]] #C [[ AUTOSTART GPS 5 ZOOM 32 Y -6 THUMBNAIL LOOP 120 HEIGHT 800 ]]

I like the infobox LifeViewer link idea -- it keeps the page from looking too full busy when it's first loaded.

That said, I tried some experimental changes to the Copperhead article to reduce the visual impact of the viewer. The version there has no gridlines turned on. With a few more script tags we can match the color of the LifeWiki's usual gridlines fairly well -- see the viewer at right. Dvgrn (talk) 15:45, 14 June 2016 (UTC)

I made just some minor changes to match things to our static images a bit more. I like it --- we could have the thumbnail LifeViewer be used by default, but if Javascript is disabled, it will fall back to the regular static image. One thing though -- is there a way to specify width/height of the thumbnail in LifeViewer? If not, I'd like to bug Chris to add that feature. Nathaniel (talk) 16:21, 14 June 2016 (UTC)

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! #C [[ THEME 6 GRID COLOR GRID 229 229 229 COLOR GRIDMAJOR 209 209 209 ]] #C [[ AUTOSTART GPS 5 ZOOM 32 THUMBNAIL T 98 LINEAR Y Y -10 LOOP 99 HEIGHT 800 ]]

The thumbnail view in LifeViewer is always a quarter of the full size. You can specify the full size with the WIDTH and HEIGHT script commands. I've also posted a slightly different way of animating the Copperhead using a LINEAR waypoint. rowett (talk) 16:49, 14 June 2016 (UTC)

Ah OK, thanks! In that case, could we increase the maximum width/height a bit? As-is, thumbnails can't be larger than 120 pixels wide, and it'd be nice to go up a bit higher than that (e.g., the current static image of copperhead is 161 pixels wide). Nathaniel (talk) 17:03, 14 June 2016 (UTC)

My worry would be that if the thumbnail goes much larger, the full-sized LifeViewer will be much bigger than anyone really wants. These Copperhead thumbnails are already slightly annoying on my laptop screen, because the bottom of the viewer tends to end up scrolled off the screen, and the first click on the frame ends up recentering the LifeViewer instead of interacting with it. As soon as the full-size viewer is taller than the average user's screen, the problems get much worse... What if the thumbnail and full frame sizes were configurable independently, defaulting to quarter-size?

I really like the moving-grid-lines Copperhead! Dvgrn (talk) 17:11, 14 June 2016 (UTC)

The default size of a full-size LifeViewer is 480x480. This can be overridden by the WIDTH and HEIGHT script commands. For width the minimum is 480 and maximum is 1024. For height the minimum is 240 and maximum is 800. With an appropriate meta setting in the webpage LifeViewer is running in you can get it to set its width to the width of the text area containing the pattern rle (this is how it works on the forum) but it will still respect the minimum and maximum width. I'm happy to add a new script command to allow a custom thumbnail divisor to be specified. rowett (talk) 18:22, 14 June 2016 (UTC)

Added a new script command THUMBSIZE to specify the divisor. Value can be 2, 3 or the default 4. An example can be seen here. rowett (talk) 19:02, 14 June 2016 (UTC)

That's perfect, thanks Chris! Nathaniel (talk) 19:05, 14 June 2016 (UTC)

Are these thumbnails going to appear on other pages like they do on the Copperhead page? Because personally I'm not that much of a fan of that. - AwesoMan3000 (talk) 20:09, 14 June 2016 (UTC)

Oh, I like the compact viewers that Dvgrn and rowett embedded above! And I agree with AwesoMan3000, the one currently embedded in Copperhead isn't perfect yet, both due to the lack of gridlines (I just think it's less pretty that way) and the placement.

I'd still prefer to have it embedded in the infobox, either as a (small) viewer or as a link as in the above mock-up. I'd give it a try, but ordinary users lack the ability to fiddle with Javascript on-wiki, of course (and in my case that's probably for the best ;)).

FWIW I think we should continue providing static and animated images in addition to the embedded viewer applet as well; these are very useful to third parties. That said perhaps in a distant future these could be auto-generated from the pattern's RLE snippet as well. Apple Bottom (talk) 11:02, 15 June 2016 (UTC)

Just so that we are all on the same page, here is what I'm currently thinking as far as the infobox/LifeViewer goes (of course feel free to say yay/nay to any/all of this). (1) For users with JS enabled, where the static image currently is displayed, a LifeViewer thumbnail will instead be displayed, in roughly the same size/formatting as the static image. For users without JS enabled, a static image will be displayed instead, just like the current set-up. And of course, for patterns like still lifes, we can just keep using static images period. (2) Clicking on the LifeViewer thumbnail will not "expand" the LifeViewer, but will instead open a LifeViewer overlay that is separate. The advantage of this is that it doesn't expand the infobox (which will look terrible and mess with page formatting) and it is easier to close due to having an X at the top-right. The disadvantage is that I have to poke Chris (thoughts Chris?) on whether this is even possible (and if it *is* possible, whether it's easy to do).

And as a side-note, yes, for security reasons only sysops (i.e., myself, codeholic, dvgrn, and Sokwe) have the ability to insert raw HTML/Javascript into templates, so most of these templates can't be made/altered by others. But once these templates get set-up, regular users will be able to use them just like any other templates. Nathaniel (talk) 12:15, 15 June 2016 (UTC)

How would it discern between JS users and not?

Also, how would it know what RLE to load? Are we going to go ahead with this RLE:patternname namespace thing? And would this override the RLE link in the Pattern files infobox section? - AwesoMan3000 (talk) 12:30, 15 June 2016 (UTC)

There are (relatively straightforward) ways to detect whether or not a browser will display Javascript -- that's something I will take care of on my end, and will just happen automatically as far as users and wiki editors are concerned. The RLE would indeed be loaded from the RLE: namespace. For now, this will *not* override the RLE link in the pattern files infobox section, but once enough RLE codes have been uploaded in the RLE: namespace, that's something we could look at. I suppose one thing I could do is make it so that, if a pattern does not have a proper RLE file, it at least auto-generates a link to its RLE: namespace in the pattern files section of the infobox. Nathaniel (talk) 12:44, 15 June 2016 (UTC)

Added new script command THUMBLAUNCH which changes thumbnail behaviour so when clicked on it Launches the popup viewer rather than Expanding. You can see this working here. Note you may need to refresh your browser. The first thumbnail on the page should say "Launch" when you mouseover. rowett (talk) 14:14, 15 June 2016 (UTC)

You make me so happy Chris. Nathaniel (talk) 15:23, 15 June 2016 (UTC)

I uploaded the newest build of LifeViewer. Unfortunately, the LifeViewer popping out gets stuck behind most of the MediaWiki page (click the following example and scroll to the top of the page to see what I mean). Chris -- is this something you can fix on your end? Nathaniel (talk) 21:25, 15 June 2016 (UTC)

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! #C [[ THEME 6 GRID COLOR GRID 229 229 229 GRIDMAJOR 0 THUMBLAUNCH THUMBSIZE 3 AUTOSTART GPS 5 ZOOM 32 THUMBNAIL T 98 LINEAR Y Y -10 LOOP 99 HEIGHT 800 WIDTH 483 ]]

Yes, fixed in build 191. It just needs some CSS for the title bar. You no longer need to specify THUMBNAIL if you're using THUMBLAUNCH. Also no need to specify the GRID COLOR, it defaults to the correct one when the background is light. Rowett (talk) 05:33, 16 June 2016 (UTC)

Nathaniel -- yes, I agree that for JS users, replacing the current static image with a (thumbnailed) LifeViewer applet is a good idea. I've gone ahead and made a change to Template:Spaceship (which, conveniently, can be edited by trusted users, as opposed to other pattern templates that are fully protected) to handle this.

Copperhead shows this in action. The RLE snippet lives in RLE:copperhead, as discussed above; so far that's a page called "RLE:copperhead" in the Main namespace, rather than a page called "copperhead" in the RLE: namespace. If we decide to add that new namespace and move pages over, Template:Spaceship will require a very minor tweak: the first colon in {{:RLE:{{{pname}}}}} will have to be removed.

If a ship does not have an associated RLE snippet, the static image will be shown in the infobox, as before. This means we can transition spaceship articles at our leisure and convenience.

Embedded LifeViewer applets can be configured using Template:LifeViewer config/spaceship. If a pattern-specific configuration template exists (Template:LifeViewer config/{{{pname}}}), e.g. Template:LifeViewer config/copperhead, that will be used instead. This allows us to have sane defaults while still tweaking individual pages as necessary, all while keeping clutter (LV configuration settings) out of the articles themselves.

Finally I've also modified the infobox so it includes a link to the static image, if one exists.

What's left to do:

1. Tweak the viewer applet so the overlay will be displayed.
2. Handle non-JS users and show them the static image instead of the viewer applet. (I would also suggest including a message along the lines of "Please enable Javascript to see the LifeViewer applet" -- they might not realize they're missing out otherwise!).
3. Do the same work for other pattern templates, notably Template:Oscillator (this one is fully protected, so I can't edit it).

Apple Bottom (talk) 10:05, 16 June 2016 (UTC)

I added one for Loafer, but as you can see it scrolls the wrong way. - AwesoMan3000 (talk) 11:14, 16 June 2016 (UTC)

Adjust Template:LifeViewer config/loafer (based on Template:LifeViewer config/spaceship). Apple Bottom (talk) 11:16, 16 June 2016 (UTC)

What exactly do I have to put in? Like, how do I determine which way it scrolls and how fast? It would be much more convenient "followed" the pattern by default (think there's a button for that). - AwesoMan3000 (talk) 11:19, 16 June 2016 (UTC)

I don't know enough about LifeViewer's configuration parameters (yet) to answer that, but you may want to take a look at the documentation etc. here; there's bound to be some explanation of the parameters somewhere. Otherwise I'd suggest holding off on adding RLE snippets for now. We're in no rush to add these, after all.

I'm furthermore not sure that storing configuration for the viewer in a separate template is actually useful. There are two reasons I did this:

1. Make it possible to have (easily-edited) default parameters if none are specified.
2. Avoid cluttering the RLE itself with viewer configuration comments, seeing as how we might use it for auto-generated downloadable RLE files later.

But perhaps this isn't ideal. We're still in the brainstorming/experimenting phase after all, trying to figure out how to make things work best. So let's finish figuring that out before we do a lot of work that we may later have to undo. ;)

Another tip: the name of the RLE snippet has to match the pname from the spaceship infobox template, so e.g. Lobster's snippet should be at RLE:83p7h1v1, not RLE:lobster. Apple Bottom (talk) 11:23, 16 June 2016 (UTC)

The only documentation currently available is in LifeViewer itself, press Help and then scroll down to the Commands section. Here's a brief explanation of the commands used for the Copperhead animation:

THEME 6 GRID COLOR GRID 229 229 229 GRIDMAJOR 0 THUMBLAUNCH THUMBSIZE 3 AUTOSTART GPS 5 ZOOM 32 THUMBNAIL T 98 LINEAR Y Y 10 LOOP 99 HEIGHT 800 WIDTH 483

• THEME 6 - sets a colour theme (black on white background)
• GRID - switches on the grid display
• GRID COLOR 229 229 229 - sets the RGB value for the grid lines (no longer needed since light background themes now use this grid colour)
• GRIDMAJOR 0 - disables major gridlines
• THUMBLAUNCH - tells LifeViewer to start as a thumbnail and launch the popup viewer when clicked
• THUMBSIZE 3 - defines the size divisor for the thumbnail
• AUTOSTART - tells LifeViewer to start playback automatically
• GPS 5 - defines the number of generations per second for playback
• ZOOM 32 - defines the camera zoom
• THUMBNAIL - tells LifeViewer to start as a thumbnail and expand inline when clicked (not needed when THUMBLAUNCH used)
• T 98 - defines a waypoint at generation 98, any of X, Y, ANGLE and ZOOM commands following define the target
• LINEAR Y - tells LifeViewer to use Linear (rather than the default Bezier) interpolation for the camera for this (and future waypoints) for just the Y axis (could also specify Y, ZOOM or ALL here)
• Y 10 - defines the waypoint target Y coordinate
• LOOP 99 - tells LifeViewer to reset back to generation 0 when it gets to generation 99
• HEIGHT and WIDTH - sets the size of the full size LifeViewer, does not change the popup viewer which is fixed size

So in this case the camera moves from X = 0, Y = 0 (the default reset position) to X = 0, Y = 10 by generation 98 and then loops. If you wanted to go right to left you'd use LINEAR X and then set some X value. Diagonally you'd probably use LINEAR ALL and set both X and Y. You can also specify multiple waypoints by using the T command more than once. Additionally if you want the camera to pause for a time at the current position you can use the PAUSE command. More commands in the built-in help. Check out this example. Rowett (talk) 11:55, 16 June 2016 (UTC)

Hah, excellent example! I didn't know LifeViewer was so advanced, that's awesome! And thanks for the explanation of the commands. Sounds like we need to add Help:LifeViewer or so to our documentation. Apple Bottom (talk) 12:13, 16 June 2016 (UTC)

I have now added the non-Javascript functionality so that a pattern's static image is instead displayed for users who have Javascript disabled. Note that if you manually disable Javascript in Chrome, you will need to refresh the page about 2 times before things display properly (this is a bug in Chrome and unfortunately there's nothing I can do about it). Nathaniel (talk) 13:11, 16 June 2016 (UTC)

Two other waypoint examples can be seen here and here. Rowett (talk) 13:15, 16 June 2016 (UTC)

Nathaniel you'll need to not only style the title bar of the popup viewer but also adjust some of the other portlets which use z-index (specifically p-personal (the top menu) and p-search (the left search box)). They both have a z-index 3 style set which means the popup viewer floats under them not above. I removed their z-index on a local test page and it doesn't appear to have broken anything else. Rowett (talk) 15:23, 16 June 2016 (UTC)

I've removed z-index:3 from those two menus like you suggested. I'm being dense though -- what CSS needs to be added to the title bar of the popup viewer? Nathaniel (talk) 18:56, 16 June 2016 (UTC)

You may notice on this page the popup has a transparent background to the LifeViewer title bar. Also on the Copperhead page the popup has a title bar that's about 1 pixel high. These are both caused because on the forum LifeViewer inherits styling for the title from the forum CSS (which doesn't exist here). I've created build 192 which may fix the problem. Rowett (talk) 19:14, 16 June 2016 (UTC)

Works perfectly now, thanks! Nathaniel (talk) 19:46, 16 June 2016 (UTC)

Excellent, thanks for unprotecting Template:Oscillator, Nathaniel. I've updated it and successfully used it on Pentadecathlon, so now oscillators can have embedded LifeViewers as well. Apple Bottom (talk) 16:55, 16 June 2016 (UTC)

Thanks. I've tweaked the templates so that Template:LifeViewer_config/oscillator now contains general parameters that should be used for *all* oscillators (e.g., grid color) and Template:LifeViewer_config/pentadecathlon contains only those parameters specific to that oscillator (e.g., width/height/generations per second). In fact, what would you think about taking the information in Template:LifeViewer_config/pentadecathlon and just plopping it into another parameter in the Oscillator template? That seems like a less confusion set-up to me, and that way we don't need to create two pages for every new oscillator. Nathaniel (talk) 17:45, 16 June 2016 (UTC)

Sounds good to me; and it'll certainly make it easier for new contributors to find where those settings are tweaked. A new viewerconfig parameter, then?

Speaking of which, I've also cleaned up the way the infobox template is included in Pentadecathlon for the sake of readability, BTW. The same should eventually be done for other pages as well. I'll add it to my ever-growing lists of tasks. :P

And of course should modify Template:Spaceship as well once we're happy with Template:Oscillator then. And of course guns and other such patterns could get a LifeViewer, too (Template:Stillife probably doesn't need it). Apple Bottom (talk) 18:25, 16 June 2016 (UTC)

Thanks for cleaning up the infobox template -- I agree that it should be done on other pages too. I've added the viewerconfig parameter to the Oscillator template, and implemented it on the pentadecathlon page, and I quite like it this way. If other folks like it too, we can start rolling out these changes to other templates (Spaceships, Guns, etc) like you mentioned. Nathaniel (talk) 18:40, 16 June 2016 (UTC)

With the new build of LifeViewer there is no need to use the THUMBNAIL or COLOR GRID 229 229 229 commands. They're redundant and should be removed from templates. Rowett (talk) 19:21, 16 June 2016 (UTC)

Done, thanks! Nathaniel (talk) 19:46, 16 June 2016 (UTC)

Sounds good to me! If everyone else is in favor, I'd say let's go. Apple Bottom (talk) 21:55, 16 June 2016 (UTC)

Addendum -- I've finished cleaning up the pattern infobox transclusions on all pattern pages (i.e. all pages in Category:Patterns). Apologies for the barrage of edits. Apple Bottom (talk) 18:32, 19 June 2016 (UTC)

Hi, I have come to report that the viewer window glitches when using different skins for the Wiki. I found this when studying the copperhead page but the situation is probably similar for others.

• Under the skins Cologne Blue and Vector (which is my preset), the window cannot be dragged or closed unless one scrolls down.
• Under the skin Modern, the window seems fully functional but can be dragged under the blue bar at the top of the screen.

Can someone please fix this? Gameoflifeboy 03:03, 17 June 2016 (UTC)

Thanks for letting me know. I believe this is now fixed in all skins. Nathaniel (talk) 12:36, 17 June 2016 (UTC)

If a page has an RLE: page but no official RLE pattern file, it now at least displays a link to the raw RLE code in the pattern files section. See P32 blinker hassler for an example. Nathaniel (talk) 11:50, 18 June 2016 (UTC)

A reboot on the topic of category config pages and pattern-specific config pages: I've tried removing the copperhead-specific spaceship-following viewer tags from LifeViewer_config:spaceship, and adding them to LifeViewer_config:copperhead. It definitely has an effect, but it's not the right effect -- see the current Copperhead page, where the theme and other tags are no longer being applied. It seems as if the existence of a pattern-specific LifeViewer:pname page breaks the tag-parsing system (i.e., keeps the viewer from applying tags).

4bobo$2o2bobo$2o3bobo$2o$2bo5bo2$5b2obo$5b2o$5bo2bo$6b2o! #C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH THUMBSIZE 3 AUTOSTART GPS 5 HEIGHT 800 WIDTH 483 ]] #C [[ ZOOM 32 T 700 LINEAR X X -100 LOOP 700 ]]

Another example to look at: here's how I think maybe the Infobox loafer might look. General infobox tags are on the first comment line, and loafer-specific tags are on the second line.

But if I try creating any LifeViewer_config:loafer page, even a blank one, then tags seem to stop being applied in the loafer infobox's viewer. (?)

I kind of like the idea of these LifeViewer config pages, and kind of don't like them -- seems like the LifeViewer_config:spaceship one might make sense... or maybe it should just be for LifeViewer_config:pattern? ... but I'd rather have the pattern-specific tags right in the Infobox section of the pattern page, somehow, where I can get at them without having to create a whole new config page for every pattern. Dvgrn (talk) 17:50, 18 June 2016 (UTC)

3o$o$bo! #C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH THUMBSIZE 3 AUTOSTART GPS 4 HEIGHT 320 AUTOFIT ]]

31b3o24b$32bo25b$32bo2bo22b$32bo2bo22b$33bobo22b$48b2o8b$48b2o8b3$32bo 25b$31bobo24b$32bo25b$49bo8b$48bo7b2o$30b4o22b2o$30b2o3bo10bo11b$31bo 4bo9bobo9b$33bob2o10bo10b$34bo23b3$42bobob2o10b$25bo16bobo13b$24b3o17b o2bo10b$43bo3bo10b$24b3o16b4o2b2o7b$25b2ob2o14bo5b2o6b$27bo21bo8b3$b3o 54b$2bo55b$2bo2bo52b$2bo2bo52b$3bobo52b$18b2o38b$18b2o38b$24bo33b$23b 3o32b$2bo19b2ob2o31b$bobo18bobo33b$2bo19bo35b3$4o54b$2o3bo13bo38b$bo4b o11bobo37b$3bob2o11bo39b$4bo15b2o36b$21bo36b$18b3o37b$19b2o37b$16bo41b $16b2o40b$16b2o40b$6b2o6b2o42b$6b2o4b2o44b$12b2obo42b$14b2o42b5$14b2o 42b$14b2o! #C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH THUMBSIZE 3 AUTOSTART GPS 60 HEIGHT 320 AUTOFIT ]]

AwesoMan3000 mentioned LifeViewer's AutoFit functionality above, as a possible alternative way of automatically following a spaceship without having to set up a waypoint and use the LINEAR tag and so forth. I experimented with this a few days ago, and I think it would currently be in danger of inducing mild nausea, even for a simple low-period monotonic spaceship such as a glider... for non-monotonic spaceships it can get really strange. Click on the Cordership at the right here for a fairly wild ride.

That said, maybe there's a way to add an optional AutoFit parameter, or a different kind of autofit (AUTOTRACK?) to do something a little bit smarter. The most workable thing I can think of would be to check if the pattern is the same at the end of a LOOP N cycle as it was at the beginning, and if so, set up a LINEAR waypoint automatically from the T=0 pattern center to the T=N center... so the viewer wouldn't track the pattern for the first cycle, but then it could maybe catch up smoothly and follow it from there. Dvgrn (talk) 18:56, 18 June 2016 (UTC)

Not sure I fancy the AUTO part of AUTOTRACK. Perhaps a command TRACK <period> <x offset> <y offset> which would (under the covers) generate the appropriate Waypoint script commands. For Copperhead you'd use TRACK 10 0 1, Loafer TRACK 7 1 0 and Glider TRACK 4 1 1. Rowett (talk) 22:20, 18 June 2016 (UTC)

I like the sound of TRACK N XVAL YVAL. It's not really necessary, since it could just be syntactic sugar for something that's only slightly more complicated -- T N*10 LINEAR [X|Y|ALL] [X XVAL*10] [Y YVAL*10] LOOP N*10 -- but I think a moving viewport is a fairly common thing to want to set up, so it would be nice to make it as simple as possible. Might there be a way to set up a moving viewport without any periodic reset? Dvgrn (talk) 00:20, 19 June 2016 (UTC)

Yes it's just syntactic sugar but probably worth it for something fairly common as you said. It would also automatically do the GRIDMAJOR calculation (if specified) i.e. GRIDMAJOR M TRACK N XVAL YVAL would generate GRIDMAJOR M T N*M LINEAR [X|Y|ALL] [X XVAL*M] [Y YVAL*M] LOOP N*M (assuming M > 0).

What's the issue with periodic reset (just flicker, which was fixed today, or something else)? Rowett (talk) 05:58, 19 June 2016 (UTC)

I've implemented TRACK N XVAL YVAL and examples can be seen here. Rowett (talk) 07:21, 19 June 2016 (UTC)

I can't advance the pattern generation-by-generation with the TRACK settings applied. Instead, going forward one step advances the frame as dictated by the TRACK settings.
~Sokwe 10:40, 19 June 2016 (UTC)

In TRACK/Waypoint mode the step forward feature moves the pattern forward at the rate defined by GPS (rather than generation by generation). To step forward a generation at a time either Reset once (which will disable TRACK/Waypoint mode) or use hotkey "w", which toggles TRACK/Waypoint mode. A second Reset while at T=0 will perform a full Reset (and restart Waypoints etc.). Rowett (talk) 11:06, 19 June 2016 (UTC)

I've made it so that generic config options (like the grid colors) are in Template:LifeViewer_config/spaceship, but Template:LifeViewer_config/copperhead is no longer used. Instead, the template on the copperhead page itself (and all spaceship pages) has a "viewerconfig" parameter that can be populated with additional options. See the copperhead page's code to see how this works now. Let me know if this works OK for you. Nathaniel (talk) 19:41, 18 June 2016 (UTC)

Viewer configuration appears to be broken now; see e.g. Loafer (does not track the ship anymore) or Mangled 1 beacon (oscillates at 60 GPS instead of 5). Apple Bottom (talk) 10:47, 19 June 2016 (UTC)

The viewerconfig parameter is sensitive to spacing -- see the fix that I just made to the loafer page. Nathaniel (talk) 12:56, 19 June 2016 (UTC)

Ah, good to know (and thanks for fixing these). Question: given the potential for confusion there, and since viewerconfig is inevitably going to be wrapped in #C[[ ... ]] anyway, should we move the comment wrapper into the pattern templates so that the configuration would instead be specified as just e.g. (using Loafer as an example) "ZOOM 32 T 700 LINEAR X X 100 10 LOOP 700 GPS 5 HEIGHT 400 WIDTH 400"? Or are there use cases where having full control over what's passed to LifeViewer would be useful/necessary? Looking at complicated examples such as the Waypoints one Chris mentioned above, it looks like the entire configuration script's still wrapped. Apple Bottom (talk) 13:14, 19 June 2016 (UTC)

There's an extra "10" in the Loafer script command list which needs removing: "ZOOM 32 T 700 LINEAR X X 100 10 LOOP 700 GPS 5 HEIGHT 400 WIDTH 400". LifeViewer actually complains about it but you can't see the error until you launch the full size popup viewer. Additionally the script can now be rewritten using the new TRACK command: "ZOOM 32 TRACK 7 1 0 GPS 5 HEIGHT 400 WIDTH 400". Rowett (talk) 13:24, 19 June 2016 (UTC)

Incorporated, thanks! Apple Bottom (talk) 13:31, 19 June 2016 (UTC)

LifeViewer looks for script commands in pattern comments (for rle format files this is lines beginning with #C or any text after the ! terminator). To be recognized the commands must be separated by whitespace and enclosed by [[ and ]]. You can either have all commands wrapped together [[ AUTOSTART ZOOM 32 GPS 5 ]] or you can wrap separately [[ AUTOSTART ]] [[ ZOOM 32 GPS 5 ]]. Rowett (talk) 20:53, 22 June 2016 (UTC)

Just a small FYI/reminder for everyone: as soon as the LifeViewer version on the LifeWiki is updated past the current build 195, existing TRACK and waypoint coordinates will have to be negated, in any scripts where they're used -- e.g., TRACK 7 -1 0 instead of TRACK 7 1 0, above. It seemed a little odd that TRACK had to be told where the pattern should move to, whereas everything else was defined in terms of where the camera position. Sooner is probably a better time than later, to make that more consistent... Dvgrn (talk) 15:27, 29 June 2016 (UTC)

Whoops, sorry for the delay. Build 199 is now live on the wiki. Nathaniel (talk) 23:55, 29 June 2016 (UTC)

Something's wrong. Viewers using TRACK (such as the Loafer's don't move the camera anymore. Viewers using the older config (such as Copperhead's) still work. Apple Bottom (talk) 09:27, 30 June 2016 (UTC)

OK so that build escaped before I had a chance to give instructions for the changes that need to be made to the templates here. The TRACK command has changed to TRACKLOOP, and the way you specify the X and Y speeds has also changed. TRACKLOOP P X Y takes the loop period, P, and then the velocity in the X and Y directions in cells/generation. The coordinate system changed so negative values are now up and left.

For the Copperhead this means that the original TRACK 10 0 1 command needs to become TRACKLOOP 10 0 -1/10 (or TRACKLOOP 10 0 -0.1 if you prefer). I've made this change to the Copperhead page. Similar changes will need to be made to other places that use TRACK.Rowett (talk) 12:04, 30 June 2016 (UTC)

I experimentally fixed Loafer and 31P8H4V0 and a few others, just now. The TRACKLOOP tracking works fine -- just needs dt, dx, and dy, in the standard Golly coordinate system now. There's a new zoom-related bug in LifeViewer Build 199, which should be fixed in Build 200, which with any luck will show up on the Wiki fairly soon (hours or days). Patience is advised... we can probably hold off on fixing the rest of the pages that link to LV:Viewer until it's clear that the viewer thumbnail is looking right when we're done. Dvgrn (talk) 14:27, 30 June 2016 (UTC)

Nathaniel please upload build 200 when you get a moment. Note that in this new build there should be no need to specify ZOOM (and in most cases HEIGHT) commands in your templates since AutoFit will take care of this. Rowett (talk) 16:48, 30 June 2016 (UTC)

Build 200 is now live on the Wiki. You may need to refresh your browser to see it. Release notes can be found here. Rowett (talk) 21:37, 30 June 2016 (UTC)

Excellent, thanks everyone! Apple Bottom (talk) 10:04, 1 July 2016 (UTC)

Tracking should be fixed for all Infobox viewers now. If you see any exceptions... well, just go ahead and fix them! Some of the Cordership views can possibly be improved with some future build of LifeViewer, if there's a way to get the (currently automatically set) ZOOM level under better control, and/or allow for a wider viewer frame in the Infobox. Currently some HEIGHT and WIDTH settings seem to be ignored -- besides any WIDTH<480 or HEIGHT<240 settings, which are below LifeViewer's minimium settings so are ignored for that reason.

I changed RLE:coeship to a different phase, so that the whole trailing spark is always visible; there might be a few other high-period ships where that workaround could be used. Dvgrn (talk) 14:30, 1 July 2016 (UTC)

BTW, I'd like to repropose that we introduce a new namespace (in the technical sense) for RLE: pages, the reason being that so long as they're part of the Main namespace, they'll turn up as random pages, among other things.

Obviously this can only be done by a site administrator who's got access to the server config (just Nathaniel, I presume). Documentation for adding namespaces is here on mediawiki.org.

If we decide to do this we'll have to move the existing RLE pages over; there's quite a few already, so the best bet would be to automate the task; MediaWiki includes a maintenance script to help with this. We'd also have to make very minor edits to Template:Oscillator and Template:Spaceship (basically, remove a colon from each to transclude the page from the correct namespace), but that's all.

Just bringing this up again because I noticed looking at random pages brought up a lot of RLE: ones. Apple Bottom (talk) 23:51, 3 July 2016 (UTC)

Thanks for bringing this up again. I'll create the namespace soon -- unfortunately I'm on vacation with terrible internet right now though so FTP access and whatnot is pretty painful. Nathaniel (talk) 01:06, 4 July 2016 (UTC)

Along with this, it would be nice to be able to auto-generate real RLE files from the RLE pages... maybe with some kind of minor security system, so that someone can't easily come along and replace every object's RLE with 28bo$28bo$4o2bo3bob4o3b3o3b4o$o3bobo3bobo3bobo3bobo3bo$o3bobobobobo3bob5obo3bo$o3bob2ob2obo3bobo5bo3bo$4o2bo3bobo3bo2b4o2b4o$o$o! or something, and have it show up in the Infobox viewer, or replace perfectly good commented RLE files that have already been uploaded. Allow raw RLE to be created, but then lock it once it's been confirmed to be the correct pattern, and auto-generate full RLE files whenever the locking happens? Something like that.

I also wondered whether it might work to have the RLE and glider-synthesis links in the Infobox open a page with a Select All codebox and a viewer, along the same lines as on the forums -- instead of just a plain-text view of the RLE file. Dvgrn (talk) 03:05, 4 July 2016 (UTC)

I especially want to see RLE as a seperate namespace, since you can't search contributions/recent changes for "new pages"-type filters without RLE: pages pouring out of the screen. - AwesoMan3000 (talk) 09:33, 4 July 2016 (UTC)

Dave -- Displaying RLE and synthesis RLE as in the forums sounds like an excellent idea as well. And mass-importing existing RLE files should be easy to do with a shell script — though some manual tweaks may still be needed for e.g. spaceships with large tail sparks. And I agree with muzik that per-namespace filtering of edits would be another perk of a dedicated namespace.

MediaWiki has some support for per-namespace permissions, BTW, so it would be easy to only allow e.g. trusted users to edit pages in the RLE: namespace. Alternatively sysops could of course simply look over each new RLE page (perhaps using Special:NewPages to monitor activity in this namespace) and lock the ones that are done, fully or to trusted users. Apple Bottom (talk) 09:44, 4 July 2016 (UTC)

Nathaniel please will you upload build 206 when you get a moment. Rowett (talk) 19:39, 13 July 2016 (UTC)

The RLE namespace is now a real namespace, and I have moved the pages over. Nathaniel (talk) 14:17, 21 July 2016 (UTC)

Excellent, thanks for handling this! Apple Bottom (talk) 11:12, 22 July 2016 (UTC)

Thanks Nathaniel!

Build 206 is now live on the Wiki. You may need to refresh your browser to see it. Release notes can be found here. Rowett (talk) 13:44, 14 July 2016 (UTC)

Nathaniel to remove the "Script error" messages and to allow wider LifeViewers please can you add the following to the <head> section of the Wiki pages: <meta name="LifeViewer" content="rle code"> Rowett (talk) 15:48, 14 July 2016 (UTC)

Done, thanks. Nathaniel (talk) 16:07, 14 July 2016 (UTC)

Nathaniel please will you upload build 207 when you get a moment. Sorry for the quick update but a bug escaped. Rowett (talk) 18:27, 14 July 2016 (UTC)

207's uploaded, script errors persist. Looks like LV:Viewer still needs to be updated? Apple Bottom (talk) 11:54, 15 July 2016 (UTC)

Script errors are because those patterns have scripts containing [[ WIDTH ]] script commands with values of < 480 (which is the minimum width for a non-thumbnail LifeViewer). So those WIDTH commands need changing or removing (in which case it will default to 480 pixels width). Then the [[ THUMBNAIL ]] or [[ THUMBLAUNCH ]] commands can be used along with [[ THUMBSIZE ]] to specify how small to make the Thumbnail.

For example the two viewers on this page with Script Errors both have [[ WIDTH 320 ]] defined. Rowett (talk) 14:31, 15 July 2016 (UTC)

What about a LifeViewer for still lifes? -wwei23 7:05PM 5/29/2017 NY time

The moon and LifeWiki's mission

It was observed on the ConwayLife.com forums that the moon (a photon in various B2 rules such as Seeds and Live Free or Die) has an article on here despite not actually being a spaceship (or indeed any notable pattern) in Conway Life.

What do we do with this article, then? I'll copy my comments from the forum below for discussion:

Right now the wiki is serving two purposes. One, it's a general resource of information about cellular automata, especially Life-like cellular automata. And two, it's a pattern collection for Conway Life specifically.

There are no hard and fast rules, but unless and until we want to change this, I'd say we should not add articles for patterns that only exist outside of Conway Life. For example, I agree that an article on the bomber, notable as it may otherwise be, does not belong on the LifeWiki in its current form.

However, that doesn't mean we can't have information on these patterns at all. For example it would be perfectly fine to have an article on HighLife (in fact, we do), and have a section on the bomber in that article (in fact, we do). A "Spaceships in HighLife" page would be fine, as that page would clearly pertain to HighLife rather than life, and its contents would not get mixed with information on Life's patterns in the pattern category.

Adding "in other rules" sections to articles on Life patterns would also be fine, of course.

The moon, meanwhile -- well, we don't talk about the moon. Ixnay on the oonmay! ;) Jokes aside, it's an article that probably shouldn't exist in its current form but has sort of been grandfathered in. If it only appeared in a single (notable) rule I'd move it to a section of that one's article -- but it's in at least two important ones, Seeds and Live Free or Die, so I'm not sure how to proceed. For now I don't think it's important enough to really worry about, but I'll start a Tiki bar discussion on the wiki.

TL;DR -- I don't want to change LifeWiki's mission, it's fine as it is for the time being. Patterns from other cellular automata should not have patterns, unless they are interesting patterns in Conway Life as well. As such the moon should (probably) not have an article, but I don't know where its article's contents should be moved.

Thoughts? Apple Bottom (talk) 12:10, 16 June 2016 (UTC)

If we're going with the "In other rules" section in more pages, seems like the best idea is merging it with Grin. - AwesoMan3000 (talk) 12:18, 16 June 2016 (UTC)

I agree with merging it with grin. In general, in cases like there where a pattern behaves differently in different rules, the Conway page should be the "main" article, with a subsection describing how it behaves in the other rule. If it is not notable in Conway's Life, then I have no objection to it getting its own page, with two caveats: (1) There should be enough information about it to really warrant its own page --- some patterns like the HighLife replicator can probably have entire articles written about them, but we likely don't need a page for every spaceship in every rule. (2) Since the focus is on Conway's Life, I'd like non-Conway patterns to be *very* clearly marked as non-Conway patterns. I'm thinking that they should all say the name of the rule in the page's title (so a pattern's title might be "Bomber_(HighLife)" or "Moon_(Seeds)" or something like that. Nathaniel (talk) 12:40, 16 June 2016 (UTC)

I don't like the idea of slapping the rule name on the page title, unless it has similarly named patterns or concepts, etc in other rules. So Bomber (HighLife) seems like a good idea as to not get mixed up with the glider gun from normal Life, but something like Puddle jumper (DryLife) is kind of unneccesary if there is no pattern named Puddle jumper in normal Life. If anything, we should add the rule name into the introduction of the article, like "Puddle jumper is a 9c/28 orthogonal spaceship in the cellular automaton DryLife." - AwesoMan3000 (talk) 12:54, 16 June 2016 (UTC)

I'm in favor of adding an indication of the rule(s) a non-Life pattern runs in to the page title, myself. It may be superfluous in the article itself, but it'll make it MUCH easier to pick out these patterns in pattern categories such as Category:Spaceships -- seeing "Bomber (HighLife)" there will make it that much clearer that the bomber isn't a spaceship in Conway Life.

Of course that's assuming we want to use the usual pattern categories for non-Life patterns in the first place. Do we? I'd honestly prefer not to; and while maintaining a separate category hierarchy for each rule would be unwieldy, we could have a second one for non-Life rules. The bomber would then be placed in (say) Category:Spaceships (non-Life) or so; same for other patterns such as still lifes, oscillators etc. Category placement could be controlled by an extra infobox parameter, defaulting to using the regular categories (so existing articles on Life patterns would not need to be changed).

Apple Bottom (talk) 16:28, 16 June 2016 (UTC)

You mean that it would check the "Rules" bit in the infobox, and if the important rule isn't Conway Life it would get added to the non-Life category? - AwesoMan3000 (talk) 15:32, 17 June 2016 (UTC)

That would be even better, but a bit more advanced. As a first approach I was merely thinking of something like life=true (default) / life=false (with a better name for the parameter). Patterns with life=false would then not get added to the usual category tree.

Of course there's still issues. For instance a pattern might be an oscillator in one rule, a spaceship in another, and a still life in a third; I don't think it'd be right to add three infoboxes (two of them specifying life=false) to the article then. But as long as we limit ourselves to highly notable patterns such as the HighLife Bomber and don't try to provide a comprehensive repository of all notable patterns in non-Life rules, I think this shouldn't matter in practice.

TL;DR -- as far as patterns go I feel we should focus primarily on Conway Life in this wiki for now, but the occasional article on highly notable non-Life patterns won't kill us and may well add value, so long as we don't lose sight of our primary focus. Apple Bottom (talk) 16:15, 17 June 2016 (UTC)

So, what exactly are the most notable non-Life patterns? To me, the first thing that comes to mind is the HighLife replicator. Can anyone think of any other non-Life patterns of significant notability? How many such patterns could we potentially justify pattern pages for?
~Sokwe 01:26, 18 June 2016 (UTC)

Probably the bomber and the c/98 from HighLife, and the 9c/28 from DryLife. - AwesoMan3000 (talk) 08:24, 18 June 2016 (UTC)

My gut feeling is that the bomber at least is probably notable enough to have an article. The other two ships that AwesoMan3000 mentions I don't know about, I'm simply not familiar enough with HighLife or DryLife to say one way or another. Based on David Bell's 1997 paper on Day & Night the Rocket (that's this xq40) from that rule is also notable enough.

But it's a judgement call. To establish a pattern's notability for the purpose of an article in the LifeWiki, do we look at that pattern's importance within the rule it appears in, or within the wider context of Life-like cellular automata? The former's tempting, but the rules the patterns stem from themselves might not be important. The latter, meanwhile, might exclude some patterns unnecessarily.

So I'd say "very important patterns in important rules", perhaps (still a judgement call, of course). How does that sound? Apple Bottom (talk) 09:33, 18 June 2016 (UTC)

Since this is the LifeWiki, I was more thinking of Conway's Game of Life, and rules which are similar to it. So HighLife, DryLife, possibly tlife, etc. Other notable rules could be mentioned here and there.

Here's the 9c/28: http://www.conwaylife.com/forums/viewtopic.php?f=11&t=490&p=3326&hilit=Drylife#p3239

and c/98: (I mean, you posted in the thread so you should know about it?) http://www.conwaylife.com/forums/viewtopic.php?f=11&t=1612#p16741 — Preceding unsigned comment added by AwesoMan3000 (talk • contribs) 10:10, 18 June 2016 (UTC)

I shoot from the hip and then promptly forget what I said. :P I'm not actually very smart, all things considered.

Outside of that -- I don't think there's really a meaningful difference between rules that are "similar" to Conway Life and ones that aren't. They're all Life-like cellular automata, after all; on the other hand even rules that share some patterns with Life (such as HighLife) still differ substantially from it. Apple Bottom (talk) 22:57, 18 June 2016 (UTC)

I personally don't see why these patterns need their own pages. The 9c/28 "puddle jumper" and its relatives could easily be included in a DryLife page. The c/98 HighLife ship could be covered with an external link to the forums. I think the bomber section on the HighLife page is sufficient for that pattern.

As I see it, there are two main problems with adding non-Life pattern pages. The first problem is that we don't really have criteria to establish the notability of patterns in other rules. There's often disagreements over the notability of Life patterns, and non-Life patterns add the extra complexity of rule notability. The second problem is that we will need to find a way to clearly separate Life patterns from non-Life patterns. I don't want the bomber to show up in Category:Spaceships with speed c/6, nor do I want categories like Category:Spaceships with speed c/98, as they could cause confusion with what is known in Life.

I personally support a ban on all non-Life pattern pages. The added difficulties and potential problems of non-Life pattern pages don't seem to be worth it when we aren't likely to add more than 10 such pages.
~Sokwe 05:49, 19 June 2016 (UTC)

Okay, no specific pattern pages. What about another approach; clicking on a link for a "non-notable" pattern shows it in LifeViewer?

It might be a bit alarming to not know which ones pop up in the viewer or not, so I propose that links that open LifeViewer are green or something, except that would probably be a lot of work to create.

For example, clicking on the link for the c/98 ship on HighLife's elemental spaceship section would open up LifeViewer, so we would get to see the ship. - AwesoMan3000 (talk) 11:53, 24 June 2016 (UTC)

I don't see anything wrong with using the viewer to display these patterns, e.g. on pages such as Spaceships in HighLife or HighLife#Spaceships or so. Remember you can just inline viewers using LV:Viewer, too.

Use of the standard infobox templates should still be avoided for now, so in order to not put non-Life patterns into the pattern categories at the very least. In the long run, detailed information on patterns from non-Life rules is likely better off in dedicated wikis anyway, though I personally think general information and "overview"-style articles are fine here. Apple Bottom (talk) 11:58, 24 June 2016 (UTC)

FWIW, since the Moon is now mentioned as a B2-photon on Grin, I've turned its page into a redirect to the latter article. Apple Bottom (talk) 22:31, 24 June 2016 (UTC)

Pattern naming

I've taken the article on Unnamed patterns and extended it into a general explanation of Pattern naming. However:

1. I don't know how to write beautiful prose; and
2. I'm still hopelessly confused about the various prefixes (ortho-, meta- etc.).

So therefore it would be great if others could go over it and clarify/expand/edit/fix it as necessary. Thanks! Apple Bottom (talk) 11:22, 20 June 2016 (UTC)

Macrocell/RLE files for large spaceships

Macrocell/RLE files for various large spaceships have been uploaded to the RLE: namespace recently, including at least the following:

1. RLE:linearpropagator-mc (89 KB)
2. RLE:gemini-mc (1.7 MB)
3. RLE:gemini2-mc (1.0 MB)
4. RLE:gemini3-mc (1.2 MB)
5. RLE:demonoid-10hd-rle (254 KB)
6. RLE:halfbakedknightship-mc (131 KB)

If there's a point to this I'm not seeing it. The LifeViewer plugin won't handle these, and embedding these huge ships in a viewer in articles wouldn't make much sense anyway. (Just imagine someone looking up a ship on their mobile device and being handed a multi-megabyte file that the viewer plugin would then try to animate.)

Thoughts? Apple Bottom (talk) 12:05, 15 July 2016 (UTC)

• Ironically, these are technically aimed at mobile users - I've stated before on the forums that it's not possible to select long text files as the raw text format. However, this is possible in the wiki editor's raw text editor.

• Of course, the viewer won't be able to load them, so I moved them to different file names so the viewer wouldn'r be able to find them. (but can we maybe get gifs for them?) - AwesoMan3000 (talk) 12:23, 15 July 2016 (UTC)

I'm not sure why you'd want a multi-megabyte pattern file on your phone, but sure, I'll take your word that it's useful.

As for GIFs, if you want them you'll have to generate these yourself. Just for fun I created a static PNG of the complete Caterpillar at a scale of 1:1. :P

$ ls -l caterpillar.png
-rwxr-xr-x+ 1 User None 11004191 Jul 15 17:45 caterpillar.png
$ file caterpillar.png
caterpillar.png: PNG image data, 4197 x 330723, 2-bit colormap, non-interlaced
$

As you can see the resulting file's surprisingly small at 11 MB, but can't be opened in e.g. GIMP because it's too big (GIMP apparently uses 16-bit integers for an image's width/height). I've not tried uploading it to the wiki; I'm not aware of any specific restrictions that would make this impossible, but I don't see the point, and I believe thumbnail generation etc. wouldn't work.

An animated GIF, meanwhile, would

1. be much larger. The Caterpillar's got a period of 270, so there'd have to be that many frames to the animation; GIF compression is also inferior compared to PNG compression, though this may be offset partially or completely by the fact you'd only need to compress a delta for each frame. Still I'd expect a filesize on the order of a gigabyte at least.
2. take much longer to generate. I didn't actually check how long the PNG took, but it was a fair while.
3. be largely useless. For ships like these videos are a much better choice.

So don't look at me -- but if you want to create an animated GIF for any (or all of these) yourself, by all means knock yourself out, stud. Apple Bottom (talk) 21:23, 15 July 2016 (UTC)

For obvious reasons, I don't think that one frame for every generation would be a good idea, especially for geminoids spaceships. - AwesoMan3000 (talk) 22:09, 15 July 2016 (UTC)

More Infobox parameter

Here are three I kind of want:

• mod = Shows the mod for the pattern
• noviewer = If false, then LifeViewer will not appear in the infobox. Good temporary fix for pages I messed up, like waterbear.
• rlelink = Specifies a different link to a page in the RLE:namespace, so I can perhaps link to RLE:waterbear-rle without having to change the name of the pattern within the infobox and screw up LifeViewer even more.

- AwesoMan3000 (talk) 20:25, 17 July 2016 (UTC)

Another few:

• systematicname = Shows the systematic naming code for the pattern
• apgcode = The pattern's apgcode

So in the case of copperhead:

• Mod = 10
• Systematic name = 28P10H1V0
• apgcode: xq10_o5995ozes88sezw33

Where those last two would be located in the onto box I do not know. Mod would be directly under period, and the result of rlelink would of course replace the "raw RLE code" link.

- AwesoMan3000 (talk) 21:02, 22 July 2016 (UTC)

I'm not sure putting the apgcode in the infobox is a good idea. I considered this back in spring, but ultimately ended up creating Template:LinkCatagolue instead. There's several reasons for this.

1. First of all, apgcodes are primarily used on Catagolue so far; they haven't (yet) caught on as general descriptors. As such it makes sense to use them in the External Links section, to link to Catagolue specifically.
2. Second, apgcodes can grow without bounds. Gliders, beehives, blinkers etc. have short codes that are easily memorized; larger objects (say, 112P51) do not. Overly long codes would break the infobox layout when they're displayed.
3. Third, apgcodes are generally more suitable for consumption by machines than humans. Longer codes in particular can be confusingly similar despite encoding different objects (contrast e.g. xp30_w33z8kqrqk8zzzx33 and xp30_w33z8kqrqk8zzzw33, the trans- and cis-queen bee shuttles).

Conversely, I don't see any advantages to adding apgcodes to the infoboxes for the time being.

One thing I'd like to do in the medium to long term is tweak the infobox templates to produce machine-parseable data describing patterns in a suitable microformat in addition to displaying a human-readable infobox; for this, apgcodes would then be useful to add (and you'd have the template add them to the machine-parseable data without displaying them in the infobox proper). But that's neither here nor there, and we'd need to lay the foundations before devoting time to implementation details: develop an ontology and write it up in a suitable language (OWL?), at the very least, and only THEN could we start tweaking the templates.

For now, let's focus on producing decent (informative, useful) articles for human readers. Apple Bottom (talk) 10:46, 25 July 2016 (UTC)

Mostly irrelevant side note: apgcodes can certainly grow big enough to be awkward in an infobox, but it's only mostly true that they can grow without bounds. A pattern over 40 cells wide would need a definite official ruling on how to encode longer strings of 0s. Quoting Apple Bottom from the apgcode article:

(Theoretically, runs of more than 39 zeroes should be replaced by 'yz' followed by the coding for the remaining zeroes. At the moment apgsearch labels everything larger than 40x40 as 'oversized' and refuses to process it.)

I'd agree that one or more yz, followed by one more y-something to get to the required length, is the easiest and most obvious way to extend the apgsearch format to encode patterns bigger than 40x40. But it might be worth thinking about a little bit, to see if it might be worth adding a marker that allows arbitrarily large (base 40?) counts to be encoded. At the moment, sufficiently large sparse patterns can be encoded much more efficiently in RLE format, because RLE can encode long distances of emptiness in a logarithmic number of characters, where apgcode is currently stuck with a linear encoding... a much more efficient encoding, but still linear.

I think most current Golly scripts that deal with apgcodes are lifted fairly directly from the old Python apgsearch, so they would similarly fail to handle patterns that need more than thirty-nine 0s, so it would be good to publish "official" encoder and decoder scripts somewhere -- maybe in Lua as well as Python. Dvgrn (talk) 15:25, 25 July 2016 (UTC)

Touché. (Of course, I must point out I didn't write that bit -- the edit's due to Rich Holmes, and is lifted straight from the wechsler.txt file on Catagolue.)

To split a hair, though, I think this is an issue of decoding vs. encoding. Given an apgcode of the form ...yzy1..., it's obvious that this corresponds to a run of 44 zeros, and even absent a formal specification or test suite I think decoders should treat it as such. It's the encoding part that's problematic, since there's no Word of God on which apgcode should be canonical.

Indeed, although encoding a run of 44 zeros can be encoded as yzy1, it can also be encoded as y1yz, which would retain the overall code's length but precede it lexicographically, so a crafty encoder could emit this instead when faced with such a pattern. In fact it could also emit wxyz instead. (0y0yz would yield a longer code and should thus be rejected.)

I'm tempted to suggest encoding long runs of zeros using a base-36 notation, where y# encodes # + 4 consecutive zeros, with # given in base-36, but since arbitary base-36 digits that aren't part of the code may follow, it would require a stop marker. This would break all existing codes that don't have one, so it's not feasible.

What is feasible is repurposing unused letters to indicate how many base-36 digits the number # has. For instance, if the z digit were used, with n z's indicating n + 1 digits, code fragments such as yzzz#### would be unambiguous, and the codes y0 ... yy would remain unchanged. A run of 44 zeros would be encoded as yz14 with this scheme.

This could still be done: a quick check of my files reveals that there are not currently any objects on Catagolue containing either yz or yy (though there are two containing yx, an xp412 in B358/S23 and the ship-pulling xq190 in B38/S23 (one variant, anyway).

So that's two ways out I see:

1. clarify how runs of more than 40 zeroes are encoded (greedy, e.g. yzy1; based on length/lexicographic order, e.g. wxyz; or other, to be specified), or
2. repurpose yz... to encode longer runs (e.g. yz14).

I personally prefer the first, since it requires no changes to existing decoders, and since I'm not so convinced people are going to want to encode extremely large patterns as apgcodes anyway (as you point out, file formats such as RLE are better suited to that task.) For that matter I also prefer the greedy algorithm, since that'd be easiest to implement.

BTW -- should we move this discussion to the forums? I've started a thread here, soliciting input from others. Apple Bottom (talk) 16:40, 25 July 2016 (UTC)

Kind of related: should we include the "raw RLE code" on all pages with them, alongside the regular RLE link? Doesn't seem way too useful, but hey. - AwesoMan3000 (talk) 16:17, 1 August 2016 (UTC)

It's nice to have the raw RLE link available if no commented RLE file has been uploaded. If we have a complete commented RLE file, a link will show up for that instead of the raw RLE. That all seems to me to be working fine just the way it is.

It would be nice if someone could put together code that would find any LifeWiki articles that have no uploaded commented RLE files, but do have raw RLE -- and build a simple commented RLE from the raw version.

I could put together something along these lines without too much trouble, I think -- but I would then have to upload the resulting files one at a time, or write some separate silly automation script to do that work for me. Here's hoping there's a better way out there somewhere (?) Dvgrn (talk) 17:10, 3 August 2016 (UTC)

Finding pages that have raw RLE code but no uploaded file can be accomplished fairly easily by tweaking the pattern templates to put such pages into a (hidden) tracking category. I can go ahead and take care of that.

Automatically generating RLE files wouldn't be too much trouble either, but an administrator would have to upload them. I'll leave this part to someone else. ;) Apple Bottom (talk) 20:56, 4 August 2016 (UTC)

EDIT: Here's the tracking category: Category:Pages with raw RLE code but no uploaded pattern files. It's empty at the moment, which indicates that either a) no such pages exist, or b) MediaWiki hasn't updated category membership information for all pages that transclude Template:PatternDownload yet. Without knowing off-hand how MediaWiki's internal queue for this sort of thing works, my money's on a). (Yay!) Apple Bottom (talk) 21:14, 4 August 2016 (UTC)

How about Grandfather_problem? Shouldn't that be showing up on Category:Pages with raw RLE code but no uploaded pattern files? I tried to create another instance, P11 pinwheel, but it's not appearing either.

-- Also noticed that Category:Pages without pattern files has a surprisingly reasonable number of entries -- someone could clean all of those up without too much effort. Dvgrn (talk) 14:54, 21 September 2016 (UTC)

The logic used in Template:PatternDownload to put pages into Category:Pages with raw RLE code but no uploaded pattern files was wrong. I believe it should work now. (Famous last words!)

Since I think it may be of general interest, I'd also like to quote from a PM sent to dvgrn on the forums regarding this issue, which has some background on MediaWiki template/... syntax, what the problem was, and what other features of the software mean for us. (Keep in mind that although I have some experience with MediaWiki I'm no wizard, and take what I say with a grain of salt, a slice of lime and a shot of tequila):

[...] Curly braces are being used by MediaWiki for many different things, among them: template inclusion/page transclusion, e.g. {{SomeTemplate}}; accessing template parameters within a template, e.g. {{{1}}} or {{{someparam}}}; parser functions, e.g. {{#if:...}} or {{#expr:...}}; and MediaWiki table syntax, where tables are introduced with a {| and wrapped up with a |}.

What's more, pipes are also used for several different things, notably: to separate parameters in a template call, e.g. {{SomeTemplate|param1=foo|param2=bar}}; in parser functions, to separate different parts of certain expressions, e.g. {{#if:condition|value-if-true|value-if-false}}; and (again) in MediaWiki tables, when a table is begun with a {|, when a new row is started with a |-, and when a table cell is introduced with a | (they appear in more places still in tables).

One of the consequences of MediaWiki's ad-hoc syntax is that pipes in e.g. tables clash with the parser function syntax. Template calls and parser functions are evaluated before wiki markup (including tables) gets converted to HTML, so the pipes in tables must be protected against being interpreted as separators. The usual solution is to have a template called ! (i.e. Template:!), which only contains a single pipe and which gets included as {{!}} whenever a pipe symbol must survive the template call/parser function step intact. Unfortunately this further increases the amount of curly braces used, and ! is itself used in MediaWiki table syntax (for table header cells), so for a human reader it's not making things any easier.

As for why why e.g. Grandfather Problem isn't showing up in the tracking category: looking at Template:PatternDownload again I think the logic used in that template to put pages into the category was faulty. There was (and still is) a test to see if there's any downloadable patterns for a page:

{{#if: {{{zip|}}}{{{mc|}}}{{{life105|}}}{{{life106|}}}{{{plaintext|}}}{{{rle|}}}{{#ifexist:RLE:{{{pname}}}|true|}} | ...

(This concatenates all the parameters to see if any were passed with a non-empty value, and also adds a "true" (i.e. a non-empty string) if a raw RLE snippet exists for a page; if any pattern exists, the whole thing evaluates to a "true" value for the purpose of {{#if:}}.)

There was an "else" branch (as it were) to that {{#if:}} later on which tested for the presence of a raw RLE snippet and added the tracking category if there was one. However, if there was such an RLE snippet the "else" branch of that {{#if:}} would never be run in the first place, so the category was actually never added to pages. [...]

As for the category itself -- it does not currently list all pages that should be in it due to MediaWiki's internal page cache / job queue, but it should populate itself in due time. (This is a feature primarily intended for large wikis where templates might be transcluded on hundreds of thousands of pages; synchronously updating category membership information for all of these when the template is saved would be impractical, to say the least.)

Individual articles should show the correct category if you've disabled page caching in your user preferences; if they don't, then doing a null edit (editing and clicking Save without making any changes) should fix this, or alternatively you can purge MediaWiki's cached version of that page by adding ?action=purge to the page's URL. (The page cache is shared across all users, so this will fix it for everyone.) I don't recall off-hand what the maximum age is after which page cache entries are considered stale, but it can't be too high, so simply waiting for a bit will also mean any page whose cache has not been purged yet will magically fix itself.

Apple Bottom (talk) 18:26, 27 September 2016 (UTC)

The new category is looking good now! The count of pages in the category stabilized at a hundred and thirty-odd, so I grabbed all the links and wrote a Python script to create commented RLE files using page title, infobox "discovered by", and pname.

The script creates the files just fine, but there are some problems I'm noticing with pnames. I filtered out the weird ones; here are the problem cases so far:

[Barge_with_long_tail], [Boat_on_aircraft], [Boat_on_snake], [Boat_with_hooked_tail], [Boat_with_very_long_tail], [Carrier_with_feather], [Cis-boat_with_nine], [Cis-long_boat_with_tail], [Cis-rotated_hook], [Claw_with_tub_with_tail], [Eater_head_siamese_carrier], [Eater_head_siamese_snake], [Eater_tail_siamese_carrier], [Eater_tail_siamese_snake], [Eater_with_cape], [Extra_long_hook_with_tail], [Extra_long_shillelagh], [Fuse_with_tail_and_long_tail], [Hungry_hat], [Integral_with_long_hook], [Integral_with_tub_and_hook], [Integral_with_two_tubs], [Long_prodigal], [Tub_with_cis-tail], [Very_long_integral], [Very_very_long_boat], [Very_very_long_canoe]. (Update: all these are fixed, I think -- new pnames match new raw RLE location, so the LifeViewer works, and now static images have been moved also.)

Looks like the pname is being defined as identical to the name in a lot of these cases --

|name         = Boat on aircraft
|pname        = Boat on aircraft

-- where it should be pname=boatonaircraft, at least according to the [how-to-contribute page on Patterns].

Would anyone care to volunteer to repair all these pnames, and move the relevant RLE:{pname} pages... or shall I just go ahead and do it? Dvgrn (talk) 22:44, 29 September 2016 (UTC)

Also -- many or most of the above linked patterns are recently-added named still lifes from Catagolue, I think. Is there a reasonably standard recommended LifeViewer config line for small still lifes, or shall I make one up? Dvgrn (talk) 14:34, 30 September 2016 (UTC)

Oh, I'd say you go ahead and do it. ;) The images will have to be moved as well when the pname's changed, of course. Apple Bottom (talk) 11:21, 1 October 2016 (UTC)

I tried fixing the last link, "Very_very_long_canoe", and the pname move worked fine, but the image didn't turn into a LifeViewer instance when I added a viewerconfig line. I admit that this is currently fairly pointless for still lifes -- the LifeViewer just serves as a very complicated generator of a still image, though with some awesome zooming/rotating/panning/coloring options...

However, that could change if LifeViewer starts supporting experimental editing, or selecting/copying patterns. Is there anything else I've forgotten that would enable the LifeViewer, or is that just not something that happens in still-life infoboxes?

When I figure all these details out, I should probably update the [pattern how-to pages] to mention the viewerconfig line, and raw RLE:pname pages and so forth. Hints and advice gratefully accepted. For the time being I probably won't bother adding useless viewerconfig lines to the other mis-pnamed still lifes. Dvgrn (talk) 13:13, 3 October 2016 (UTC)

It's been a bit, but IIRC Template:Oscillator and Template:Spaceship were specifically modified to support an embedded viewer, while other pattern templates weren't. I'll go ahead and edit Template:Stilllife accordingly.

BTW, one of the "would-be-nice-in-the-long-term" items on my to-do list is modifying the various pattern templates to use a common base template (so that only that base would have to be modified to support such things as an embedded viewer. But that's something that would have to be discussed and planned first, obviously. -- Apple Bottom (talk) 19:01, 4 October 2016 (UTC)

P.S. -- done, and it seems to be working on Very very long canoe. Still life-specific configuration for the LifeViewer is in Template:LifeViewer config/stilllife. I've also fixed a minor problem in Template:Oscillator for patterns with no uploaded image or pattern file/raw RLE (of which there shouldn't be any). Apple Bottom (talk) 19:08, 4 October 2016 (UTC)

Thanks -- the long term was impressively short in this case...! I've gotten a script to generate pattern RLE for all of the Category:Pages with raw RLE code but no uploaded pattern files, and uploaded them all. Now it's just a matter of changing nofile=true to rle=true, and fixing the pname for patterns in the list of links above. Don't need to add a viewerconfig line at all, right? -- unless I don't like the defaults.

rle=true successfully removed 112p5 from the category list. I tried getting a viewer for the first two items on the list, which were (27,1)c/72 Herschel climber and (34,7)c/156 Herschel climber, but those are in an odd "Crawler" category which I'm guessing isn't set up quite the same as the main categories.

I'm ignoring the problem of getting _synth files available for the synthesizable small stable patterns, and keeping the patterns and glider counts up to date. Will try to keep that on the back burner until the next version of Mark Niemiec's glider synthesis database becomes available. It might get a sizable update any month now, or at least any year, and possibly also a new URL. If the new URL seems likely to be stable, maybe it will make sense to provide direct links to the patterns on Mark's site, instead of copying them one-by-one to the conwaylife pattern collection. Dvgrn (talk) 12:57, 6 October 2016 (UTC)

Is there a good trick for moving an image file to match an edited pname? So far I've only tried with [this case], but didn't like the results. All the attribution information would have to be re-entered for the new copy (I think) and then the old copy could be deleted. Seems a little silly. Would a redirect work, maybe? Dvgrn (talk) 17:41, 6 October 2016 (UTC)

Images can be moved just like other pages; there's a menu item in the dropdown menu. This'll leave all metadata intact, including the original upload date and uploader, file description, and so on.

Moving an image will also create a file redirect which we may not need, but that can be deleted easily, or even just left for now — it's harmless after all. Apple Bottom (talk) 22:43, 6 October 2016 (UTC)

P.S. -- I've moved the affected images. Since you already uploaded a new copy of File:Barge with long tail.png, I'd suggest we delete File:Bargewithlongtail.png and then move the old one to the new and proper name. I'd do this myself, but I'm not an administrator and cannot delete pages. -- Apple Bottom (talk) 23:03, 6 October 2016 (UTC)

Okay, File:Bargewithlongtail.png is now the right file. Thanks! On to the remaining no-rle-file patterns, which I think all actually have correct {pname}.rle files but just don't know it yet. -- Dvgrn (talk) 13:36, 7 October 2016 (UTC)

Now they know. Ha -- take that, you Category:Pages with raw RLE code but no uploaded pattern files! Dvgrn (talk) 22:00, 19 October 2016 (UTC)

Too bad the LifeWiki doesn't have barnstars like Wikipedia does. You'd certainly deserve one for all the work you put in there -- excellent job clearing that category. :) Apple Bottom (talk) 22:20, 19 October 2016 (UTC)

P.S. I do apologize for already having created more work for you again, in the form of 128P10.2 and 48P22.1. -- Apple Bottom (talk) 09:51, 20 October 2016 (UTC)

No problem! A few at a time are easy to keep up with. The big group of new RLEs was generated with a script, but I won't bother with that unless the category page fills up again.

I'm vaguely worried about the pnames for these new objects, though. I suppose it will happen rarely if ever that there would be both a 48P22.x and an actual 48P22x (for x=digit 1 to 9). Guess there's no harm in waiting to cross that bridge if we ever come to it. Dvgrn (talk) 02:16, 24 October 2016 (UTC)

True, that COULD be an issue down the road. Are there any reasons why we don't have periods in pnames so far anyway? The only OS/filesystem I can think of right now that could potentially have issues with having multiple periods in a filename (as in e.g. 48p22.1.rle) is MS-DOS/FAT16, but that's going to run into other problems anyway, e.g. with long filenames. 'sides nobody uses DOS anymore, right?

We don't have too many of these, FWIW. Looking at Category:Oscillators, I can only see the following: 123P27.1, 128P10.2, 28P7.1, 42P10.1, 44P12.2, 48P22.1, 54P17.1, 65P13.1, 68P32.1, 92P33.1 and 94P27.1. None of those seem particularly "dangerous" to me; oscillators with three-digit periods and two-digit minimum populations aren't gonna be that common. And 28P71 — well, 71 is prime.

Category:Spaceships contains no patterns right now where there would any ambiguity, BTW. All "dotted" ships move horizontally.

There's also a couple of oscillators where the pname DOES already include a period, BTW, namely 134P39.1, 168P22.1, 18P2.471, 28P7.2 and 44P7.2. So there's prior art for doing that.

If we decide to change this we'll have to amend LifeWiki:Pattern pages, which currently states that the pname should be "[t]he name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed". OTOH I think most people (myself included) create patterns by copying existing pattern pages and editing them as required. ;) -- Apple Bottom (talk) 09:57, 24 October 2016 (UTC)

Smallest oscillators of a certain period?

I think it might be useful to have a category page which shows all oscillators that are currently the smallest oscillator of their period. (In terms of cells). Thoughts? Gmc nxtman (talk) 16:41, 14 August 2016 (UTC)

If population is the only measure, there's an absolute ceiling for oscillator size no matter how big the period gets. The "smallest" oscillator will often be a big eight-glider loop made of Snarks, or I guess maybe just a couple of rectifiers. Just need to make sure no one is tempted to add pages for each such oscillator... but I suppose that's not likely to be a problem. Maybe only include oscillators with period less than 43, or maybe less than 100 since the rectifier's repeat time is 106? Dvgrn (talk) 13:55, 21 September 2016 (UTC)

Pattern collection archive

I noticed that the pattern collection linked on the Main Page only contains RLE files anymore, not files in other formats (Life 1.05, Life 1.06, Macrocell, Plaintext). That's fine in principle, I think; RLE has been established as a standard, and we probably don't need to provide Life 1.05, Life 1.06 or Plaintext files.

However, there's a couple of patterns that are now missing entirely from the archive, large patterns that are only available in Macrocell format. Specifically, the following files are gone:

• caterpillar.mc
• centipede.mc
• demonoid.mc
• parallelhbk.mc
• shieldbug.mc
• succ.mc

Would be nice if the script generating the archive could be modified to include those again. Oh, and while I'm at it: the _README_.TXT file should perhaps be updated as well to reflect the fact Plaintext and Life 1.05/1.06 files aren't included anymore.

One more thing: the archive contains two different "B29 with gliders" files, B29withgliders.rle and b29withgliders.rle. This is probably unintended, and also causes problems on case-insensitive filesystems. Apple Bottom (talk) 11:24, 8 October 2016 (UTC)

EmbedViewer template

x = 13, y = 10, rule = B3/S23 4bo3bo$2b2obobob2o$bo3bobo3bo$o3b2ob2o3bo$obo7bobo$bo9bo2$4b2ob2o$3bob obobo$4bo3bo! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART GPS 4 THUMBSIZE 2 ]]

Rich's p16
(click above to open LifeViewer)
RLE: here Plaintext: here

Quick heads-up: I created a new template for easily embedding LifeViewers in article, Template:EmbedViewer. It should be largely self-explanatory; the example shown to the right was generated using the following template call:

{{EmbedViewer
|pname        = richsp16
|viewerconfig = #C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART GPS 4 THUMBSIZE 2 ]]
|caption      = [[Rich's p16]]
}}

The template itself has some basic documentation for its parameters. Default CSS style and LifeViewer configuration could probably still be tweaked, but it's a start and should make things a bit easier. Apple Bottom (talk) 10:36, 9 October 2016 (UTC)

Clearing out Category:Proposed deletion

I've gone and removed the low-hanging fruit from Category:Proposed deletion by deleting the uncontroversial cases where there is almost certainly consensus for deletion. There are now 9 subcategories, 8 pages and 7 files left; for these, I'd like to start a discussion before doing anything.

My suggestions are:

• Category:Oscillators with 284 cells
• Category:Oscillators with heat 54
• Category:Oscillators with heat 76
• Category:Oscillators with period 155
• Category:Oscillators with period 186
• Category:Patterns found by GraviPy
• Category:Patterns that can be constructed with 111 gliders
• Category:Patterns with 162 cells
• Category:Spaceships with heat 10

Although these are currently empty, they could be of use in the future, so I'm inclined to keep them. OTOH they clutter up the category tree and the DynamicPageList templates, and there is nothing in any of them that couldn't easily be recreated if and when they are needed again. I'm on the fence about these.

• Category:Asymmetric patterns

User:Fractal Fusion reworked our symmetry-related category/template infrastructure back in late March/early April this year, and (IIRC) felt that there was no need to have a category for patterns lacking any kind of specific symmetry. I disagree with this; collecting asymmetric patterns in a category allows us to distinguish pages which have no symmetry from those which have not had their symmetry specified yet.

That said I also believe that symmetry should be specified as part of the pattern infobox; and having a symmetry= parameter there would in turn allow a proper tracking category to be created, so this category would then not be necessary anymore at all. (That discussion, however, is for a later date.)

• Augmented still life
• Primitive still life
• String
• Vessel

Glossary articles without references. I'm on the fence with regard to whether these should be in the main namespace, but if the consensus is that they shouldn't, I'd suggest moving them to subpages of the users that created them instead of deleting them outright.

As the creator of all four: the first three are not glossary articles, as much as analysis articles, as a part of a project to impose some order on still life and more generally pattern classification (beyond fairly robust metrics such as cell count or bounding box). (In Wikipedia terms, they would clearly count as "original research".)

I have not lately found time to work with GoL in any extent, such as to flesh these pages out further, much less to work on an actual (non-wiki) article I have planned on the topic. (This would e.g. include an approximate generating grammar for strings.) If people wish to move these pages to userspace, go ahead. --Tropylium (talk) 12:06, 21 February 2017 (UTC)

• Glider 7171
• File:Plasmabursterinverted.png

A spaceship that does not exist in Conway Life. My suggestion is adding a section on it to the Live free or die article and delete this article. Alternatively this article could be moved to a subpage of the user that created it as well, but we should not use the standard spaceship template then to avoid category pollution. The image can be kept or deleted as necessary.

• Mangled1beacon synth.rle
• RLE:Mangled1beacon synth

We do not currently collect synthesis RLEs, and this one is in the wrong namespace anyway. My suggestion is to delete this for now. (And re: adding synthesis RLEs in general, I think Mark Niemiec is already doing a terrific job, so we don't have to; but that, too, is a discussion for another day.)

• UNTITLED

This was used by the SimpleForms extension; since that extension is not currently installed anymore I believe the page can be deleted, but I'd like to get User:Nathaniel's OK for this first.

• File:AGARONION.GIF
• File:DIPNAG.GIF
• File:LILFIRE.GIF
• File:ORPNAG.GIF
• File:PNDRNG.GIF

These can probably be deleted; we have better versions of all of them.

• File:P35hfhassler.png

We have a better version of this, too, but I only just proposed deletion yesterday, and don't want to delete it so quickly myself without input from others.

Apple Bottom (talk) 12:32, 13 October 2016 (UTC)

I've also PD'ed three more:

• Category:Patterns with D1 symmetry
• Category:Patterns with D2 symmetry
• Category:Patterns with D4 symmetry

These are all empty, and they're not part of our current symmetry infrastructure. What's more, their content is misleading (as far as I can tell) in that what they describe is actually D2, D4 and D8 symmetry, respectively. My suggestion is to delete all these. Apple Bottom (talk) 10:54, 17 October 2016 (UTC)

LifeViewer for eaters

Should we put LifeViewer applets in pages about eaters so we can view their eating sequences? - AwesoMan3000 (talk) 08:45, 2 November 2016 (UTC)

Template and pages for agar crawlers.

So I'm thinking this should be something pretty similar to the spaceship template. Not sure how lifeviewer would handle it though. - AwesoMan3000 (talk) 13:23, 17 December 2016 (UTC)

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)

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)