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

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)