LifeWiki:Tiki bar

Taka Tiki Break

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

Click here to start a new Tiki bar discussion.

Welcome to the Tiki bar

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

Archived discussions

Note: active discussions are not archived.

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

LifeViewer inline patterns versus JavaRLE

As discussed in a questions thread on the forums -- do we know enough about LifeViewer, and is it stable enough for all users on all browsers as far as we know, that we should adjust the Pattern Pages howto and checklist to explain how to do inline RLE for secondary images in an article, without the nuisance of getting pattern files uploaded as a separate admin-only step?

More ambitious: might there be some clever way for non-admin users to contribute the baseline pname.rle and pname_synth.rle files directly, using a similarly easy inline-RLE method? This is already possible by creating a raw RLE page for the pname pattern, but it doesn't work for pname_synth, does it? Could those RLE chunks be hidden in the actual article text somewhere, in some standard location?

It still seems good to have copies of these patterns available in the downloadable ZIP file, though. Does that mean we also need a mechanism to assign a pname to each LifeViewer inline pattern? And then some (semi-automated?) way do the upload, and note in the article that that has been done.

A vaguely related note: the pattern-file admin maintenance page is getting a little unwieldy as the number of patterns goes up -- it lists every pattern in one page, which is so long now that the load time is really noticeable sometimes, at least on my system. Dvgrn (talk) 15:27, 26 November 2017 (UTC)

You're right, pname_synth isn't currently recognized. This could be changed; all we'd need to do is update the pattern templates accordingly.

I'm not sure I'm a fan of putting the RLE into the article text proper. The most natural place for it would be an infobox parameter, but that might run into subtle parsing issues. For example, I'm not sure if this:

{{Oscillator

|name = Prancing Ponies

|pname = prancingponies

|p = 49

...

|rle =

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

...

|... = ...

}}

...would work, or whether it might break because there's equal signs in the value of the rle parameter. I think MediaWiki is smart enough to handle this these days, and a similar parameter to Template:EmbedViewer has not caused any trouble yet as far as I'm aware, but this sort of thing still makes me nervous. (The safe way of handling this would be to escape all equal signs in the value passed using an appropriate template, as {{=}}, but users will forget this, and if it then doesn't work they will not understand why.)

The above applies equally to the synthesis RLE, of course. On that note, having the synth RLE for pname live in RLE:pname_synth or Synth:pname or so would be saner. But it would make the RLE less accessible (though of course the pattern templates could also be rigged to check whether the RLE exists, and show a big red "click here to add the missing RLE" link if not.)

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

For secondary patterns currently using Template:JavaRLE I think migrating to an on-wiki solution is definitely sensible though. Template:EmbedViewer already exists and can be used (and several pages are already using it), even if that template's still got room for improvement.

I do agree that the ZIP file containing all uploaded patterns is valuable and should be kept if at all possible. (Do we have statistics on how often that's downloaded, BTW?) As I said on the forums, generating it from on-wiki RLEs would just be a matter of adjusting the generator script, but someone's got to do it, and unless someone else has shell access to conwaylife.com's hosting, it'd probably have to be Nathaniel (who I understand is busy these days with rather more important matters).

(Might be a good time to bring up (again?) an old idea of mine, namely that of a Conway Life Foundation that could take some of the responsibility and workload off of Nathaniel's shoulders. Hey, it's worked for N. J. A. Sloane and the OEIS, and Larry Wall and Perl, and Jimbo Wales and Wikipedia...) Apple Bottom (talk) 21:29, 28 November 2017 (UTC)

Just a note on the technical side of things -- an equals sign within a template parameter indeed won't cause any problems (as long as the parameters are named, as is the case in the pattern infobox templates). The only problem that might arise is if the RLE has vertical bars | in them, but I don't think there's any reason that should ever happen.

I agree that RLE data should be separated from the main page data in some way, since it is somehow more important and/or should be more "static". We could keep using pattern files, but that has the not-admin-friendly downside. We could use the RLE namespace, which in my opinion isn't bad (maybe slightly clunky). Perhaps a more elegant alternative would be to use the new Cargo extension that has recently been made available for MediaWiki. I've tested it out on another wiki that I run, and it works pretty fantastically (though I'd have to update MediaWiki here to a more recent version before it'd work). It introduces a bit of server overhead, but not *too* much based on my testing with it. What it does is makes data entered into templates query-able across the wiki, so on any page of the wiki we could write code that looks something like {{GetRLE|Glider}}, and it would grab the RLE from the pattern template on the "Glider" page. Nathaniel (talk) 17:42, 1 December 2017 (UTC)

The Cargo extension looks interesting, but it's a couple of steps removed from what we can do today. Maybe what we should do is to keep implementing Infobox patterns using uploaded pattern files or the RLE: namespace, whichever one we have -- but also document how to set up subsidiary patterns in an article using LifeViewer and inline RLE, since that's the only way that non-admin users can add such patterns without admin help.

The inline LifeViewer method doesn't require the additional patterns to have their own unique pnames, but the docs should ask for one and give a standard way of recording the pname.

Whenever we come up with a better method, and hopefully while there's still only a manageable number of LifeViewer-with-inline-RLE patterns, we'd probably want to commit to an admin-led effort to convert all trial-format pages to the new long-term format.

That seems like one possible way to keep moving forward in smallish steps, while also avoiding the current problem of confused and mystified potential contributors. Thoughts? Dvgrn (talk) 18:39, 1 December 2017 (UTC)

Sorry for the late reply... I agree with Dvgrn, Cargo looks neat, but I'm not convinced it'll help us here. For making it easier for non-admins to contribute/edit RLE files I still think the best current way to do this is to either:

• keep RLE in wiki pages, in the existing RLE namespace or a new one (say "RLE synth"); or
• use regular on-wiki file uploads for RLE files. I've never tried this, but the File: namespace isn't just for images, so I'm sure it could be made to work.

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

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

This evening I'm feeling brave enough to start editing the Help: files to tell J. Random User step-by-step how to add patterns for use with LifeViewer. That means deciding what to say about including/not including RLE header lines, comments, etc. The possibility of adding _synth files this way seems like a minor remaining question mark.

Eventually I think all these added patterns in the RLE: namespace should be automatically vacuumed up somehow and added to the pattern collection -- presumably with some kind of comparison tool to make sure that patterns already in the collection are the same as the versions in the RLE: namespace. (Will work on building that tool later.) Dvgrn (talk) 22:04, 21 February 2018 (UTC)

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

Still not sure whether RLE:pname_synth or Synth:pname would be the better choice; I'm actually leaning toward the former right now. It'll make the script that little bit less complicated; it fits our existing naming scheme for pattern files, images, etc.; and it won't require a new namespace to be configured. (Of course you can create prefixed pages without a namespace as well, with the prefix just being part of the regular title, but that interacts badly with things like Special:RandomPage; and moving pages over after a new namespace has been created... well, there's still at least ghost RLE: page lingering in the Main namespace right now that is being shadowed by an RLE: namespace counterpart.) So yeah, leaning towards RLE:pname_synth right now.

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

#N Pattern name
#O Discoverer
#C One-line description
#C Wiki-page link
(actual pattern)

We probably can't reasonably expect random users to adhere to that, always --- but guidelines are good having, and if it's on-wiki it's easy to edit.

The only issue I can see right now is conflicts. Suppose you have an RLE file, and an on-wiki RLE snippet, and they're not the same. How do you tell whether a) the RLE file was uploaded by an admin (and should thus presumably not be overwritten), and b) the RLE file was generated from an earlier revision of wiki page, and thus should be overwritten?

One way around this would be to put a suffix on the files generated from on-wiki RLE snippets, so that e.g. RLE:ponyexpress would become ponyexpress_wiki.rle, or some such thing. Conflicts could then be handled by simply assuming that any file whose name is suffixed _wiki was imported from the wiki and is fair game for being overwritten (and if it was not, then the uploading admin only has themselves to blame). But is this ideal?

Flagging files externally would also be possible, but the flags should be visible on the mod panel in some way, and they should reset if a file is manually uploaded there.

Alternatively we could declare this to be a non-issue and say "the wiki takes precedence, period". This would be the way to go if we want to deprecate the mod panel in the long term. If we did this, of course, we (and by "we" I mean you, heh) should audit the uploaded RLE snippets we've got to make sure we'd not be overwriting any existing RLE files with inferior content. (Comparing conflicting files to see which ones are actually different could also be done programmatically, of course.)

But that's enough rambling from me! Apple Bottom (talk) 09:08, 22 February 2018 (UTC)

Sounds good -- RLE:pname_synth it is, then. I'll see if I can dig up a sample or two to add on-wiki, with a suitably modified header:

#N pname_synth
#O Discoverer, optional date (?)
#C Description -- can be one or multiple lines
#C Wiki-page link
#C http://www.conwaylife.com/patterns/{pname_synth}.rle
{actual pattern}
#C LifeViewer config

I like having the date, if it can be collected, but there's never been a really good place to put it. It sort of ought to have its own tag, like #D {date}, but #D traditionally meant something else in old Life32 files, and it's a little awkward having it take up its own line anyway, so I usually just put it in the description.

It's also nice to have the direct link to the actual pattern file, when that exists. That might cause headaches because it won't exist until the hypothetical periodic upload happens, and then it will exist. So probably both the wiki-page link line and the pattern link line really ought to be added programmatically, to signal that the upload has happened. I think I have the tools to do that, but it's a bit ugly -- will experiment and (eventually) report back.

Another awkwardness is the question of whether or not to include a LifeViewer config line, when that exists, in the uploaded RLE pattern. This is looking forward a little, but I'd like to programmatically grab that and throw it in also. Mostly this is because lifeviewer.lua is a thing, and it may eventually allow LifeViewer-like displays in Golly if the config line has been carried over. Just tried it on-wiki and it's a bad idea to have it in the RLE: namespace due to conflict error messages.

Next question: we have Category:Pages_with_raw_RLE_code_but_no_uploaded_pattern_files and Category:Patterns_with_RLE_snippets_but_no_LifeViewer_configuration, but that only applies to articles with an associated primary pattern, not articles with one or more subsidiary LifeViewer illustrations. What's the best way to get a link list for everything in the RLE: namespace? Dvgrn (talk) 11:46, 22 February 2018 (UTC)

Looks good! I just realized that due to MediaWiki's underscore conversion, RLE:${pname}_synth will become (i.e. look like RLE:${pname} synth). I don't know what title MediaWiki saves the page under internally, so it may be a good idea to code conservatively and convert spaces to underscores.

Re: dates: what does #D traditionally mean, then? BTW, we might be able to use #T (for "timestamp") or so instead.

LifeViewer-config embedded in the RLE file itself, that's certainly doable; if this is done we may eventually want to remove the relevant infobox parameter, it shouldn't be needed anymore then. (The "default configs" could then also go, in a second step.)

Re: pattern file links not being "live" until files are uploaded: as you say, this should be fine if those links are added (and the files uploaded) programmatically. Perhaps the script could also update the on-wiki pattern file?

Getting a list of all RLE: pages -- you can do that on-wiki using Special:AllPages, specifically Special:AllPages/RLE: (here's a better link). From a script, you're probably better off using the MediaWiki API. I've no experience with this, but the allpages query looks promising (you can pass a parameter indicating which namespace you're interested in).

... What does #D mean? You'll be sorry you asked. Summary here.

Xlife tag -- #D x,y:  coordinate differences from
the previous point, separated by newlines
Life 1.05 format -- comment, instead of "#C".
"D" stands for "description".
Life32 format -- initial tag in every saved pattern,
containing an ugly hexadecimal checksum.

Hmm, we start with putting standardized comments in the RLE, and now maybe just move the LifeViewer config line there too? I almost wouldn't mind that. Ihe viewerconfig is generally a lot bigger and uglier than any of the other infobox parameters.

My first thought was that it was a bad idea, because if we wanted to use the same pattern in a different article with a different LifeViewer animation (highlighting a different reaction, or whatever) then we'd have to duplicate the RLE, name it something different, and add a different config line.

But considering how often pattern re-use has actually happened so far -- approximately never (?) -- I don't think a tiny amount of duplication would be a problem if the case did eventually arise. Should I be brave and start moving config lines into RLE, or is this a good time to hunt for third opinions?

On the #T timestamp idea -- I wouldn't mind that too much, but unless the discovery date is going to be filled out really reliably with a #T tag, I don't entirely see why we need a new #T convention. We could equally well say that the new #O convention is #O {discoverername}[, {discoverydate}]. I'm happier when there are fewer half-empty mandated comment lines; the date fits perfectly well on the same line with the discoverer.

-- Yeah, there are some possible parsing problems with commas if there are multiple discoverers, which could probably only be solved by standardizing the date format. But again, is anyone really ever going to be expecting to find a discovery date reliably with a comment-line parsing script?

Thanks for the pointer to "All pages". The amount of wikistuff I don't know still greatly outnumbers the amount I do know. I see the redirects are helpfully italicized. Um... "RLE:Merzenichsp644blockshassling2beehivesand2rpentominos"? What exactly is that doing in there? Dvgrn (talk) 18:09, 23 February 2018 (UTC)

Ah, so the answer re: #D is "it's complicated". Gotcha. ;) And OK, let's just extend what #O covers, that's probably the most sensible approach.

Re: LifeViewer config -- yes, it seems we're not actually reusing patterns in different places, so moving the viewerconfig into the pattern seems sensible.

FWIW, what we're currently lacking is a mechanism for "prioritizing" LifeViewer config parameters. Having a mechanism to assign different priorities to different #C [[ ... ]] lines would open up a variety of use cases. Imagine the pattern looks like this:

#N Amazingpattern
#O Cathy Sue Lifeenthusiast, November 2017
#C https://conwaylife.com/wiki/Amazingpattern
#C [[ TRACKLOOP 30 -1/10 -1/10 GPS 15 ]]
x = 48, y = 52, rule = B3/S23
...

Now imagine that we want to use this pattern somewhere, with a different viewerconfig, and that we could simply say:

{{EmbedViewer
|pname        = amazingpattern
|viewerconfig = #C [[ PRIORITY 1 GPS 1 ]]
|caption      = Cathy Sue's Amazing Pattern in slow-motion
}}

And the explicit viewerconfig would (partially) override the embedded one, by virtue of having a higher PRIORITY (the default if none was specified would be 0).

Further imagine that there was a default viewerconfig that said e.g.

#C [[ PRIORITY -1 THUMBLAUNCH THUMBSIZE 2 GRID GRIDMAJOR 0 THEME 6 ]]

...thus setting a number of sensible defaults at a lower priority, allowing any viewerconfig embedded in the pattern file or passed explicitely to a template to override it.

Wouldn't that be neat? Perhaps Chris Rowett could be persuaded to add something along these lines. (Right now, IIRC, LifeViewer throws the towel in the face of conflicting configuration commands.)

Finally, re: RLE:Merzenichsp644blockshassling2beehivesand2rpentominos -- that's apparently a redirect left over from when I moved a page from a previous improper name. I'll delete that, we don't need the redirect.

EDIT: I've also deleted all other redirects in the RLE: namespace; none was necessary, and none had any pages linking to it (except for RLE:Lightweight spaceship, which was linked to as an example of not to name RLE: namespace pages). Apple Bottom (talk) 10:45, 24 February 2018 (UTC)

After looking at the ugliness of competing viewerconfig lines, I was thinking somewhat along the same lines. Another option that would allow many of the same use cases would be a simple command to allow later configs to override earlier ones:

viewerconfig = #C [[ OVERRIDE GPS 1 THEME 3 ]]

However, at the moment all such use cases require quite a bit of imagination -- we don't need to do any such thing with any current patterns, and there's a perfectly good workaround that involves adding RLE:cathysueamazingpatterninslowmotion. And since I'd much rather Chris worked on some waypoint and point-of-interest stuff, and/or support for Larger than Life which is also in the works, maybe I'll just leave this note here and see if he notices it --! Dvgrn (talk) 13:06, 24 February 2018 (UTC)

That works, too -- though an explicit OVERRIDE tag would have the disadvantage that you'd explicitely have to spell it out. Say we've got a default viewerconfig for oscillators that should be overridden by more specific viewerconfigs in individual RLE files; then all these files would have to use the OVERRIDE tag. And if you then wanted to use the same pattern in several places, and tweak its viewerconfig further, as in the "slow-motion" example above, you'd have to OVERRIDE the embedded viewerconfig as well.

Worse, it's not immediately obvious to me what the result would be in the face of conflicting OVERRIDEs. Say, the three viewerconfigs (default, embedded-in-RLE, and explicitely-passed) amount to something like the following:

#C [[ GPS 4 ]]
#C [[ OVERRIDE GPS 30 ]]
#C [[ OVERRIDE GPS 1 ]]

would the final GPS be 30 or 1? I'm tempted to say "1" -- but one could disagree. And besides, if it is 1, we'd be back to square one; the final result would depend on the order of the lines again, and all we'd have done is a "please don't ignore this line" tag. (PLEASE ABSTAIN FROM IGNORING... the INTERCAL version of LifeViewer?) At that point we might as well do away with the tag again and say "later values overwrite earlier ones, so the last value takes precedence".

But yes, let's leave it for Chris. As you say, we can just upload different version of the same pattern if this ever becomes an issue in practice. Apple Bottom (talk) 09:21, 25 February 2018 (UTC)

"later values overwrite earlier ones" is how LifeViewer works today. It just throws errors to tell you that's what happened. If you wrote:

#C [[ GPS 4 ]]
#C [[ GPS 30 ]]
#C [[ GPS 1 ]]

LifeViewer would say:

Script errors
GPS 30 overwrites 4
GPS 1 overwrites 30

and set GPS to 1.

Two level config makes sense to me: a baseline (level 1 config) which is the default style for LifeViewer in the Wiki, and then specific extras (level 2) per pattern or class of pattern. In this case you do want "later values overwrite earlier ones" but to be able to suppress the error message the first time a later script command overwrites something defined in the baseline. The reason for first time is I'd still want to know if there are multiple definitions of the same parameter in the level 2 script since this is likely an error.

This suppression could be as simple as a new script command added at the end of the level 1 config.

#C [[ THUMBLAUNCH THUMBSIZE 2 GRID GRIDMAJOR 0 THEME 6 SUPPRESS ]]

For three level config I'm not clear on how this would work. Are the config levels strictly hierarchical? Chris Rowett (talk) 07:51, 26 February 2018 (UTC)

I'll prefix this by saying I don't know exactly how LifeViewer parses its configuration lines -- is it line-based, or are all the lines treated as one continuous stream of config commands internally?

I've been assuming the former, and on that assumption my initial idea was that config lines like the following:

#C [[ LOOP 60 GPS 30 ]]
#C [[ THEME 6 THUMBLAUNCH THUMBBSIZE 2 GPS 3 PRIORITY -1 ]]
#C [[ GPS 1 PRIORITY 1 ]]

would be parsed into a data structure like the following:

$VAR1 = {
          'GPS' => {
                     '-1' => 3,
                     '0' => 30,
                     '1' => 1
                   },
          'LOOP' => {
                      '0' => 60
                    },
          'THEME' => {
                       '-1' => 6
                     },
          'THUMBLAUNCH' => {
                             '-1' => 'true'
                           },
          'THUMBSIZE' => {
                           '-1' => 2
                         }
        };

...which would, in a second step, be tranformed by eliminating the middle layer:

$VAR1 = {
          'GPS' => 1,
          'LOOP' => 60,
          'THEME' => 6,
          'THUMBLAUNCH' => 'true',
          'THUMBSIZE' => 2
        };

...thus producing the final configuration to use. Of course, this rests on the assumption that the specified PRIORITY would apply to the entire line, rather than just one parameter.

If LifeViewer does treat all config commands as one continuous stream internally and if you don't want to change that, then yes, it may actually be enough for our purposes here to have a flag to suppress (certain) errors. We'd then just take care to assemble the various config lines in the right order in the templates, subsequent parameter values would overwrite earlier ones, and thanks to the flag, there'd not be any complaints that we had two GPS specifications, say.

I think the flag could suppress all errors (relating to config values being overwritten, anyway), too. After all, it would only come into effect if explicitely specified -- caveat emptor. Also, it shouldn't suppress all errors, and LifeViewer could still collect these messages and display them on request, so long as it didn't present them as script errors by default. Apple Bottom (talk) 11:25, 26 February 2018 (UTC)

LifeViewer treats all config commands as one continuous stream and as such line breaks have no special meaning. You could still have commands that define priority or error suppression in that stream. Examples of this are the Waypoint commands [[ T ]] and [[ PAUSE ]], and the [[ POI ]] command. These commands signify the start of a new Waypoint or POI and the following commands define that Waypoint or POI, until another Waypoint or POI command is hit. For example:

x = 28, y = 5, rule = B3/S23 o2bo2b4o2bo5bo6b2o$o2bo2bo5bo5bo5bo2bo$4o2b3o3bo5bo5bo2bo$o2bo2bo5bo5bo5bo2bo$o2bo2b4o2b4o2b4o3b2o! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ PAUSE 2 X 0 Y -10 ZOOM 6 T 100 X -100 Y -30 ZOOM 2 T 200 X 0 Y 5 ZOOM 8 LOOP 400 AUTOSTART ]]

Waypoints example
(click above to open LifeViewer)

#C [[ X 0 Y -10 ZOOM 6 T 100 X -100 Y -20 ZOOM 2 T 200 X 0 Y 5 ZOOM 8 ]]

Means start the camera at x = 0, y = -10 with zoom 6. By generation 100 get the camera to x = -100, y = -20 at zoom 2. Then by generation 200 get the camera to x = 0, y = 5 at zoom 8.

This could also have been written for clarity as:

#C [[ X 0 Y -10 ZOOM 6 ]]           initial camera position
#C [[ T 100 X -100 Y -20 ZOOM 2 ]]  first waypoint
#C [[ T 200 X 0 Y 5 ZOOM 8 ]]       second waypoint

But to LifeViewer the two are identical.

So in the same way a PRIOIRTY or SUPPRESS keyword could apply to all following commands or all previous commands. My intention with SUPPRESS was that it would only suppress "overwrite" errors and not all errors. Chris Rowett (talk) 12:05, 26 February 2018 (UTC)

I certainly wouldn't object to a SUPPRESS keyword -- it's simple, and simple is good (and easier to test, too).

On the other hand, in some sense its function is to hide problems that maybe don't need to be hidden. If we can just make a decision and stick to it, about viewerconfig lines belonging at the bottom of the RLE:{pname} pages and nowhere else, then there's really not much potential for conflicts that need to be SUPPRESSed.

Theoretically I like the idea of abstracting out some general LifeViewer settings that deal with an overall LifeWiki "look and feel", putting them in say the Pattern template, and then being able to change those settings in one place and have it change immediately everywhere. If we want that functionality, then I guess it would be good to have at least the SUPPRESS keyword, to allow for overriding those defaults without seeing errors.

In practice, though, what settings could we possibly set at the general level and then alter later, that wouldn't break a whole bunch of carefully configured LifeViewer instances?

We're currently adding "#C [[ THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART ]]", right? Can someone remind me where exactly that's coming from again? After finding it in the copied text for Glider, Blinker, etc., I just looked through the Spaceship and Oscillator and Pattern templates, and did searches on "THEME" and "GRID GRIDMAJOR" and "THUMBLAUNCH AUTOSTART".

Couldn't find the source of that appended viewerconfig line anywhere. But I did find that all these settings, including THEME, are in fact mentioned specifically in viewerconfigs here and there. In Tanner's p46, for example, the THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART is supplied automatically in the infobox, but has to be explicitly included in the glider-gun illustration in the article. How should that illustration _really_ be done -- is there a more standard way? Dvgrn (talk) 19:18, 26 February 2018 (UTC)

Chris -- thanks for the clarification re: linebreaks (not) having a special meaning!

Dave -- these days, all pattern templates transclude Template:InfoboxStart, passing the defaultconfig= parameter; that template then handles all the boilerplate code to open a pattern infobox, including the embedded viewer. The default LifeViewer configuration is loaded from Template:LifeViewer config/${defaultconfig}, assuming that exists. You can find a list of current default configurations here, by way of Special:PrefixIndex (another handy special page to know about).

How were these default configurations decided? Truth to be told, I think we simply put whatever seemed like a good idea at the time into them, the goal being (again) to cut down on boilerplate and not having to specify, say, a theme for every pattern but getting something nice and good-looking by default.

The whole mechanism could be reworked as necessary, of course. We can change these default viewer config as desired, and we can also remove them altogether and instead stipulate that all uploaded RLE snippets should include their own, including all theming.

I don't have any horses in this race, and I don't know much about the technical side of LifeViewer, so I'll just leave this to the two of you. Apple Bottom (talk) 19:32, 26 February 2018 (UTC)

Any suggestions as to how best to set up a default config for secondary illustrations, such as the one in Tanner's p46? I think "THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART" is really pretty good as a standard.

It seems reasonable

1. to assume all of those config settings in a LifeWiki context (in nearly all cases -- maybe with a slight change for still-life patterns, omitting the AUTOSTART), and
2. to not include any of that outside of a LifeWiki context

(so that those details won't get exported and distributed with patterns in The Future LifeWiki Pattern Collection)

-- whereas things like HEIGHT and WIDTH and GPS should be included, so they'll go at the end of the RLE:{pname} entry.

Seems like that strikes a reasonable balance, and avoids adding lots of THEME 6 BLAH BLAH BLAH boilerplate to each and every RLE:{pname} page. Guess I'll start gradually getting the viewerconfig lines out of existing infoboxes, and see if any unforeseen difficulties crop up. Dvgrn (talk) 20:48, 26 February 2018 (UTC)

The double-square-brackets around THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART has made it the second-most wanted page on the LifeWiki. If it's good enough as a standard, should this wanted page be created to explain that THEME 6 GRID GRIDMAJOR 0 THUMBLAUNCH AUTOSTART is a sequence of LifeViewer commands used to give the familiar LifeWiki appearance for embedded patterns? It seems almost too tempting to resist. Calcyman (talk) 21:17, 26 February 2018 (UTC)

Now it's the first most-wanted page, but thanks to the template changes, the request is for just plain AUTOSTART. Probably might as well wait a while and see what else changes, before trying to explain anything... but eventually a walkthrough would be really nice, to show exactly how to build a good multi-illustration article. Dvgrn (talk) 16:58, 27 February 2018 (UTC)

The style stuff should probably be in a single default config that's inherited by all the others. The current default appears to be:

THEME 6      (alive cells are black, dead cells are white, and no history colours)
GRID         (draw gridlines)
GRIDMAJOR 0  (no major gridlines)
THUMBLAUNCH  (show LifeViewer as a thumbnail that launches when clicked)

As Dave suggested AUTOSTART is not needed for still-life patterns. It'll just burn CPU cycles for no reason.

Perhaps we should have "LifeViewer config/default" that contains just the style stuff above and is always loaded and then one of the specific configs (which now in most cases would just contain AUTOSTART except for the config/stilllife which would be empty).

b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ AUTOSTART THUMBLAUNCH GRID THEME 7 GPS 5 ZOOM 32 HEIGHT 800 TRACKLOOP 10 0 -1/10 ]]

Colour history
(click above to open LifeViewer)

If we wanted to globally change the THEME colours or GRID default we just edit "config/default". For example I quite like THEME 7 since it has colour history but it's not good for LOOPing patterns (since on reset there is no history).

Also just a note: as it stands EmbedViewer assumes THUMBLAUNCH in the config since the embedded Viewer has the text "click above to open LifeViewer". See the Waypoint example above. Chris Rowett (talk) 21:32, 26 February 2018 (UTC)

Hmm, so that THEME 7 LOOP issue is an argument for the ability to jump instantaneously to a waypoint at an arbitrary (X, Y, T) spacetime location, with non-zero T, and start the LOOPing from there. Dvgrn (talk) 04:20, 27 February 2018 (UTC)

Yes, perhaps a requirement for PLAYFROM and possibly LOOPTO commands. PLAYFROM would replace POIT as a non-POI specific version. LOOP or TRACKLOOP would loop back to the PLAYFROM generation. LOOPTO or TRACKLOOPTO would allow looping back to an arbitrary generation. Chris Rowett (talk) 07:15, 27 February 2018 (UTC)

Replying to Chris's earlier suggestion re: Template:LifeViewer config/default: I've gone ahead and created that, and made Template:InfoboxStart use it in addition to the more specific configurations. I also edited those to remove the common config. Some (/inductioncoil, /methuselah, /pattern, and /stilllife) are empty now, the rest just contain the AUTOSTART command.

The order in which the various bits of LifeViewer config are assembled in Template:InfoboxStart still needs reworking, I think, but that's something that can be tackled later. Apple Bottom (talk) 09:50, 27 February 2018 (UTC)

Looks good. I'd like to use [[Template:LifeViewer config/default]] in secondary illustrations in various articles like Tanner's p46 -- or I might make a [[Template:LifeViewer config/defaultactive]] and add the AUTOSTART. Not clear exactly how to invoke the template in that context. If someone does a sample The Right Way once somewhere, though, I'm a good copycat.

Also, what template changes need to be made so that RLE:Snakewithfeather_synth shows up as a "raw RLE" link in the Snake with feather glider synthesis section of the infobox? Up at the top of this thread it says "all we'd need to do is update the pattern templates accordingly"... Dvgrn (talk) 14:49, 27 February 2018 (UTC)

Re: using Template:LifeViewer config/default -- that should just require an edit to Template:EmbedViewer.

Re: "raw RLE" links for uploaded syntheses -- that'll require tweaking Template:PatternDownload.

Neither should be difficult to do, I'll see what I can do in a moment.

EDIT: done on both counts. Pages using Template:EmbedViewer will need to be updated so that LifeViewer doesn't throw a wobbly over THEME 6 overriding THEME 6, and all that. Template:PatternDownload seems to be working (see e.g. Snake with feather) -- knock on wood! Pages with on-wiki syntheses but no uploaded synthesis files are tracked in Category:Pages with raw synthesis RLE code but no uploaded synthesis files. Apple Bottom (talk) 09:17, 28 February 2018 (UTC)

Looks good. Can you add a newline so that, when you hit Ctrl+C in the launched LifeViewer, you get both #C comment tags at the beginning of two lines, instead of piled onto a single line? Not that it matters a bit, as far as functionality goes.

It appears there are seventy EmbedViewer uses that will need to be checked and have their viewerconfigs probably reduced. I just cleaned up Telegraph, and am planning to sort LifeViewer commands into some kind of standard-ish order for each use, while I'm at it. Probably AUTOSTART then THUMBSIZE then WIDTH then HEIGHT then ZOOM, then X then Y (if needed), then GPS 20 then LOOP (if any). Dvgrn (talk) 17:33, 28 February 2018 (UTC)

-- Hang on, though. Supposing one really wanted to use an embedded viewer with THEME 7, let's say, like the example above. How to avoid the ugly error, exactly? Do we need a LifeViewer with a SUPPRESS command, or a separate EmbedUnconfiguredViewer template, or what?

I'm finding that separating the viewerconfig from the article is significantly awkward, because to make a viewerconfig look just right I usually have to preview it many times. But I can't preview the RLE:pname page and see any changes on the [[pname]] article page...

So what I have to do is to create the RLE:pname page later. First I put rle= and viewerconfig= lines into the EmbedViewer curly braces, and preview and change viewer commands to my heart's content. Then cut the rle and viewerconfig lines and paste them into a new RLE:pname page (without the rle= and viewerconfig= tags, of course), and save that. Then preview one more time to make sure the article still looks the same, and save.

It's workable, but more than a little awkward, as I said. Not sure yet if it will make me reconsider the Grand Plan of moving viewerconfig lines into the RLE: namespace. Dvgrn (talk) 18:11, 28 February 2018 (UTC)

Yes looks like we will need SUPPRESS. I'll put it in the next build. We'll then need to update config/default to end with the SUPPRESS keyword. I'll keep you posted. Chris Rowett (talk) 21:38, 28 February 2018 (UTC)

Seems like we would only need SUPPRESS very rarely, e.g., for the broken LifeViewer above in this section, where we want to override a setting in config/default. No need to include SUPPRESS in the default string -- it would just suppress errors that you might want to see, like a setting at the beginning of a long config string duplicated by a setting at the end of the string. Dvgrn (talk) 22:58, 28 February 2018 (UTC)

The function of SUPPRESS would be to allow one overwriting of each setting defined in the commands before the suppress keyword. So if, for example, config/default specified [[ THEME 6 ZOOM 4 ]] I'd want to add SUPPRESS to the end of that because it's always OK for posters to override those default values and I don't want them needing to know about SUPPRESS to do so.

[[ THEME 6 ZOOM 4 SUPPRESS THEME 7 ]] would be valid.

[[ THEME 6 ZOOM 4 SUPPRESS THEME 7 THEME 4 ]] would throw the error "THEME 4 overwrites 7".

I wouldn't expect posters to use the SUPPRESS command themselves but there may be edge cases where that's valid and useful. Chris Rowett (talk) 04:56, 1 March 2018 (UTC)

SUPPRESS is implemented in LifeViewer Build 238. Test case is here. Chris Rowett (talk) 08:33, 1 March 2018 (UTC)

Excellent -- how do we get this on the wiki? I don't remember, is Nathaniel the only one who can touch the wiki's LifeViewer code, or do others have the necessary rights?

Not sure - I think Nathaniel has to do it. Looks like it's kept at http://www.conwaylife.com/js/lv-plugin.js. Chris Rowett (talk) 09:08, 1 March 2018 (UTC)

Dvgrn-- I've also added linebreaks to Template:EmbedViewer to hopefully help you with debugging, as you requested. Apple Bottom (talk) 08:53, 1 March 2018 (UTC)

LifeViewer build 238 is now up here and on the forums. You'll need to refresh your browser (on Chrome CTRL-F5). Release notes are here. Chris Rowett (talk) 05:21, 3 March 2018 (UTC)

Stability of Pentadecathlon IDs

Maybe I should be asking Heinrich Koenig about this instead of posting here, but here goes-- does anyone know whether Pentadecathlon's ID numbers are actually stable?

The reason I'm asking is that when adding missing info to some patterns, I come across three patterns (out of about three dozen) whose numbers on PD differed from ours. Our 44P12.2 is now 44P12.3; our 42P10.1 is now 42P10.3; and our 44P7.2 is now 44P7.3.

I moved the first two to match their new PD IDs, but not the third. After all, once is happenstance, twice is coincidence, but three times is enemy action; I figured I'd better make sure these ID numbers are stable/reliable to begin with. Apple Bottom (talk) 12:38, 25 February 2018 (UTC)

Category:Toplevel category

Following some discussion at Talk:AUTOSTART, I've moved a few categories from Category:Toplevel category to Category:Everything else -- several were already in both --, to make the decision of what's in the latter and what's in the former a little less arbitrary.

In fact, it should be pretty much entirely non-arbitrary now. Category:Everything else states that it "contains all pages that are not about specific patterns", so I moved all content categories collecting CA content (CCCCC?) to that category -- except for Category:Pattern categories, of course.

What's left in Category:Toplevel category now is the following:

• Category:Administrative categories -- self-explanatory, I hope; a 2nd-level root category for everything relating to the inner workings of the LifeWiki (the plumbing, as it were, as opposed to the porcelain).
• Category:Everything else -- CA-related content that isn't patterns.
• Category:Images -- self-explanatory.
• Category:Pattern categories -- self-explanatory.
• Category:Tutorials -- self-explanatory.

I left Category:Tutorials in Category:Toplevel category on account of its contents not describing CA-related subject matter, as such; I feel it should be treated the same as (say) Category:Images, which clearly also belongs Category:Toplevel category. (FWIW, I think Tutorials could actually well get their own namespace, but that's a different discussion.)

Long story short, I think Category:Toplevel category is much less cluttered now, and the placement of content categories is much less arbitrary. All we still need to do now is keep it that way. ;) Apple Bottom (talk) 15:56, 4 March 2018 (UTC)

Image generation and upload

I looked at Help:Images this morning, and I think it might make sense to do a complete rewrite. Rather than suggesting Golly and Print Screen as a source of screenshots, we should probably create a special page in some namespace or other, that has one or more NOGUI LifeViewers in it, and link to that from Help:Images.

(This is based on last year's discussion about using LifeViewer to capture images.)

The text of this hypothetical image-gathering page might suggest editing the page, replacing the sample RLE with the desired pattern, and hitting Preview (actually saving the changes won't be necessary). The page can include a list of the relevant LifeViewer scripting commands -- no waypoint stuff, but X Y ZOOM HEIGHT WIDTH, and how to hit 'I' to read that information after manually setting the view up exactly right.

When the image looks right, probably after multiple previews, a user can right-click and save it, then upload it to the relevant article.

bo$2bo$3o! #C [[ NOGUI THEME 6 GRID GRIDMAJOR 0 WIDTH 128 HEIGHT 128 ZOOM 12 ]]

... This is certainly somewhat simpler than fiddling with Golly settings to get the colors right, and for most small patterns it allows a wider range of sizes than Golly's simple powers-of-two system can provide.

Still seems like it could be easier, though! In particular, if you have the NOGUI command set, of course you can't adjust the view, and the 'i' information doesn't pop up. So you have to remove NOGUI and then add it back when you want the screenshot.

Any suggestions for how to capture an image without having to figure out the scripting commands or go through multiple Preview cycles to get everything right? Obviously plain Print Screen on the first Preview page is an option, as Help/Images currently suggests, but then it becomes necessary to edit the image in some Paint-type program.

Do all modern OSes have something equivalent to Windows' Snipping Tool, and we could mention those as a way to grab the image directly?

... Yes, in many cases we can now just use a NOGUI LifeViewer, and never upload an image at all. So we should say that clearly in Help:Images. But it's still good to have the option to upload images, for cases like the green-annotation image in Blockstacker. And it seems like a nice idea to have a static image available as backup, anyway, so let's not get rid of the "View static image" links yet!

The other awkwardnessfulmost detail is when you want to generate an image in a different-shaped rectangle than what the LifeViewer provides by default. You pretty much have to figure out the scripting system enough to add WIDTH and HEIGHT tags -- and if you've removed the NOGUI tag, as you kind of have to to do any experimenting, in many cases you'll fall foul of the mysterious minimum and maximum values allowed for LifeViewers with GUI controls.

I'm also fishing for options that might allow for dodging the two-step save-file/upload-file. Is there any way for this hypothetical image-gathering page to pop up immediately when someone clicks on an image redlink -- with a text box to paste RLE into, a LifeViewer frame that's resizable by clicking and dragging, and some button or link on that page that magically collects the current image from LifeViewer when the user says it's ready to be collected?

-- I think that would be just about the minimal, easiest to use design. What's the closest setup to that, that's actually practical to implement?

TL;DR: Sorry about the long essay. What exactly should the Help tell people about how to make standard LifeWiki images? Dvgrn (talk) 15:03, 5 March 2018 (UTC)

Good points all around -- perhaps the best solution would be to have an online RLE-to-image converter where people could simply paste an RLE snippet (or point to a remote RLE file to be fetched), and which would then spit out a bespoke image, suitable for immediate uploading to the LifeWiki (or further editing as desired). Something vaguely along the lines of Oscillizer is what I'm imagining there.

For extra brownie points, it could also offer a few form controls to tweak common options, such as live cell/dead cell/grid color, cell size, and so on; all with sensible defaults, of course.

Speaking of which, what should those defaults be? Cell size in particular -- right now quite a few still images (those I made anyway) are smaller than the animated ones, my thought at the time having been that they needed to fit into infoboxes without blowing those up too much. Now that we've entered the age of embedded LifeViewers, this isn't (that much of) a concern anymore.

I'm thinking 15x15 pixels for a single cell, plus 1 pixel for the border. Color-wise, we seem to have settled on (192, 192, 192) (#C0C0C0) as our border color of choice. We've also used (192, 239, 192) (#C0EFC0) as a light green color for highlighting cells, and (82, 192, 82) (#52C052) as a dark green, for the border of those highlighted cells:

Getting back to how to create images... I don't know what support the various OSes do offer. I do, however, think that a two-step process, where you save an image locally and then upload it in a second step, isn't that bad, so long as generating the image in the first place is easy, straightforward, fast, and convenient. (Ideally, all four!)

Oh, and experimenting with LifeViewer, its config commands, and the limits it imposes? Oh yes, I know exactly what you're talking about there! WIDTH and HEIGHT will surely be the death of me some day. :) Apple Bottom (talk) 22:00, 5 March 2018 (UTC)

EDIT: oh, and BTW -- perhaps in addition to a default size for images, we should define standard small(er) sizes as well? For instance, I'm imagining that Cathysuesamazingpattern.png might use 15x15 cells, whereas Cathysuesamazingpattern_small.png might use 7x7, and Cathysuesamazingpattern_tiny.png might use 3x3, all with a 1 pixel border. Or something along those lines, anyway.

This would make it easier to select the right image on-wiki when a specific size is needed, and it would also mean that we could keep all the current images using smaller (e.g. 7x7) cells; we'd just have to rename them. Template:InfoboxStart could easily be tweaked to display links to all sizes that exist, or only to the largest size that exists, or whatever else we might find best. Apple Bottom (talk) 22:04, 5 March 2018 (UTC)

Just because both of you mentioned it here are the mysterious LifeViewer width and height rules:

1. Common rules:

1.1 Width is always (silently) rounded down to a multiple of 8 pixels.

Why? Because it makes drawing faster.

1.2 Maximum width is 1024 pixels.

Why? Arbitrary decision. Could be any multiple of 8. Pick one.

1.3 Maximum height is 800 pixels.

Why? Arbitrary.

2. With GUI rules:

2.1 Minimum width is 480 pixels.

Why? Any smaller and the GUI wouldn't fit horizontally.

2.2 Minimum height is 480 pixels or 240 pixels.

Why? 480 for the full GUI to fit vertically. 240 if you don't mind losing the navigation controls.

3. NOGUI rules (for image display):

3.1 Minimum width is 64 pixels.

Why? No GUI to draw. Arbitrary.

3.2 Minimum height is 64 pixels.

Why? Seemed like a good idea to make it the same as the minimum width.

4. meta tag

4.1 Some LifeViewer settings can be set by putting a <meta name="LifeViewer" content=""> tag in the <head> section of the HTML page.

4.2 If the meta tag doesn't exist, or exists but has the word "limit" in the content="" string then the maximum width is constrained to the width of the element containing the pattern source (typically a textarea or similar containing RLE).

4.3 For the conwaylife.com forum the meta tag doesn't exist so all Viewers are limited to the width of the HTML element containing their RLE.

Why? It stops Viewers escaping out of the central column.

4.4 For the Wiki the tag does exist, but doesn't contain "limit", so the maximum width is not constrained by the HTML element containing their RLE.

Why? Because on the WIKI the RLE is typically not displayed.

5. Errors

5.1 If WIDTH or HEIGHT are specified outside of the ranges defined above then the window is sized to be at least the minimum width and height.

Why? So you can see the script error message.

6. Defaults

6.1 The default width and height for an embedded Viewer are the size of its HTML canvas element. Silently, the minimum width and height are enforced and the width is rounded down to multiple of 8. Currently, no maximum width and height are enforced - I suspect I forgot.

6.2 The width and height of the popup Viewer are fixed to be 560 x 480.

Why? The top and bottom row of GUI controls are 40 pixels each so the display area is 480x480 square.

Hopefully the rules are less mysterious now. Feel free to suggest better Arbitrary values or any other improvements. Chris Rowett (talk) 01:03, 6 March 2018 (UTC)

Thanks for the explanations! We don't have a Help:LifeViewer page yet -- making one is one of the many items on my to-do list --, but perhaps we could start one now, and seed it with this information.

While I'm at it, one question: when using THUMBLAUNCH, is it possible to independently set the width and height of the thumbnail, and the full viewer you get when clicking it? Getting the best possible viewer size/shape in pattern infoboxes can be fiddly, and I've found that playing carelessly with WIDTH/HEIGHT can make the full viewer look funny. Is there such a thing as THUMBWIDTH and THUMBHEIGHT? (If not, I think there really should be!)

Thanks for all your work on LifeViewer BTW, it really is an excellent piece of software to have, and makes Life (if not life) so much easier and more accessible to newcomers. Apple Bottom (talk) 10:20, 6 March 2018 (UTC)

There are actually two thumbnail commands: one for embedded Viewers: THUMBNAIL, and one for popup Viewers: THUMBLAUNCH. In both cases they render the Viewer at 1/2, 1/3 or 1/4 of its width and height depending on the value of "THUMBSIZE <2..4>". The default is 1/4 size ("THUMBSIZE 4").

The THUMBNAIL command will resize the Viewer in place when clicked. If you hover the mouse over the Viewer it will say "Expand". The Viewer can be returned to the thumbnail state with hotkey "n" or by clicking the shrink button (top left in the navigation menu assuming the height is at least 480).

bo$2bo$3o! #C [[ THEME 6 GRID GRIDMAJOR 0 WIDTH 640 HEIGHT 480 THUMBNAIL ]]

THUMBLAUNCH will launch the popup window. If you hover the mouse over the Viewer it will say "Launch". The popup Viewer size is fixed at 560x480 and ignores WIDTH and HEIGHT settings.

bo$2bo$3o! #C [[ THEME 6 GRID GRIDMAJOR 0 WIDTH 640 HEIGHT 480 THUMBLAUNCH ]]

So I believe that means you are free to use WIDTH and HEIGHT and THUMBSIZE to define the size of the thumbnail for THUMBLAUNCH, knowing that when clicked the popup Viewer will always be 560x480.

If you create a Help:LifeViewer page it's fairly likely I'll update it over time. There's already some documentation on the forum in the Pattern Viewer for forum threads thread. For example this post describes how to use LifeViewer in your own web page including details on the meta tag discussed earlier. There's also documentation in Golly for the Lua version of LifeViewer which is a subset of the HTML version functionality but still valid. Chris Rowett (talk) 10:59, 6 March 2018 (UTC)

I like defaulting to the pop-up LifeViewer for wiki purposes, mostly because it doesn't force an ugly re-flow of the text around a thumbnail image, and it's guaranteed to appear always in the same place and entirely on the screen (unless you're looking at a very small screen). The inline viewer that shrinks and expands is often more annoying to use in wiki articles, because either

1. the Play/Pause controls at the bottom expand to offscreen and you have to scroll to get to them;
2. the Play/Pause controls are visible, but the very top of the viewer is offscreen, in which case the first click on the viewer moves the Web page so that the whole viewer is visible, but doesn't actually activate the control you clicked on. And now whatever you clicked is suddenly not under your mouse any more, so you have to go find it and click again.

The popup viewer is a bit taller than it is wide, so 480x560. This does cause some trouble on very small laptop/tablet/phone screens when the window is 480 pixels high -- you have to scroll to make the controls usable. I wonder if it would make sense to reduce the popup window to a square 480x480?

Along the lines of Apple Bottom's THUMBWIDTH and THUMBHEIGHT comment above, I've sometimes wanted to set the popup viewer to landscape format, so to speak. E.g., when opening the secondary illustration in Telegraph, you don't really need the extra height, but more width would be okay. I guess this would really be POPUPWIDTH and POPUPHEIGHT, since the thumbnail size is specified by regular WIDTH and HEIGHT.

I would like to bump up the maximum height and width, to be able to use LifeViewer in more or less full-screen mode. 2048x1600? Or is there any downside to just saying something like 4096x4096, with the understanding that if that causes memory issues then that's the problem of whoever set the size that big? Dvgrn (talk) 16:35, 6 March 2018 (UTC)

I like the idea of POPUPWIDTH and POPUPHEIGHT. That would also solve the popup height (560 pixels) since you could put POPUPHEIGHT 480 in config/default if you wanted it to be a site wide standard.

I'll increase the maximum width and height to 2048. Though I'll probably cap it at the actual screen size or we'd be in Viewer half off screen purgatory.

The issue with clicking on a Viewer that's half off the screen is thorny. I remember taking a brief look at it a year or so ago when you last mentioned it. I'll take another brief look. Perhaps two brief looks is enough for inspiration to strike. Chris Rowett (talk) 18:15, 6 March 2018 (UTC)

The second brief look was fruitful. See if you like the behaviour in build 241. Click on a Viewer that's not fully scrolled onto the window. Chris Rowett (talk) 20:54, 6 March 2018 (UTC)

I've added POPUPWIDTH and POPUPHEIGHT in Build 242. Test cases are here. Chris Rowett (talk) 21:39, 8 March 2018 (UTC)

Wonderful, thanks. :) (I'll still need a tutorial at some point so I'll understand how to give the LifeViewer the right size, e.g. in infoboxes...)

Other things I noticed earlier today: there's some arbitary (?) limits left. "ZOOM 64" produces an error, as does "WIDTH 400". And "GRID" cannot be overridden, AFAICT; there's no "NOGRID". Apple Bottom (talk) 12:14, 10 March 2018 (UTC)

For InfoBox I think you just need to set WIDTH and HEIGHT to 4x the size you want (since it uses THUMBLAUNCH which will divide the defined size by 4 by default, or by 2 or 3 if you specify THUMBSIZE 2 or THUMBSIZE 3).

ZOOM is limited from 1/16x to 32x

WIDTH and HEIGHT are limited as described in detail above (see the mysterious LifeViewer width and height rules)

Correct, GRID can not currently be overridden. There are a number of commands like that (for example AUTOSTART). They were defined that way since the LifeViewer default is OFF, so all I needed was something to switch various modes ON. On the Wiki we now have config/default which defines GRID (ON) so I'll have to add GRID OFF to compensate. I already added STOP OFF and LOOP OFF in a previous build. Chris Rowett (talk) 14:24, 10 March 2018 (UTC)

AUTOSTART OFF and GRID OFF are in Build 243. Chris Rowett (talk) 14:43, 10 March 2018 (UTC)

Wonderful, thanks. I love how quickly you always implement new things! Now we'll just have to wait for this build to be available on the wiki. (Or does the wiki automatically use the latest these days?) Apple Bottom (talk) 19:41, 10 March 2018 (UTC)

No, that's still something that someone has to get Nathaniel's attention for. That usually doesn't take too long. But now I think we're waiting for a few more minor alterations and a Build 244.

Meanwhile, the addition of a waypoint script in the 2-engine Cordership article has exposed a flaw in the idea of including viewerconfig lines at the bottom of the pattern text in the RLE: namespace. As things are now set up, the default config line #C THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH is intended to show up before any overriding commands in the RLE:pname text. But as you can see if you launch a viewer on the slow-salvo pattern and hit Ctrl+C, the default config is currently being appended to the end of the RLE text.

The obvious way around this is to put the default config first, so it shows up as an initial comment line. But that's kind of non-traditional, not to say ugly, since it puts the LifeViewer command lines in two widely-separated places.

I had to make multiple edits to the viewerconfig to get things looking okay, mostly because there's no reasonable way to preview before saving changes. I'm pretty close to being persuaded that it's just plain not that good an idea to include viewerconfig lines in the RLE: namespace. It's much easier to fix and test viewer behavior if the commands are in a viewerconfig= line in the article itself. Thoughts? Dvgrn (talk) 21:55, 11 March 2018 (UTC)

Without having taken a close look -- I'm not sure I see the problem with ugliness you're mentioning. The RLE snippet from the RLE: namespace is a "black box" as far as assembling the RLE (including all the various viewerconfig lines) passed to LifeViewer is concerned, isn't it? Where inside that black box the snippet-internal viewerconfig line is found shouldn't matter -- right?

But you're the LifeViewer wizard, not me, and I'll defer to your superior experience. :) If you think keeping viewerconfig lines out of RLE: snippets, I'm fine with that. If you think we can make including them there work, that's fine with me as well. Apple Bottom (talk) 09:51, 12 March 2018 (UTC)

Yeah, true, it doesn't matter a whole huge amount. I've gotten in the habit of putting viewerconfig lines after the RLE, away from the other comments and all together in a consecutive series of lines. But they can equally go in as the first lines in the RLE: snippets, and then the default config could be dropped in ahead of everything and it would all end up reasonably readable.

The main reason to put viewerconfig= back into the article text is that it makes it significantly easier to explain in the Help how to use LifeViewer. Put in viewerconfig=something, hit Preview, keep previewing until it looks right, and then save.

Otherwise, especially if you want to adjust a viewer that already has viewerconfig in its RLE:pname page, it's a big pain to test changes -- either save the RLE:pname page multiple times and refresh the article page each time until you get it right (this can take dozens of test cycles for a good animation)... or take out the viewerconfig lines temporarily, put them back in the article under viewerconfig=, preview there, and then finally copy the successful viewerconfig back into the RLE:pname page and save again.

Those methods aren't all that difficult really, but they seem like an unnecessary barrier to successful editing, for people who might want to learn how to use LifeViewer.

If it's easy to adjust the template to put the default config first, before the RLE:pname content, then maybe I should try playing around with that for a while before deciding to banish viewer config back to the infobox (or EmbedViewer) section again. But really it seems pretty clear that the advantages of keeping the viewer config with the article outweigh any disadvantages. Bonus: we'll be back to not needing multiple copies of the same RLE to use it multiple different ways, or in different articles. Dvgrn (talk) 16:50, 12 March 2018 (UTC)

Permission to edit high-risk pages

Talk:Main Page has apparently been protected from recreation due to too much spam in 2010, and the main page itself, as well as LifeWiki talk:Did you know/35‎ are protected as well, conceivably for the same reason. But since editing has been generally restricted in 2016 to "trusted" users only, this appears not necessary anymore. Could those pages now be allowed to trusted users, please? Micromegas (talk) 00:51, 11 March 2018 (UTC)

Strange, but Talk:Main Page doesn't show up on Special:ProtectedPages. I'd have unprotected previously otherwise, there really is no reason for it to be protected, especially in this day and age of "trusted" flags. If you come across any other such pages, let me know.

LifeWiki talk:Did you know/35 is not protected, but LifeWiki:Did you know/35 is, by virtue of cascading protection: any pages transcluded on the Main Page (which is protected with cascading protection enabled) are automatically protected as well. This is by design so that protected pages cannot be edited "through the back door", as it were.

I'm not going to unprotect the Main Page itself; even in the absence of spammers and with only good-faith editors around, there's several I don't trust to exercise the necessary care. But editing the Main Page or its transclusions should be a rare event in any case, and you can always ask a sysop to do the necessary edit. Apple Bottom (talk) 09:51, 11 March 2018 (UTC)

Image update

Can someone update File:Spaceship ford circles.png to include c/10, 3c/7 and 31c/240? It may also be worth colouring in all circles below c/4 a dark yellow, signifying their existence as trivial caterloopillar constructions.

In addition, could diagonal and knightship variants of said image be created? - AwesoMan3000 (talk) 16:57, 12 March 2018 (UTC)

Redirects

Apologies if I am asking this question in the wrong place, but how do I create redirects? I recently got into LifeWiki and there doesn't seem to be any formatting tutorial... Cognaso (talk) 01:12, 16 April 2018 (UTC)

Like this:

#REDIRECT [[Target article]]

Yeah, our help/project pages are not as complete and all-encompassing as they should ideally be. So in general you may want to look at the documentation on meta.wikimedia.org, or on the English-language Wikipedia. The latter also has a handy cheatsheet for common formatting. Some of it may be project-specific of course, e.g. certain templates, or syntax relying on extensions we don't have installed on the LifeWiki. (I don't think you'll be able to enter hieroglyphs here, say, not that I've tried.) Apple Bottom (talk) 08:45, 16 April 2018 (UTC)

Conduits and converters

I'm gradually gathering the necessary courage to tackle the new Life Lexicon items that start with "P". Looks like one of the big things I should do is to carefully figure out how to make proper use of Template:Reflector, but in this modern LifeViewer age I don't think I agree with the part about "The image in this infobox should NOT include the glider that is to be reflected...".

Seems to me these template recommendations should be updated to say something like "The image in this infobox should include the glider that is to be reflected -- optionally, two input gliders separated by the mechanism's minimum recovery time, and an output glider if that allows a smoother animation. However, the bounding box and population count should be calculated with these gliders removed."

It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to go. When copying and pasting one of these to use in a larger construction, it's usually pretty handy to have some kind of marker for where the the input goes and where the output comes from -- thus the ghost Herschels in recently added Herschel conduits.

[Ideally the marks are state-4 LifeHistory so you don't have to edit them out after pasting -- but we should probably stick with simple 2-state Life patterns on the LifeWiki and not open the LifeHistory can of worms.]

... And we can probably get rid of Template:Reflector/Doc while we're at it, no?

Before I start this I'll definitely undertake to review all the existing converters and reflectors and conduits -- there are a bunch with raw RLE and/or uploaded pattern files missing. That's relatively easy to fix, once we have an official decision about whether and how to show inputs and outputs. I'm currently puzzled by the mysterious Template:ConduitInput and Template:ConverterInputOutput. Not that that's surprising -- I'm easily confused by all this wiki template trickery. Dvgrn (talk) 15:26, 8 May 2018 (UTC)

I agree that reflector patterns should include the input glider. I'm the one who originally wrote that they shouldn't, and I'm not really sure why anymore. It can't have been very good reasoning, because I completely disagree with it now.
~Sokwe 07:08, 9 May 2018 (UTC)

Template:Reflector/Doc also asks users not to put animated images on pages, instead suggesting that one should "consider using a static image of the reflector with a caption that links to the animation". I think this does not match the general current LifeWiki practice regarding animated images, or generally animated content. Should we reconsider? Apple Bottom (talk) 05:25, 7 June 2018 (UTC)

It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to go. There are quite a few Help documents and templates that were written long before the advent of LifeViewer. I'd love to have the Help actually explain to a new user how exactly to add RLE to the RLE namespace, how to get that RLE to show up in an infobox or an embedded viewer, how to adjust the LifeViewer config so that animations (if any) look good, etc. It will take a while to get all the docs updated, no doubt. My edit yesterday was just a first attempt to start chipping away at the problem. Dvgrn (talk) 14:48, 7 June 2018 (UTC)

Definitely agree! Unfortunately writing documentation is one of things I'm hopelessly.. well, hopeless at. ;) Apple Bottom (talk) 10:33, 9 June 2018 (UTC)

Lexicon tags

Many of our articles (glossary, in particular) are based on, or at least synced with, Life Lexicon content. This creates a need to update these articles when the Lexicon changes.

Some of that has been handled in an ad-hoc manner on my userpage, but the process is fairly involved: look at the project page, find an article to work on, make sure it needs to be worked on, make the necessary edits, make the necessary changes to the project page to reflect the fact you edited the article.

It's also not easily found by newcomers who may want to help out. (OK, I'll admit, there likely aren't droves of eager newcomers to begin with, but that nonwithstanding, if you don't know said page exists you're not going to find it easily.)

So I was thinking, can't we improve on this? And I just had the idea of tagging articles themselves instead, indicating which version of the Lexicon they correspond to.

The Nethack wiki does something similar; for instance, take a look at their Foodless article, and you'll find that it has an indicator at the top right saying that the page reflects Nethack 3.4.3 (rather than the current 3.6.1), generated by this template.

We could use something similar. There wouldn't necessarily have to be a visible indicator (though there could be); at the very least, though, pages could be tracked in appropriate categories, and we'd know at a glance what needs to be updated (or at least reviewed) and what's current.

This way, all edits would be in one place: review an article and make edits as necessary, and also update the tag to indicate it now reflects a newer Lexicon version. And placing those tracking categories into an appropriate supercategory and placing that in the existing category tree in turn would allow editors interested in helping out find articles in need of review.

There would be two downsides. a) most of the Lexicon doesn't change in each Lexicon release, so we'd have a lot of articles tagged as (say) reflecting v28 when in fact they're also current, by virtue of not having changed since v28. And b) we wouldn't easily be able to see which articles are missing from the wiki entirely.

I still feel that this would be an improvement though, and there's no reason we couldn't combine these tags with a manually-curated project page to get the best of both worlds.

Also, re: downside a) specifically, I think this could be dealt with by also having an indicator on the wiki saying which Lexicon release is current; pages that haven't been tagged as reflecting the current version would then display a gentle, unobtrusive note, and anyone viewing such a page could quickly check that it does indeed match the current Lexicon release, and update the tag if so.

Thoughts? Apple Bottom (talk) 07:49, 18 July 2018 (UTC)