LifeWiki:Tiki bar

From LifeWiki
Revision as of 17:15, 28 March 2019 by Moosey (talk | contribs) (Non notable isotropic rules -> user namespaces)
Jump to navigation Jump to search
Taka Tiki Break

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

Welcome to the Tiki bar

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

Archived discussions

Note: active discussions are never archived while still active.

The list(s) of rules investigated on Catagolue

Short version: these have increasingly become a burden to maintain on-wiki, and with Catagolue now having its own endpoint providing an overview over and an exhaustive list of all rules searched, they're largely irrelevant now. (The on-wiki list was only started because Catagolue didn't provide one at the time.)

So I'm giving up maintainership of these. If anyone wants to take over, please do! Apple Bottom (talk) 17:00, 7 January 2019 (UTC)

If we are to retire the List of rules investigated on Catagolue, how should we do this? Add a notice at the top saying:
"This page is no longer actively maintained in favour of the equivalent Catagolue page."
or words to that effect?
It still might be a good idea to actually keep the information in the LifeWiki, because Catagolue occasionally has outages when the daily quota has been exceeded, whereas tends to be permanently accessible. Calcyman (talk) 18:26, 7 January 2019 (UTC)
The wiki page does have some advantages over the Catagolue one, such as listing the rule integers for outer-totalistic rules and being easier to edit (e.g. adding names for new rules). 77topaz (talk) 23:51, 7 January 2019 (UTC)

Time for a consensus decision on pnames?

I've run the RLE-scraper script to collect new RLE files for a bulk upload. The script found 321 new RLE files. Before I send them to Nathaniel, it looks like I'll be doing some more standardization, especially involving pnames.

The guidelines for creating pnames say very clearly:

pname	(required) The name of the pattern being described, but converted to lowercase and with all non-alphanumeric characters and spaces removed.

This has worked fine for us for the great majority of cases, but there are two related cases where blindly following that rule creates not-very-good pnames:

  1. apgcode-based names, where removing the underscore can sometimes concatenate two strings of digits. For example, according to the rule, Xs15_3lkia4z32 is theoretically supposed to have a pname of "xs153lkia4z32", which reads as if it's a 153-bit still life. Underscores are confusing in article names because MediaWiki turns right around and renders the name without an underscore. But they do seem to work fine, and they're necessary in other article names, anyway -- raw RLE "pname_synth" synthesis files need them.
  2. patterns named after a Niemiec or ID, where removing a period causes similar problems with readability. Examples:
  • 37P7.1, created by Sokwe in 2009 with a pname of "37p7.1" -- including the period. Another similar case is 37P10.1, where Sokwe changed the pname from Nathaniel's original "37p101" to "37p10.1", back in 2010.
  • 38P11.1, with a pname of "38p111". Periods in filenames are definitely annoying because the part after the period can look like a file extension... but I think "38p11.1" would really be better here.
  • Several patterns with pnames created by Entity Valkyrie recently: 14p2.1, 14p2.3, 14p2.4, 28p7.3, 28p7.3bumperbouncer, 28p7.3eatingss, 31.4, 33p3.1, 33p3.1bumper, 33p3.1eatingss, 33p3.1reactions, 34P6.1.

Capitalization Bad

The last pname in that list is also nonstandard due to capitalization, but that's a separate problem. The full list of capitalized pnames is 35P12, 53P13, 55P10, 113P18, BF20H, BFx59Hinjector, FMHEB, Gtolwss.rle, L112functions, L156reactions, L156variants, L200, Lightspeedcrawler, P5HWV, P58toadflipper, PT8P, PT9B, PT38P -- again all by Entity Valkyrie, I think. I'll definitely have to go through and fix all of these, just because they're dangerous to cross-platform uses of the pattern collection: "35P12.rle" will overwrite "35p12.rle" on a Windows operating system, but not on Linux. And LifeViewer fails to find "RLE:35P12" when told given "pname = 35p12", because the LifeWiki's filesystem is case-sensitive. So I think the no-capitalization part of the pname guidelines should continue to be very carefully enforced.

Periods Not So Bad

However, given the long precedent for pnames occasionally including periods, I'm not planning to change any of Entity Valkyrie's pnames if a period is the only non-standard part. Should probably do something about "31.4", but the rest seem okay.

-- Anyone know where the ".4" comes from in "31.4", by the way? The problem with calling the thing just plain "Snark catalyst" is that there are several workable Snark catalysts. 31.4 is one of the two most common ones, but it's not exactly "the" Snark catalyst. But no other common name has caught on. (Bellman Zero, anyone? Catalyst B0? 31.4 seems better than either of those.)

Summary questions

TL;DR: Does anyone object if I adjust the pname guidelines to say that periods are okay, but "only where necessary", or something along those lines? And also say that underscores are okay only in apgcode pnames and raw-RLE _synth articles? Underscores are a minor nightmare, because MediaWiki automatically converts them into spaces, and pnames really aren't supposed to include spaces. I'm reasonably sure that that underscore-to-space conversion is bound to cause coding difficulties somewhere sometime. But unless someone wants to recommend consistently using periods in place of underscores in apgcode pnames, I just don't see any good alternative.

Comments, suggestions, disagreements? Please post 'em here! Dvgrn (talk) 17:56, 15 January 2019 (UTC)

Also, not sure if anyone will find this note here, but gmc_nxtman's recent series of synthesis postings made for a good test case for reworking several pages recently updated by AwesoMan3000. It's been different changes for every article, but it tends to take a lot of fiddly adjustments to synchronize the pname, RLE, synthesis RLE, LifeViewer config, and any files already uploaded to the LifeWiki server.
I've done half a dozen articles for starters: very long snake, trans-block on long hook, integral with tub, eater head siamese eater tail, cis-block on long hook, and aircraft carrier with feather. LifeViewer generally Just Works once there's a raw RLE article with the right pname, but the images come out too small by default, so I've been adding viewerconfig THUMBSIZE 2. This should probably be a default added to the template, with SUPPRESS, except I don't know if that will change the looks of a lot of existing articles).
This leaves boat with long tail, beehive with nine, broken snake, cis-boat with nine, eater bridge eater, long boat tie ship, long shillelagh, ortho-loaf on table, snake siamese snake, snake with feather, snorkel loop, trans-boat on table, very long shillelagh, and sesquihat that still need editing to add the latest syntheses. I could definitely use some help with updating these:
  1. decide whether the pname should change to match the article name
  2. new synthesis copied from Talk:{name} to RLE:{pname}_synth, either updating or replacing any RLE that's currently there
  3. fix "synthesis = {n}" in infobox
  4. add to infobox:
    viewerconfig     = [[ THUMBSIZE 2 ]]
  5. remove Life1.05 and Life1.06 lines (optional)
  6. double-check that article name matches article text and Catagolue link -- there's often something wrong there
  7. add RLE:{pname} if it's not there already, to make LifeViewer show up instead of an old image file
A couple other tasks are admin-only --
  1. If pname has been changed, delete {old pname}*.rle from LifeWiki server to keep things in synch
  2. If Life1.05 and Life1.06 lines have been removed, delete corresponding files from server. (I'm leaving the "plaintext" (.cells) links, because I'm hoping to generate those automatically for all sub-64x64 patterns currently on the LifeWiki.)
  3. When a good break point is reached, re-run the auto-upload script and collect all the new pattern and synthesis RLE text into a ZIP file for bulk upload.
Here again, I'm leaving some broken links to pattern or synth files, which I'm planning to fix fairly soon (by putting the files back in place using the auto-upload script).
This is the kind of project where I'm very unlikely to get everything exactly right. Independent reviews of all this stuff will be greatly appreciated, and just let me know what I've done wrong so far. Dvgrn (talk) 12:33, 21 January 2019 (UTC)

Special pages broken?

I have noticed several oddities in a few of the maintenance pages:

Anyone know what's up with these? Ian07 (talk) 23:35, 15 January 2019 (UTC)

Rulespace info for eaters, reflectors, conduits, etc.

So lately I've been busy adding isorule parameters to the infoboxes for various patterns. So far I've stuck with oscillators, spaceships, still lifes, and infinite growth patterns, but I'd also like to expand this to other pattern such as conduits which are a bit more ambiguous. For example, the sidesnagger works in B/S23, but obviously there are no gliders for it to eat. I'm of the opinion that for these patterns we should show the rules they're actually useful in, since that's what makes them notable in the first place, (though with the possible exception of eater 1 since it's such a small pattern) but I'd like to hear others' thoughts on this. Ian07 (talk) 18:57, 19 January 2019 (UTC)

My main thought is that all but the very simplest and lowest-step-size conduits are very close to rule-specific -- useful only in B3/S23. Adding a B8 or an S8 might be one of the few isotropic bits where some conduits would survive the rule switch (?). Even if a particular conduit works in another rule, it's only interesting if a large enough group of conduits works in the alternate rule to make it computationally universal. (That would probably make it construction-universal, too, but only after someone re-did all the single-channel search work to produce new recipe libraries.)
Anyway, from my point of view the reason why B38/S23 or B3/S238 doesn't get a lot of attention is that there's nothing really new and exciting about those rules to make up for the fact that the rule spec is just that little bit more complicated... pun maybe intended. Dvgrn (talk) 02:04, 20 January 2019 (UTC)

apgsearch and Catagolue

Would anyone be opposed to a reorganization of the information on these two articles? I noticed that a lot of the information in the Catagolue article really applies more to apgsearch rather than the site itself, and therefore might be worth moving. Such a change would be particularly easy to revert if need be, but I'd rather not go through the effort if that's the case, so I'd also like some feedback about that. Ian07 (talk) 23:32, 19 January 2019 (UTC)

No opposition here. I wouldn't think anyone would be likely to revert changes to those articles, just the usual quick review to see if the changes happen to serve as a reminder of anything else that should be added. Dvgrn (talk) 02:04, 20 January 2019 (UTC)

Pattern collections

I just thought to check the LifeWiki pattern collection for outdated links to Mark's database. There were 165 RLE files with dead links in the comments. I fixed two of them, one by creating an RLE:{pname}_synth page and one by editing the pattern comments and deleting and re-uploading the file by hand... and then thought, "Nope. There has to be a better way."

Now I'm just doing a search-and-replace, "" instead of "", and will ask Nathaniel to re-upload all those files to the server along with the output of the auto-upload script.

Of course, if these _synth files were created when that website was available, a lot of the actual syntheses might be out of date as well. A dynamic endpoint somewhere for reporting the actual latest synthesis for each object would certainly be a step up from the current perpetually out-of-date synthesis files.

-- On the other hand, there are big advantages to Mark's comprehensive collections of practically every historically known way of constructing each object. Sometimes you might want a synthesis with a suboptimal number of gliders but better clearance than usual, or might want an incremental construction starting from one half of the still life, or whatever. Reporting just a single current-best synthesis would lose a lot of that useful information. Dvgrn (talk) 22:25, 24 January 2019 (UTC)

The problem of deciding what to do about glider syntheses is still where it was in January. I'm still leaning toward leaving things pretty much as they are until Mark Niemiec's new synthesis database becomes available, and then figuring out how to link directly to the relevant Niemiec synthesis page, for any object that has a LifeWiki article -- and removing those _synth files from the Patterns folder. Most of the Niemiec-derived _synth files that have been uploaded will probably be subtly out of date when the new version comes out. Anyone have any better ideas?
In other news, User:Dvgrn/Plaintext_files documents the 695 new plaintext-format .cells files that are available on the server now. This means that a lot of articles' infoboxes could now be updated to say |plaintext = true along with |rle = true. If nobody wants to tackle making these several hundred edits manually, I might eventually look into setting up some kind of automated search-and-replace functionality, based on this kind of article list. Dvgrn (talk) 22:45, 17 February 2019 (UTC)
I noticed once again that there are quite a few patterns with capitalization in their names, most of which (with a few exceptions) were created by User:Entity Valkyrie. Even RLE:ModelD is still in that list despite having been deleted and moved over a week ago, so those should probably be fixed. Something more confusing, though, is that certain small patterns (such as 44P14 and 44P12.3) were labeled as being too large despite easily fitting within the 64×100 limit. What's up with that?
As for adding these to the infoboxes, I'll probably get to that eventually but I'm a bit too busy at the moment. Ian07 (talk) 23:14, 17 February 2019 (UTC)
Many thanks for the review. I believe I've patched all the remaining instances of pnames with capital letters: 68p16.cells/.rle, 76p8.cells/.rle, 113p18.cells/.rle, 209p8.cells/.rle, p130shuttle2.cells/.rle, l156reactions.rle, p24lwss.rle, and p52g3to4.rle. Obviously in the future the auto-upload script should check for capital letters and complain.
I haven't yet looked into why a few small patterns didn't get .cells files created properly. Will figure it out and fix that bug along with adding the capitalization check. That one isn't too worrisome -- anything that got missed in the first round we should be able to pick up on the next auto-upload. Dvgrn (talk) 19:54, 18 February 2019 (UTC)
The missing small files that were flagged as "too big" seem to have been mostly due to patterns with no header lines in the RLE namespace. I think I've fixed all of those now. A few such files managed to get themselves uploaded to the LifeWiki server, but the auto-upload script now reports those when it sees them, so I think those are all cleaned up now also.
As before, if anyone wants to add "plaintext = true" to the many articles where that's missing, please go right ahead. The latest auto-upload script report has been added to User:Dvgrn/Plaintext files, so the dump of newly added .cells files there can be used as a checklist. There's also the option of adding plaintext file links to embedded viewers as appropriate. I did a couple of samples, e.g., 68P9 -- it's pretty easy. It should always be just a matter of adding this to the caption:
[{pname}.rle RLE format]
[{pname}.cells Plaintext format]<br />
Maybe this is something that should be done with a template, to make things even easier?
The script now also checks for pnames with uppercase letters and complains about that. I don't think there are any of those at the moment. If anyone sees other problems or oddities that the auto-upload script should be catching but isn't, or if there are any other surveys or reports that it should do while it's running through all the articles anyway, please make suggestions here. Dvgrn (talk) 15:09, 27 March 2019 (UTC)
I just modified Template:EmbedViewer to link to the RLE and Plaintext automatically. The biggest problem with this, of course, is the larger patterns don't have a plaintext file. I'm not sure how to elegantly deal with this, unless there's a way to make it read the RLE header and find the pattern size or something. Ian07 (talk) 19:55, 27 March 2019 (UTC)

Help Wanted with templates and general review

Here are three problems that I'd like to fix. I could probably track down the necessary template changes myself, eventually, but I'd like to have expert advice if I can get it. Both of these items have been sorta kinda mentioned on the Tiki Bar before, fairly recently:

1. I think THUMBSIZE 2 should be the default for all infobox LifeViewers. I keep adding #C [​[ THUMBSIZE 2 ]] to get infobox pattern frames back to the right size. There seem to be hundreds of these THUMBSIZE 2 specifications by now, but looking through a bunch of new aircraft-carrier-themed still lifes that AwesoMan3000 added recently (see links a few paragraphs up)... those all need the same addition done to them, and there are dozens or hundreds more existing articles that still have the same problem. The SUPPRESS command should follow THUMBSIZE 2, so that the relatively few viewerconfigs that specify THUMBSIZE 3 won't start throwing errors after the change is made.

2. As of this morning, Nathaniel has officially removed the Life 1.05 and Life 1.06 patterns from the LifeWiki patterns directory. That means the infobox template probably ought to be adjusted to stop showing those links. We could remove "|life105 = true // |life106 = true" from all the articles that have those infobox parameters instead, but only if someone wants to get a leg up on entry into the 10,000 Club.

The Life 1.0x patterns are still on the server, but hidden in a ZIP file. It seems to me that going forward, the way to make patterns available in non-standard non-RLE formats will be to publish conversion scripts that work on the contents of

Anyway, there are some places in the infobox template documentation and other docs that mention Life 1.0x, which I can track down and fix eventually if no one else gets to it first.

3. Let's get rid of that dependency where you have to have rle = true or nofile = true before LifeViewer will show up -- as per Nathaniel's recent advice. Dvgrn (talk) 15:51, 25 January 2019 (UTC)

Okay, Nathaniel has done a bulk upload of 387 RLE files, collected by the auto-upload script for every article in the main namespace that referenced a pname and had RLE:{pname} and/or RLE:{pname}_synth articles in the RLE: namespace. That means that as of today, there should no longer be any broken RLE pattern download links (the ones that show up when you say rle = true in the infobox).
There shouldn't be a lot of broken synthesisRLE = true links, either, but those might happen if somebody set that flag to true but then didn't create the RLE:{pname}_synth article.
I'd suggest that people shouldn't go too wild uploading new glider syntheses, until the next version of Mark Niemiec's database comes out -- and maybe not even then. It would be nice to come up with direct dynamic links to synthesis patterns on Catagolue and/or in Mark's database, so that we don't always have slightly antiquated information copied from those places and uploaded to the LifeWiki pattern collection, where they're kind of hard to keep up to date.
I guess the next item to tackle is automatic generation of the plaintext = true .cells files for every article about a pattern that's 64x64 or smaller (let's arbitrarily say). Does anyone have suggestions for other checks and auto-updates that the uploader script might be able to accomplish? Dvgrn (talk) 04:25, 27 January 2019 (UTC)
@Ian07: Wow, that was a lot of fast Life 1.0x cleanup work. Thank you! I'll see if I can get a bulk upload done for .cells format soon, for all sufficiently small patterns (which is most of them). Then the LifeWiki will suddenly be following a standard policy on pattern formats, fairly universally across all articles. Dvgrn (talk) 20:49, 28 January 2019 (UTC)
I've just added THUMBSIZE 2 as a default option for the viewers to save myself some trouble. As for item #3 in your list, the solution probably in Template:InfoboxStart though I'd rather leave that to someone more experienced with templates. Ian07 (talk) 22:12, 13 February 2019 (UTC)

Replacing images with animated viewers

I just started on a project to add more animated viewers in place of static images on the wiki. However, I've already started running into some problems, particularly with the pushalongs in the 114P6H1V0 article. I already created an RLE:114p6h1v0pushalong, but I'm not sure how exactly the comments in the RLE:pname page get translated to the actual files, especially since files like block.rle have comments that aren't in the RLE namespace. I'm worried that I'll unintentionally remove said information from the wiki's pattern collection if I'm not careful.

I'm thinking it might be better for now to just focus on the infobox images and not worry about the rest of the article, especially considering the images in the article have colors and arrows and other things which might be lost with an animated viewer. I'd be perfectly fine with RLE:114p6h1v0pushalong being deleted for the time being so it doesn't replace 114p6h1v0pushalong.rle in the next bulk upload.

Even then, though, as with the Block example above, there's still comments in the original files that may or may not be overwritten since I don't know how bulk uploads work. I'd basically just like to know what precautions to take to make sure I don't break anything with this project before I proceed. Ian07 (talk) 16:06, 2 February 2019 (UTC)

All good questions. The main answer is that the auto-upload script is designed so that it never overwrites any files that are already on the LifeWiki server, so you don't have to worry about overwriting anything. Comments in block.rle are safe, and the addition of RLE:114p6h1v0pushalong won't damage the existing uploaded file on the server.
Now, if we deleted 114p6h1v0pushalong.rle from the server, and added these two comment lines at the top of RLE:114p6h1v0pushalong --
#O Hartmut Holzwart
#C A pushalong for the c/6 orthogonal period 6 spaceship 114P6H1V0.
- then the auto-upload script would regenerate a fairly close copy of the file that we deleted. The #N line would be a little different since the default is now {pname}.rle, and the script produces two URL lines instead of just one: a link to the article followed by a direct link to the (future location of the) file itself on the LifeWiki server.
So far I've always looked through the RLE files produced by the script, and hand-edited anything that didn't come out quite right -- order of comment lines, etc. That's probably a tradition that I'll continue, so that's another line of defense against accidental damage. With any luck the next run won't be quite so much work, as long as no one goes back to uploading new headerless RLE or other nonstandard stuff that the script doesn't know how to clean up.
See also User_talk:AwesoMan3000#Standardization_of_comment_lines for a summary of what should, or could, still be included in comment lines, versus what is auto-generated. Maybe after that summary gets a good trial run, I can migrate it into the actual documentation. It will be strange and wonderful for a new LifeWiki editor to actually have a reasonable way to learn how to add new articles with associated LifeViewer-displayed patterns... the docs have been partly stuck in 2009 ever since, well, 2009 I suppose! Dvgrn (talk) 04:07, 3 February 2019 (UTC)
One more detail that isn't clear from the above:
The auto-upload script will automatically generate a slightly nonstandard #O line including both the discoverer and the discoveryear from the infobox -- like
#O Paul Tooke, 2008
for the 114p6h1v0 article. But that only works for patterns that have infoboxes. Other patterns may also have pnames, but only show up in embedded viewers in some other article. In those cases the script can't be sure that the discoverer or discoveryear will be correct, so it will just leave that optional line out.
Theoretically we could invent some standard way to include attributes in an embedded viewer template to convey that information. But since those attributes aren't actually used by LifeViewer it seems just as easy to make a habit of adding a comment line to the RLE.
For example, adding "#O Hartmut Holzwart, May 2009" to RLE:114p6h1v0pushalong would convey slightly more information (month as well as year) than the auto-upload script manages to collect for main-article patterns. Dvgrn (talk) 04:19, 3 February 2019 (UTC)
Just looked over the first batch of patterns added to the RLE namespace for the convert-static-images-to-LifeViewer project. Everything looks pretty workable. I think I'll adjust the auto-upload script to skip the generation of an #O line if there's one in the RLE already. Usually what's in the RLE will be a more specific date than what the script can produce from the discoveryear parameter.
Maybe I should change the script to find the "name" parameter if there is one, and use that instead of {pname}.rle in the #N line? It's kind of weird having ".rle" as part of the defined name. The problem is, there isn't a name= line in embedded viewers, but there is a pname= line, and I wanted some information in that first line that could be collected consistently. (?)
The only other thing I noticed offhand is that a few RLE files ended up getting comment lines with links: for example, RLE:151p3h1v0 has
There's a shorter form that works just as well:
But really I don't think there's any need to add article or pattern links to the RLE namespace. They'll get generated and added automatically by the auto-upload script. If you're actually looking at an RLE file in the RLE namespace, and wondering which article it goes with, then it's pretty quick to click the "What links here" link in the sidebar to find that out, instead of copying and pasting part of a comment line.
Based on experience so far, does there seem to be anything else that really ought to be adjusted for this whole conversion / auto-upload process? Dvgrn (talk) 22:54, 3 February 2019 (UTC)
Oh, one more minor thing: looking at LifeWiki articles with lots of LifeViewers on them, I'm starting to think that there might be such a thing as too much animation sometimes. If the infobox has an animated spaceship or oscillator in it, it might make sense to leave out AUTOSTART on (some?) embedded viewers in the actual article. It can be nice to have something on the page that isn't moving -- or to be able to open in LifeViewer and step through a pattern one tick at a time, without having to disable AUTOSTART first. Dvgrn (talk) 23:12, 3 February 2019 (UTC)
I haven't had any other problems so far, though of course I've only just started this project and have only gotten through around 1% of all the articles. As for the comment lines in RLEs, I'll try and be more consistent with them from here on out. (will double-check the ones I've already made to see if there's anything that should be added or removed) And yeah, I do agree that too many auto-started viewers looks very cluttered, so here's a rule of thumb I'm probably going to use: there should be no more than three AUTOSTART viewers in close proximity to each other. Thoughts? Ian07 (talk) 23:50, 3 February 2019 (UTC)
Fine by me. I've been thinking two animated viewers at once is usually enough action, but it depends on the article. Just maybe something to keep in mind a little bit. Dvgrn (talk) 01:33, 4 February 2019 (UTC)

Arbitrary adjective names

Per this forum post, I've removed every Arbitrary Adjective Name™ I could find on the wiki and moved it to a more easily-recognizable name (article text has also been properly updated to match title). Here's the list of files that need to be deleted as a result:


Ian07 (talk) 17:12, 23 February 2019 (UTC)

I think the above are all cleaned up correctly now, as far as uploaded patterns getting deleted. There was also a file out there called "extraextralongsnake_synth.rle" which turned out to have the Niemiec synthesis file for long^4 snake rather than long^5 snake. (Yup, getting rid of the extra and very and Arbitrary adjectives in favor of a simple long count still seems like a good simplification.)
The _synth files are still troublesome in general, because the files that are already out there often have generic links to the Niemiec database search page, rather than to the actual file. And of course on that database search page, the way you'd find a long^5 snake or whatever is actually by looking up "extra extra long snake"... so there's some possibility that the cleanup of "extra" creates some new confusion while reducing some other old confusion.
Anyway, I'd still recommend not starting any kind of comprehensive review of _synth files until the new version of Niemiec's database becomes available.
The second half of this cleanup will require re-running the auto-upload script, to get the .rle and .cells versions of all these files back onto the server with their new longN* names. I'm planning to wait until at least the end of this week before tackling that job. Dvgrn (talk) 22:27, 25 February 2019 (UTC)
Upload of new RLE and plaintext files should be done now. Some of these names are still preserved as redirects, like Stupidly long boat and also as an alternate name given in the text of the article. I may eventually be inspired to track down all these leftovers and clean them up, but for now I'm kind of worn out from wrestling with the auto-upload script. There's always another degenerate case that hasn't been handled yet... Dvgrn (talk) 14:45, 27 March 2019 (UTC)

Non-notable isotropic rules

Many pages on isotropic non-totalistic rules have been proposed for deletion. It seems that some users (myself included) have moved articles on such rules to their namespace, such as here. This seems to be an ongoing project and deserves discussion here.

Should I adopt salad or would someone else like it? I have a couple collections of ships that I’d like to move to the page should it be adopted. Moosey (talk) 17:15, 28 March 2019 (UTC)