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)

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)