LifeWiki:Tiki bar/Archive/2018

From LifeWiki
Jump to: navigation, search
The following is an archive of tiki bar discussions started in 2018.

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:

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:
Neighborhood 1c.png
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)