Template talk:Things

Usage & styling
Trying to understand a few, uhh, things about this template:
 * 1) The description states that sprite names are used, yet the template deviates from the Doom2 IWAD in two entries: Shotgun guy is   rather than SPOS, is Heavy weapon dude is   rather than CPOS. The original author of the template seems inactive since 2010, so I suppose the reason for that cannot be unearthed anymore. Since the template in its intended parametric form is used only once and without those two enemies, I figured it's okay to fix them.
 * 2) This one example table shows a problem: all rows containing just zeroes are still displayed, while wiki convention is to prune such rows completely. An attempt seems to have been made to output rows conditionally on them have a defined parameter, but that was reverted at the next edit. Does anyone, or Sigma 7 in particular (who made that edit and is still active), know why this avenue was not pursued further?
 * 3) So currently this template is always used after subst-ing, but is the (long-term) goal to make its parametric usage fully functional, and the preferred approach? Or is there no consensus about that (yet)?
 * 4) Some creative contributors combine multiple columns with the same value into single columns using colspan attributes, e.g. here. It seems nigh-on impossible to cope with that in template logic, but I'm not well-versed in that. Is this table style to be preferred over repeating identical columns?  If so, then the whole parametric approach might as well be stripped from the template altogether, yesno?

Background: In light of this discussion I'm researching how best to generate the Things table via my DMMPST tool, and my current line of thinking is that parametric usage may work better for me. But if #4 is answered affirmatively (or #2 cannot be addressed in template logic), then I'd have to work with a subst-ed template. --Xymph (talk) 11:15, 10 June 2016 (CDT)


 * It doesn't seem use of this template ever gained traction probably because it's unwieldy with a potentially huge number of parameters, and could actually exceed the limitations of MediaWiki template expansion. I'll note it doesn't match current consensus practice as far as the skill level column headers, which are usually given as the abbreviated skill level names, for example. --Quasar (talk) 09:44, 10 June 2016 (CDT)


 * I agree it may be unwieldy for manual parametrization, but not for a tool. I read up on template limits and tested it, but it's nowhere close to any limits, even if included with multiple other templates (which are all smaller) in a typical map page. See the in the comments of the HTML source for that sandbox. As for current consensus re. the skill headers, I beg to differ. Back in 2010 the headers were changed from abbreviations to numbers – and the entry orders within categories changed – and were not affected in later edits anymore. I read a definition of DoomWiki consensus recently (can't find it now) as: how something is done in recent months and/or years. Because the Things template is included in Map_skel, any and all new map pages created since 2010 use numbered skill headers (whether Things is subst-ed or not), and that would then be the consensus. Anyhow, the skill headers are just a minor issue. The main topic here is whether and how to use this template. And if not, what would then be the preferred method for inserting Thing tables in map pages? Surely manually constructing a prettytable isn't it. Copying from another, similar page may be a common approach, but that's how inconsistencies propagate, and won't bring us any further in the overall discussion in Central Processing either. --Xymph (talk) 11:15, 10 June 2016 (CDT)


 * I've probably been looking at the wrong pages ;) None of these are big deals in that case, so I see no problem with using it as part of edit automation. If adjustments need to be made, we can hash those out. --Quasar (talk) 16:28, 10 June 2016 (CDT)


 * My two cents on skill columns: I much prefer numbers over abbreviations. My reasons are: #1 it's shorter (also, aesthetically, you get balanced columns when you have "1 & 2" vs "4 & 5" instead of "ITYTD & HNTR" vs. "UV & NM") and #2 it's universal. The skill setting names can be changed by mods (example: Batman Doom, which features skill names Detective, Dark Knight, The Crusade, Avenging Angel, and Knightfall) and aren't consistent across the games covered by this wiki. Once again, Hexen is a particularly notable case since the skill names depend on the class chosen. --Gez (talk) 16:53, 10 June 2016 (CDT)


 * Point 3: I can neither recall nor find any prior threads (typical for map articles). The templated form was larger in wikitext, and requires editors to learn the abbreviations before verifying or changing data, so IMO we shouldn't implement en masse without good reason.  Using conditional logic to improve formatting would be a good reason.  Futureproofing, in case prettytable itself is modified or replaced, may be another.


 * Points 2 and 4: Both technically possible. The code tends to become a hirsute mess, which I personally don't mind, but I understand why other non-programmers do.  Template limits were recently discussed on IRC (regarding parametric external links); my impression was that manual testing is required, including asking the webmaster politely about load, because this site will experience slowness and timeouts before even approaching the maximum values Xymph mentions.  Implementing both suggestions requires hundreds of function calls, which is unprecedented for us, so we should be cautious at first.


 * Skill level names: No strong opinion but Gez's arguments sound sensible. Also, numbers make the columns somewhat narrower, which would reduce congestion in the general case of many sub-tables per page.    Ryan W (usually gone) 10:12, 15 June 2016 (CDT)

Unindenting due to time elapsed. I think I understand point 2, why conditionally outputting rows was not pursued: subst-ing such a template (without any parameters) results in a near-empty table with just section headers, which is confusing (especially to casual contributors). And conditionally skipping section headers too (e.g. Keys) makes the template even more of a "hirsute mess". subst-ing this template (as part of map_skel) seems to be its only practical use, and also avoids any potential load problems that RyanW warns about.

Also, my DMMPST tool-in-progress works with Heretic as well, and rather than have that switch to a yet-to-be-devised HereticThings template, my approach in the tool is more suited towards manually generating a prettytable Things list, after all.

That leaves my question in #4: should repeated values be combined using colspan, or not? But maybe that's better discussed in the main topic. --Xymph (talk) 03:43, 28 July 2016 (CDT)

Pruning those parameters
There's only one map page using this template with parameters, with the undesirable effect that rows for which no params are defined are still displayed with zero values instead of not being displayed at all. Eventually the preferred way (if I may be so bold) to generate Things tables will be DMMPST. Therefore I propose to: The un-subst-ed template is occasionally used and pruning the params would leave its rendered form unaffected. More often the Things table is left out if unspecified, or subst-ed and manually filled (on many pages). Both practices can also continue unaffected by these steps. If there are no objections, I will perform them soon. --Xymph (talk) 08:58, 16 September 2016 (CDT)
 * 1) Replace that one parametric Things template with a normal, fixed table.
 * 2) Prune all the parameter stuff from this Template.