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

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.

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

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)