Difference between revisions of "LifeWiki:Tiki bar"

From LifeWiki
Jump to navigation Jump to search
(excessive categories - new section)
Line 55: Line 55:


I think there's way too many categories for "Patterns with X cells" and "Patterns with Catagolue frequency class X" (see [https://www.conwaylife.com/wiki/Category:Patterns_with_(number)_cells this] and [https://www.conwaylife.com/wiki/Special:PrefixIndex?prefix=Patterns+with+Catagolue+frequency+class&namespace=14 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? [[User:Goldenratio|Goldenratio]] ([[User talk:Goldenratio|talk]]) 14:09, 10 May 2021 (UTC)
I think there's way too many categories for "Patterns with X cells" and "Patterns with Catagolue frequency class X" (see [https://www.conwaylife.com/wiki/Category:Patterns_with_(number)_cells this] and [https://www.conwaylife.com/wiki/Special:PrefixIndex?prefix=Patterns+with+Catagolue+frequency+class&namespace=14 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? [[User:Goldenratio|Goldenratio]] ([[User talk: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. [[User:HotdogPi|HotdogPi]] ([[User talk:HotdogPi|talk]]) 14:42, 10 May 2021 (UTC)

Revision as of 14:42, 10 May 2021

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.

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.

In general, if anyone has better suggestions for dealing with page flow issues like these, please let me know! Dvgrn (talk) 15:51, 1 July 2020 (UTC)

Link to Discord server on navbar?

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)