LifeWiki:Tiki bar

From LifeWiki
Revision as of 18:56, 16 June 2016 by Nathaniel (Talk | contribs)

Jump to: navigation, search
Taka Tiki Break

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

Welcome to the Tiki bar

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

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)
Copperhead infobox mockup.png
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)
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)

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)