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)
- Note: active discussions are never archived while still active.
- 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.
- See LifeWiki:Tiki bar/Archive/2018 for Tiki bar discussions started in 2018.
- See LifeWiki:Tiki bar/Archive/2019 for Tiki bar discussions started in 2019.
- See LifeWiki:Tiki bar/Archive/2020 for Tiki bar discussions started in 2020.
Embedded-viewer variant collections
I just tried some experiments with using embedded viewers floating to left, right and center, in the Fx77 article.
It looks like it's always going to be a little tricky to get this kind of viewer stamp collection to flow correctly on the page, cooperating with the infobox -- at least, unless someone can put together some very very clever templates. It seems to be far beyond my web layout skills.
I found that the old trick of adding
<div style="clear:both;"> ... </div>
almost worked well for flow control -- for example, to force the centered Fx77+R64 to drop below the two Hersrch Fx77 variants, Fx77S and Fx77SW. This looks okay on a small laptop screen, but produces ridiculous amounts of whitespace on a larger monitor, so I removed it. The clear:both trick is particularly unwieldy when a pattern has a very lengthy infobox, because all the following text drops below the entire infobox -- not just below the most recent embedded viewers.
Also, it seems as if I often get stuck having just one left-aligned, one right-aligned, and one center-aligned embedded-viewer thumbnail. I'm thinking that there are a number of medium-sized stamp collections that it would be good to get into LifeWiki articles, e.g., maybe representatives of the sixteen classes of glider timing adjustment circuits. I've never gotten a midsized collection like that to look any good on multiple monitors, but maybe if they all just float left with THUMBNAIL THUMBSIZE 3 in LifeViewer, that will be about the best we can do?
I did find that captions could be improved by centering with
<div style="text-align:center;">first-line caption<br /><br />extended-caption<br /><br /></div>
Does that look tolerable to everyone else? Unless this is added, EmbedViewers with position=center will have centered caption text, but position=left and position=right EmbedViewer captions will both have left-justified text, which doesn't look so good. The automatically-added last two lines still end up left-justified in those two cases, unfortunately; I didn't attempt to fix that for the Fx77 article.
So today ApChrKey joined and said something about how the invite link was really hard to find. It is on links but at the very bottom. (I don't know how that affects it but whatever) Macbi suggested that we could put it up top on the navbar or whatever it's called. Given that we already have a way to cite it I don't see why we can't have a direct way to access it. Bubblegum (talk) 22:56, 10 July 2020 (UTC)
Time to delete Template:LinkWeisstein?
At this point, I think it's unlikely that the site is going to be updated so that this template can be re-enabled. As it stands, all this template does is produce an ugly piece of whitespace in articles such as toad. Any objections to deleting it? (note that I can semi-automatically remove all the occurrences beforehand with AutoWikiBrowser) Ian07 (talk) 16:40, 18 October 2020 (UTC)
- I don't see anyone posting any objections. Certainly I don't object. I've been writing to Eric Weisstein every few years, asking for him to get those out-of-date pages either updated or removed, but have never gotten a response back. Or not about that, anyway -- there was one short email exchange just after I attended a Wolfram CA summer session, once upon a time. Dvgrn (talk) 23:53, 2 December 2020 (UTC)
- I wasn't anticipating any objections either, but I just wanted to be safe. Since it's now evident that someone else has tried and failed to resolve the issue, I've gone ahead and deleted the template along with its transclusions. Thanks to AWB, this was a mercifully quick process: only 13 minutes to go through ~250 articles. Ian07 (talk) 01:52, 3 December 2020 (UTC)
A minor issue concerning the deleted template: as said on Special:WantedPages, other external link templates still have a link to the LinkWeisstein template, presumably due to Template:ListOfLinkTemplates. I don't see where to fix that. GUYTU6J (talk) 06:55, 7 December 2020 (UTC)
Excessive barberpole articles
In light of the recent merging of Template:Vessel articles, we should probably consider merging some of the larger barberpoles as well, as most people seem to agree that going up to quindecapole is pretty excessive. However, this raises the question of what the new cutoff point should be. I'd say we should keep at least everything up to heptapole, since all of those have shown up naturally. Note that although duodecapole does not have any sample soups in any symmetry, tredecapole does, making that the largest semi-natural barberpole. Ian07 (talk) 14:11, 20 October 2020 (UTC)
- Agreed. I think it would be nice to link barberpole from the individual barberpole pages. Also, just in case even the natural ones gets too many, a "Further Plan B" could be merging the "natural-but-no-content-otherwise-barberpoles" inside barberpole or something similar. (Edit: a table would be nice and clean)
Scorbie (talk) 01:48, 8 December 2020 (UTC)
Automatic categorization of pages under Rule namespace
The first topic that starts in 2021, this is actually a continuation of LifeWiki:Tiki_bar/Archive/2020#2-state_rule_cleanup. Can we set up some mechanism that scans through ruletables on LifeWiki and creates categories for rules with different n_states, neighborhood and symmetry? Hopefully this should not affect the content of ruletables. GUYTU6J (talk) 15:44, 21 April 2021 (UTC)
Merge some excessive categories?
I think there's way too many categories for "Patterns with X cells" and "Patterns with Catagolue frequency class X" (see this and this), (100+ cells or 10+ frequency class is when they start to get unneccesary) and they usually don't help the reader at all since there's usually only one page in them. Could we try merging some them to categories like "Patterns with between 200 and 300 cells", which would both be less excessive and more useful to readers? Goldenratio (talk) 14:09, 10 May 2021 (UTC)
- Population: 98, 99, 100-109, 110-119, ..., 190-199, 200-299, 300-399, ..., 900-999, 1000-9999, 10000-99999, (each power of 10)
- Heat: Use same category numbers as population.
- Period, mod: Keep exact.
- Constructible by gliders: 48, 49, 50-59, 60-69, ..., 90-99, 100-199, 200-299, ..., 1000+
- Rotors: Delete all heat/mod/period/population/volatility. Period can be recreated once a non-2 is created.
- Unit cells: Delete period/population/size.
- Eaters: Delete by number of cells.
- Sawtooth: Truncate population to nearest hundred below 1000, then keep 1000+ category. (Also, shouldn't 1163 have an expansion factor of 2?)
- Frequency class: Round to integer. HotdogPi (talk) 14:42, 10 May 2021 (UTC)
- Agree with basically all of these. Will take some effort to implement, but this seems like a much better way of organizing things IMO. Any objections from anyone else? Ian07 (talk) 15:08, 10 May 2021 (UTC)
- I would like to register a very strong opposite-of-an-objection. Mean to say, I'd like to vote in favor of all of these items -- especially if I don't have to do too much of the work, since I'm still very much more likely to break anything related to LifeWiki categories, than to be able to fix them successfully. Dvgrn (talk) 15:42, 10 May 2021 (UTC)