Doom Wiki:Central Processing/2016

From DoomWiki.org

Central Processing archives


Link archiving[edit]

I have created a series of new templates for semantic link archiving and and a help page that explains how they work. --Quasar (talk) 16:30, 1 February 2016 (CST)

Webfonts[edit]

The MIT-licensed version of Glyphicons Halflings and the (somewhat vaguely) open-source Iconochive fonts are now pushed out through our Common.css, allowing use of the various icons they contain. Right now you need to know the magic Unicode numbers but we can address that through either templates or CSS rules, depending on how much we value IE8 support (the CSS :before selector cannot insert content in that browser, which is the typical strategy used for this). --Quasar (talk) 16:30, 1 February 2016 (CST)

Promotion for Nukeykt[edit]

Fraggle would like for Nukeykt to have editor rights, in lieu of waiting for autopromotion. I am opening discussion here. --Quasar (talk) 16:30, 1 February 2016 (CST)

I have no objection. --Gez (talk) 16:41, 1 February 2016 (CST)

Marked spots?[edit]

Gez enlightened me on what tools generate the maps deployed in this wiki, but this seems a general issue so I'll pose it here rather than to him directly: many level walk-throughs refer to "marked spots" on the accompanying map, but quite a lot of maps don't actually show those spots. Is this being discussed or addressed? I searched but didn't find a previous topic about it. --Xymph (talk) 04:39, 18 February 2016 (CST)

Doom Wiki:RFC/Maptabs template is relevant. The intention is to make such walkthrough images alternatives to the normal map images and make both available through this template. However, I do not have the patience required to redo the CSS on the tabs template because it took literal weeks to get it working. Since there is negative consensus on the current appearance, the RFC has stalled. --Quasar (talk) 12:04, 18 February 2016 (CST)
I love that template, but I think this is about its prerequisites, i.e. how do we get the "dotted" images uploaded in the first place?  The short answer is no, there is not currently an ongoing project (unless someone is doing it secretly).  The only previous thread I recall is here; in addition to what I told that guy, it is not purely a clerical task, because you have to examine the level sufficiently to match the 2D locations with their architectural descriptions in the text.  Like many aspects of map articles, improvements can and should be made, but it takes time and concentration to do correctly.    Ryan W (talk) 16:26, 18 February 2016 (CST)
Yes, I was more curious about the latter, but thanks both for further enlightenment. :) --Xymph (talk) 02:41, 19 February 2016 (CST)
I've suggested a simple change to (hopefully) revive and wrap up the maptabs RFC. Also, I encountered the original topic where the markers were introduced, linked here for reference. --Xymph (talk) 15:57, 24 April 2016 (CDT)

Should go without saying...[edit]

Please do not place multiple right-floating elements next to each other when authoring pages. Most of these happened a long time ago but a few are recent. General rule, if it looks funny to you, it's funny :P --Quasar (talk) 14:00, 25 February 2016 (CST)

This can be dependent on browser window size, zoom level, font size, etc. so sometimes it'll look fine on your computer and wrong on another. A long time ago on UESP I got in a dumb edit war because of that: I'd tweak a page's layout to look great on my screen and then someone else would come and ruin everything for me by making it look great on his screen. :p --Gez (talk) 16:36, 25 February 2016 (CST)
True, always a consideration. --Quasar (talk) 21:24, 26 February 2016 (CST)

Console level template deletions[edit]

As per consensus reached to move multiple competing article-top-right-corner nav templates related to console levels down to the bottom as wide navboxes, the following templates are now unused and I have nominated them for deletion. The top-right role will be replaced by a console level progression navigator that lets you move backward and forward to the previous or next map for the specific console you want to follow, which we felt was the primary motivator for these templates to begin with.

  • Template:Console Doom Conversions
  • Template:PSX Doom II
  • Template:PSX Ultimate Doom
  • Template:Console conversion levels

--Quasar (talk) 16:38, 2 March 2016 (CST)

  • Yeah, delete.  These templates indeed appear to be superseded by the new wide navboxes, and have been replaced by them in all articles.  (Still not sure how that happened so quickly...)    Ryan W (talk) 23:05, 4 March 2016 (CST)
Pretty much uncontroversial cleanup, so I went ahead with it. --Quasar (talk) 19:27, 17 March 2016 (CDT)

Banning and IP blocking procedures[edit]

Due to the rash of spam we opened up the CheckUser ability to some sysadmins. It is important that procedures continue to be followed as they were previously, however:

  • If a user account spams, that user account must be blocked. Creating an IP range block that covers them does not ban any accounts they already created.
  • IP rangeblocks should only be set to prevent account registration when a spammer has actually registered an account from that range, not just because spam came out of that range from anonymous IPs. This is what our captcha exists for - to allow constructive human editors to have a chance of getting past indiscriminate IP blocks. If you go back to all the rangeblocks I did, *only* ranges that had accounts registered from them ever had "prevent account registration" selected.
  • IP rangeblocks in areas likely to contain constructive editors must be temporary. Anglosphere countries, Western Europe, or Russian dynamic IP ranges should not be permanently blocked. Chinese, Indian, Philippine, Ukranian, Russian private /24 networks, and dedicated hosting companies should be permanent blocks. This is obviously on a case-by-case basis but my rule has been the less likely an area is to be constructively editing or even having any interest at all in our site, the longer the block. A general scale I go by: US/English-speaking/Western European dynamic range: weeks to 1 month block at most. Eastern European or various other less likely areas: 2-6 months.

--Quasar (talk) 01:14, 3 March 2016 (CST)

Console map articles: going forward[edit]

So, from the recent mass edits, I infer the following.

  • SNES Doom and GBA Doom II don't need separate map articles, because some effort was made to match the originals.  Any changes can be described in a section of the PC map article.
  • Doom Classic, Windows CE, and Tapwave Zodiac are even closer conversions, and should be assumed identical (aside from global differences listed in the main article), barring some unforeseen technical research.
  • Stock PC maps go into Category:Levels with console versions only when a separate console article exists (or is redlinked).
  • Category:Stock levels with multiple names may include redirects for ease of navigation.  We don't normally categorize redirects, but I can see the point in this case.

Does that make sense?  I personally don't have big plans for this content, but presumably others do  :>  and also I'm thinking of how best to react when a newbie creates a page, or when working on related PC articles.    Ryan W (talk) 15:26, 5 March 2016 (CST)

  • Do not necessarily agree on SNES and GBA Doom 2 as a blanket statement. Not all levels in those ports are sufficiently modified to require a new article. But some are substantially modified. GBA Doom 2 has heavy modifications - a couple of the levels are even divided into two maps! I'll make this call if and when it ever becomes possible to acquire maps for the levels in these ports - it is not currently possible.
  • Ports that are only using the PC WAD do not need level articles. Those are direct ports using the same data, not new levels.
  • The category contains redirects because without them you cannot see what the alternate names are.

--Quasar (talk) 05:38, 17 March 2016 (CDT)

For the SNES case, Ledmeister seems to have them [1], although he doesn't explain what the secret sauce is.    Ryan W (talk) 16:12, 18 March 2016 (CDT)
Right, unfortunately they're not in our preferred OMGIFOL/SLADE color scheme and we also do not presently have a content sharing arrangement with him. --Quasar (talk) 16:12, 20 March 2016 (CDT)

Articles to be merged[edit]

Articles to be merged needs attention. It is perpetually growing without anyone ever giving input. A few weeks more on some of these and I will just execute them unilaterally. --Quasar (talk) 05:38, 17 March 2016 (CDT)

Standard map sections?[edit]

While editing walk-throughs of the Final Doom maps I played, I have been standardizing the section headers, but along the way learned that there seem to be two standards, at least for the main strategy / walk-through area.
One used on e.g. E1M1 - E1M9, E2M1 - E2M5, E2M9, E4M1 and a similar cross-section of Doom II maps:

  1. Walkthrough
    1. Essentials
    2. Other points of interest (optional)
    3. Secrets
    4. Bugs (optional)
    5. Demo files (optional)

Another used on E2M6 - E2M8, E3M1 - E3M9, E4M2 - E4M8 (and ditto D2 mishmash):

  1. Strategy
    1. Walkthrough
    2. Other points of interest (optional)
    3. Secrets
    4. Bugs (optional)

Why do the different variants exist? Which one is preferred or recommended? Where is the template used to initiate new pages for maps? The one frequently used by e.g. MtErebus adheres to the first standard above. Is this topic already discussed elsewhere (I searched in vain)? --Xymph (talk) 12:48, 20 March 2016 (CDT)

AFAIK, most map articles are created by substing the {{map skel}} template, which corresponds to the first model. The second model seems older, since the map skel template started with a "strategy" header with "walkthrough" and "secrets" as subheader, and then here changed mostly to the first model. --Gez (talk) 13:02, 20 March 2016 (CDT)
Bummer, I usually standardized towards the other one, or at least didn't convert when the opportunity arose. Somehow the latter model seemed newer, more common and more sensible to me. Well, I'm not going back just to tweak earlier edits, but will keep it in mind going forward. Thanks. --Xymph (talk) 13:30, 20 March 2016 (CDT)
Note that, due to the recent inclusion of other templates within {{map skel}}, simple substing no longer works: you must copypaste from one edit window into the other.  This is counterintuitive and produces well-intentioned errors, so I keep meaning to research it further (MediaWiki has, I believe, some equivalent of preprocessor directives which would generate the intended output in one step).    Ryan W (talk) 14:19, 20 March 2016 (CDT)

Supercharge over Soul sphere?[edit]

Although the pick-up message for the Soul sphere is: SUPERCHARGE!, I've never heard the power up itself being called a supercharge itself, and instead I thought the message describe what the powerup did as in a supercharge of health. It is more commonly reffered to as a Soul sphere. I'm new to this wiki and I'm not sure how to move the page. Thanks

Hi. A change like this generally would not be made before consensus is reached in a discussion here. There are a number of such ambiguities in the Doom series where things have more than one canonical name, and one or the other were chosen, sometimes without deliberation or regard to any particular standard. However generally preference was given with these old articles to the text used in-game, in preference to text that appeared in the manual, on the theory that id Software may not have been as involved in the manual's production, making it secondary canon to the game itself. This is not an unusual approach in other gaming communities; Castlevania is plagued by such issues, where the story in the manual doesn't match the game or the original Japanese version. Right now we have Supercharge as the article title, and soul sphere is a redirect to that, so writers are still able to call the item by whichever name they prefer and as far as I know there is no objection to doing this except where it creates stylistic inconsistency (ie., switching arbitrarily between the two names within the same article). --Quasar (talk) 11:11, 8 April 2016 (CDT)

News board tweaks[edit]

Our News board now validates as schema.org NewsArticle microdata entries, as well as the hfeed/hAtom microfeed it previously supported, which Google and other search engines can use to build "AMP articles". Dunno if they'll pick up on it and actually do that, but the capability is there. As a result though, if you want to put a right-floating thumb in, you need to use the new pic/w/h parameters of the news article header template or else the image isn't visible as being related to the article. I hate making something complicated even more so but it was unavoidable because microdata is really inflexible. --Quasar (talk) 11:55, 12 April 2016 (CDT)

Baron of (H|h)ell[edit]

User:Who is like God? moved Baron of hell to its lower h-e-doublehockeysticks location back in 2008 but consensus since then has been that we treat Hell as a proper noun anywhere it's not being used as a quoted swear word ("go to hell", for example), so arguably this move was incorrect in the long term. Moving it back at this point (Making Baron of Hell the main article title, and Baron of hell a redirect to it) will require fixing up the following redirects, however, so that they don't become doubles:

  • Baron
  • Ogre
  • Bruiser Brothers
  • Barons

Is there consensus for this? The article title doesn't even currently match the bolded text in the first paragraph, so far has the consensus shifted. --Quasar (talk) 12:32, 12 April 2016 (CDT)

I dimly recall contesting that move, but now can't find the thread.  The reasoning in our current guideline seems sound: Hell is capitalized because it's a place name, e.g. Baron of Largs.  Should this be agreed upon, I'm willing to search for other instances in body text, and try to make them consistent.    Ryan W (talk) 19:11, 13 April 2016 (CDT)
Makes sense to me. And welcome back to Ryan. ;) --Xymph (talk) 02:22, 14 April 2016 (CDT)
Agreed. --Gez (talk) 07:14, 14 April 2016 (CDT)
As already stated before on this site, I strongly agree --SuperShotgunPenguin (talk) 13:31, 19 April 2016 (CDT)

I'll double down here and note that I never suggested here that "Baron" should be capitalized everywhere. This was about the word Hell. --Quasar (talk) 12:06, 8 May 2016 (CDT)

That's indeed how I interpreted the outcome here when occasionally updating baron of [h->H]ell refs in Final Doom walkthroughs in recent weeks. --Xymph (talk) 12:55, 8 May 2016 (CDT)
The previous two posts refer, presumably, to this edit which I have now adjusted.  As noted on IRC, our current practice is inconsistent but the preferred convention is not entirely clear either ("baron" in non-Doom contexts can be capitalized or not).  So I tried it, and apparently messed up, but at least there was feedback for once.  Long live open editing!    Ryan W (talk) 19:41, 9 May 2016 (CDT)
We might as well open the nasty discussion I've always dreaded on how we want to treat the phrase "Baron of Hell" when it occurs in full, since we're currently inconsistent with it even within single articles. I still prefer the full phrase to be capped when it occurs like this, because it feels like it is the title of the monster being discussed and not a mere species name, to me. But also, it's a matter of aesthetics:
  • Baron of Hell
  • baron of Hell
Maybe it's just my OCD kicking in, but the latter looks unbalanced to me, and therefore ugly to read. --Quasar (talk) 23:45, 9 May 2016 (CDT)
I sorta agree with the unbalanced aspect, but all other monsters are also mentioned as individuals (e.g. in walkthroughs) yet the consensus is not to capitalize their names. Why would "the Baron of Hell" in full be a title but "the cyberdemon" or "the arch-vile" not? Is it because it "lords over" a place, and is that strong enough to make an exception just for this monster?
Wish you hadn't dreaded this til past my combing the Final Doom walkthroughs. ;) --Xymph (talk) 02:56, 11 May 2016 (CDT)
It only looks unbalanced because of the list presentation, the issue is not as visual when barons of Hell are just mentioned inside a proper paragraph, just like you could mention earls of England and dukes of Denmark. Lists tend to have their items capitalized anyway even though the words themselves wouldn't be in paragraphs:
  • Strawberry
  • Banana
  • Apple
  • Coconut
So I don't see this as a problem. --Gez (talk) 03:22, 11 May 2016 (CDT)
On reflection I agree with this.  A related recent case was gameplay navboxes, where initial capitals belong on article titles even when the subject itself is a common noun (e.g. shotgun, door).  Maybe there could be edge cases involving the rank of a specific individual ("Oremorj, the Cyberdemon Lord"?) but 99.99% of the time we refer to a thing as an interchangeable member of a class, matching Gez's examples.
In formal writing, arguments from OCD are often valid  :>   but not here IMO.  Lowercase species names "looked unbalanced" to me once, so I started capitalizing them.  As Quasar states, a consensus on lowercase then emerged over time (eventually I'll go back and mop up, unless someone else does first).  I'll get used to this one too.    Ryan W (talk) 11:00, 12 May 2016 (CDT)

Article on Super chaingun?[edit]

Would it make sense for a page about the Super chaingun (the weapon used by the Spiderdemon, according to the manuals)? Or are the manuals not good enough sources for it to be distinguished as a separate weapon from the Chaingun? thanks. --SuperShotgunPenguin (talk) 10:35, 13 April 2016 (CDT)

Consensus is only to discuss enemy attacks on the enemy's page itself. The weapons wielded by enemies can be adequately described there. I believe the "super chaingun" bit is already described on Spider Mastermind. --Quasar (talk) 17:35, 13 April 2016 (CDT)
Agreed.  It would be one thing if that gun had become a DeHackEd fad or something, circulated widely among modders in certain countries, but that's not so.  Monster weapons simply don't have enough content, separate from what we already say about the monster's combat behavior, for separate articles.    Ryan W (talk) 19:15, 13 April 2016 (CDT)

Navbox template font size?[edit]

It struck me that the font size for episode navboxes is inconsistent: an incomplete random check of entries on Category:Navboxes for map articles indicates that the majority (including those for Doom II and both Final Doom iwads) use default font for the header and 'div style="font-size: smaller"' for their contents; some however use 'div style="font-size: larger"' for the header and default for the contents. Which one is the standard / preferred style?
The larger style (e.g. in Template:Hell's Gate - The Red Spot) looks to take up too much space for my liking, but it also happens to be the one used for the Ultimate Doom episodes, so I'm not going ahead and change it without discussion and (hopefully) consensus. ;) --Xymph (talk) 14:50, 18 April 2016 (CDT)

Normal header and smaller content, IMO. --Gez (talk) 15:13, 18 April 2016 (CDT)
The "smaller" font size is a real problem for mobile view, which now accounts for 25% of our viewership. Something to think about. I am not really concerned with the headers, but the use of "smaller" on lists of links creates tap zones that are too small to effectively use at all. --Quasar (talk) 15:49, 18 April 2016 (CDT)
I looked at the site on my tablet for the first time (in mobile & desktop modes), and I have to agree. But I don't normally visit the site on anything but a PC, and I'd still like the smaller fonts/boxes there. I'm also a stickler for consistency. ;)
So what can be done? Is it possible to differentiate between platforms and present different sizes via CSS? --Xymph (talk) 03:53, 19 April 2016 (CDT)
It is, but the templates would have to be changed to use a CSS class. We'd then define that class to apply font-size: smaller in Common.css, while leaving it normal in Mobile.css - this allows the two to present differently depending on the view being used. --Quasar (talk) 09:44, 19 April 2016 (CDT)
Well, that's a lot of templates to tweak, but they don't all have to be done at once, and I'm willing to assist as I brought it up. ;) Can you make the necessary CSS additions, and changes to a 'prototype' template? --Xymph (talk) 15:13, 19 April 2016 (CDT)
Quasar, since you seem to be the only one making CSS changes, is this little project still on your to-do list? (And the Maptabs template tweak(s) too?) --Xymph (talk) 09:17, 19 May 2016 (CDT)
Unindenting...

...due to time past. I encountered Community Chest 4 21-30 which, probably accidentally, uses the same default font size for header and map list – unlike 01-11 and the others in that series where the map list uses the 'smaller' font. Would this be a suitable compromise for all navboxes for both desktop and mobile view? Then no new CSS classes are needed. --Xymph (talk) 07:12, 24 November 2016 (CST)

All existing navboxes have now been updated to the new CSS-based styling, therefore this topic has been wrapped up. --Xymph (talk) 15:23, 27 January 2017 (CST)

Backups, dumps, archives, etc.[edit]

On a related note, and I realise you have not ended up being in this position on purpose, but we are basically one person deep (bus factor: 1) on important things like site resilience, which is why I've been banging on about backups and data dumps for a long time. It's all fine and well to assure us that all is fine, but I would be much happier if I knew *I* had a dump of everything myself, and worst-case scenario, some crazy bus driver takes you out, takes Mike out and steals Mancunet's hard drives, I could get the thing back up again myself. Or anyone could. -- Jdowland (talk) 09:49, 19 April 2016 (CDT)

This is straying from the original topic and would be served by forking it under a separate header. I took the liberty of doing that, hope Jdowland doesn't mind.--Xymph (talk) 10:08, 19 April 2016 (CDT)
Not at all -- I've just moved the whole section to Central Processing which is probably where it belongs anyway. Thanks! -- Jdowland (talk) 03:27, 20 April 2016 (CDT)
Anyway, I can confirm that wikis do die because of bus factor 1, as www.tm-wiki.org (for TrackMania) went down last year and the only person controlling the server didn't respond to emails, not even from the (different) person that controls its DNS entry. Not saying that DoomWiki's resilience is badly handled now, as I know nothing about that, but if there is concern about it then I can understand that. --Xymph (talk) 10:08, 19 April 2016 (CDT)
Nothing stops anybody from making incremental dumps of this site via the MediaWiki API. I would suggest you do so at a retrieval rate that does not tax the server though. As stated before there is no process available to me to make safe dumps available. There is no MediaWiki script that will dump the user table columns for salted password, email address, and current session ID. So unless you want everyone's user accounts to be hacked and emails harvested for spam, please don't suggest that I upload an unstripped dump. --Quasar (talk) 10:27, 19 April 2016 (CDT)
Thanks Quasar for your patient, reasoned response. You are right and those are things I should really focus on. I will get back in touch with you about which IP and how frequently an API dump will be performed to make sure it's coordinated. But my main effort will be on sorting out a script for getting a scrubbed dump reliably. -- Jdowland (talk) 03:27, 20 April 2016 (CDT)
FWIW, I get API dumps with this.  I did the first one with Manc watching on IRC, and he said the load was negligible and never mentioned IP addresses.  I assume a skilled programmer could modify the code to download any supported metadata (e.g. username lists), which would still be less than a full SQL dump, but decrease the pain of a (hypothetical) fail-safe fork.    Ryan W (talk) 18:09, 20 April 2016 (CDT)

QueryBot can now edit[edit]

I've successfully written code that can automate simple types of edits and apply them through the User:QueryBot account. I finished using it to recategorize 142 images that were in the Screenshots category and distribute them properly into PlayStation Doom screenshots and PlayStation Final Doom screenshots. --Quasar (talk) 14:15, 20 April 2016 (CDT)

WOW!  A large milestone for us.  And hopefully people won't expect you to take all mass edits off their hands.  :D    Ryan W (talk) 18:26, 20 April 2016 (CDT)

Map thing statistics[edit]

I'd like to establish some sort of new standard for filling up the map things tables, one that is inclusive of multiplayer and of Hexen. Problem: there's a lot of cross-referenced infos and we're limited to two-dimensional tables. Here are the basic issues: a thing can appear or not depending on the following filters:

  1. Skill setting (usually 12/3/45, but in UDMF it can be 1/2/3/4/5, and ZDoom allows up to 16 skill filters)
  2. Game mode (single-player, cooperative, deathmatch)
  3. Player class present in game (usually just one in Doom/Heretic/Strife, but Hexen has cleric, fighter, mage, and in UDMF ZDoom allows up to 16 class filters)

Currently, my idea would be to list the table multiple times:

  1. Single player (one table per class when multiple classes exist and filter things differently)
  2. Coop (for class-filtered things, assume all player classes are present)
  3. Deathmatch (idem)

For vanilla Doom/Heretic maps, coop and deathmatch are identical since there's just a "multiplayer" flag. So we'd get two tables: single and multiplayer.
For vanilla Hexen maps, there'd be five tables: cleric, fighter, mage, coop, and deathmatch.
There are also things that are present in the map but never appear (because, for example, they don't have any skill flag). For exhaustiveness it might be interesting to also list all things that are present, regardless of settings, but I'm not sold on it. Another thing: scripted maps can make more things appear during the game, something that a simple analysis of the thing data in the map lumps doesn't cover. Knowing how scripted thing spawning can be conditional and repeated, how do you express that? Sometimes, the spawning will always happen as part of normal gameplay, and it will happen just once, so it could be considered like a thing that was here from the start. Other time, it's optional (spawning some monsters to punish the player for getting a puzzle wrong for example) and it can be repeated infinitely, so the scripted thing count would be from 0 to ∞.

Anyway, I welcome any better idea on how to organize this data visually. The current approach is good enough for Doom/Heretic/Strife single player but cannot handle Hexen, and for some ZDoom maps such as ZDCMP2 a non-standard table had to be used. --Gez (talk) 09:32, 2 May 2016 (CDT)

Heretic IWAD's tables already are already more comprehensive than Doom ones (with players starts, decorations, etc), but include just one extra column for multiplayer rather than a separate table. Would that same approach work for Doom? I don't see any Hexen IWAD map pages with a Things table, so that seems to be new territory.
My main question is what purpose do the tables serve, what would the audience get out of them by making them more comprehensive, or even list all things regardless of function? I personally wouldn't be interested to see that a level includes 16 lamps and 9 puddles of blood. For Doom tables, barrels used to be included but were later dropped. Maybe the reasoning behind that change (if anyone can find it – this is the closest I could find) also helps us decide on whether to include other things not in the current template.
You've outlined a complex problem which I don't think can be solved with a single solution, so breaking it up into manageable chunks may be a way forward. Defining the desired tables for the two vanilla categories above seems a good start. --Xymph (talk) 16:39, 4 May 2016 (CDT)
No specific layout to propose, but I'm glad this is being discussed — a standard form would look more polished, and help infrequent editors see what's missing.  A few thoughts:
  • Most (all?) stock maps lack skill settings for multiplayer things, but it sounds like Gez wants to handle the general case of artisianal modding.  It would reduce clutter if the display were flexible about this, e.g. parameters to collapse identical columns.
  • IIRC some contributors omit objects irrelevant to normal play: no difficulty flags (I've been listing these under Bugs only), in the void (should be bump-checked I suppose), or on unreachable surfaces (a non-algorithmic decision).
  • If this actually gets coded into SLADE, I'd suggest not laboring to implement the wikitext, because those details are vulnerable to rot.  Just make it sufficiently generic, like delimited plain-text, that it could match most plausible markup with a few find-and-replaces.
  • Xymph may be giving us too much credit again.  :>   Barrels were added sporadically over the years [2] with no discussion, so the "reasoning" was probably that some people like barrels.  (It happens [3].)  More broadly, there have been few changes in the table layouts and almost no talk threads, because stock maps are a sleepy neighborhood and actually extracting statistics has been tedious.  Definitely new territory.
Ryan W (talk) 22:44, 4 May 2016 (CDT)

Unindenting due to time elapsed. As mentioned above, manageable chunks seem the way forward to me, so I worked on the Doom & Heretic tables, and my tool DMMPST to generate them. Elaborate discussion of the many various aspects of those would overwhelm this here topic, so for that I created a blog user page. :)
While extracting statistics may have been tedious, now it's a snap, but some degree of consensus needs to be reached before my approach can be rolled out wiki-wide. So I'd like to ask (prospective) participants in this topic, Gez in particular, to review my DMMPST page and the most recent table variants, provide me with feedback, and answer questions like these:

  1. are the two (vanilla multiplayer) or three (Boom-compatible) tables overall okay?
  2. the tables are spaced evenly within the available page body, so with just two tables they stay rather far apart - is that okay?
  3. are the choice of thing classes and the class order okay?
  4. are the items within each class and their ordering okay?
  5. in Heretic tables decorations, ambient sounds, etc are skipped, is that okay?
  6. should headers for empty classes (e.g. keys) be shown or skipped?
  7. should columns with identical values be merged via colspan?

If some point is not yet okay, how can it be improved? As offered before, participants in this topic can request a beta copy of DMMPST to help test and improve it.
All my tools are derived from the ancient DEU codebase in C which covers only Doom and Heretic. While Hexen and Strife support look feasible and something I'll work on next, UDMF and ACS still seem bridges too far for me and I also feel it's impractical to try and support them in the same tool. Besides, I really fail to see the point of 16 skill levels and 16 classes. ;)

I realize this is just a start, and maybe an approach that's not as generic or groundbreaking as Gez aims for. The tables that DMMPST generates so far are essentially the same as the existing ones, only much more consistent. I don't have a "better idea on how to organize this data visually" either, and I doubt a single approach-to-rule-them-all exists. So until someone else comes up with a better idea, I'll continue down the path of multiple tables for the binary-WAD formats.   --Xymph (talk) 12:38, 5 August 2016 (CDT)

My own answers:
2. I'll experiment with the |width parameter to col-break.
3. Yes, though I kind of like the separate Health and Armor class in Plasmaplant too.
6. Skipped.
7. Probably not, the values jumping left and right depending on where the column dividers are make the tables fidgety (see Plasmaplant and ZDCMP2 above), though repeating the values would make them more crowded. Hmm.
And Yes to the others. --Xymph (talk) 13:23, 5 August 2016 (CDT)
Mine, then.
  1. Guess so.
  2. It'd probably look better if they were side by side rather than far apart.
  3. Mostly.
  4. Can be fine-tuned a bit for some things, e.g. backpack vs bag of holding, as I mentioned previously on the DMMPST talk page.
  5. I think it's better to err on the side of including things than on not including them.
  6. Better to skip them.
  7. I'm not really fond of that, except when it affects the entire row.
--Gez (talk) 08:05, 15 August 2016 (CDT)
Since my previous post in this topic, plenty of progress has been made on DMMPST which can be followed on my user page from here. In response to Gez:
  1. I'll take that as a 'yes'. :)
  2. Agreed, hence the width=33% on the first table. Are the DoomII and Heretic sample pages now OK in this respect?
  3. What changes in ordering do you propose? Refer to the overview page; I'd like to finalize this aspect.
  4. Again see the overview page, and propose specific changes please. It's not yet clear how backpack/BoH should be classified and ordered, for example.
  5. I added Heretic's ambient sounds, that's fine – its list of supported Things was the shortest of all four games before that anyway. But I still don't see any value making the tables for all games longer by including decorations and player starts. Sometimes more isn't better, it's just more. ;)
  6. Thanks.
  7. Upon some tests (see the Plasmaplant sample page) I agree that combining three identical values into a row works well, in combination with centering the single cell values as well. What do you think?
  8. New question: how should Hexen tables be presented: using tabs, or some other method?
As always, more feedback by others remains welcome. --Xymph (talk) 07:19, 16 August 2016 (CDT)
For what it's worth, I support every change you make to the stock level thing tables. I cannot help having a personal grief on this, but it's the wiki that matters, and it seems that the thing tables will become clearer and more consistent. --Jartapran (talk) 10:08, 17 August 2016 (CDT)
Thanks, I appreciate that. I understand the grief and have much respect for the huge amount of work you put into compiling the existing tables over the past years. But computers are better than humans at adding up and compiling tables, so the goal of my project is indeed to make them more complete and consistent, and much easier to generate. In that sense a tool, any tool, is merely long overdue. Your efforts have served the wiki well though, we all stand on the shoulders of those before us, and DMMPST certainly benefits from yours. :) --Xymph (talk) 03:18, 19 August 2016 (CDT)
Going back to my latest bulleted list, I'm taking the lack of Gez's feedback so far as 'OK' on #2, #5 and #7, while #3 and #4 made progress and are almost there as per the DMMPST discussion page. That leaves #8. Anyone... anyone... Gez? ;) --Xymph (talk) 10:36, 25 August 2016 (CDT)

Bot on the loose :)[edit]

After lots of work behind the scenes, dmmpstBot is now ready to roll, and update the Statistics sections of a lot of maps. As a test run, I let it do the first map of Doom, Doom II, Heretic, Hexen, Strife, and Sunlust. More about the bot on the DMMPST blog some other day, but meanwhile, if anyone has any last-minute feedback on Things table content or layout, speak now or forever hold your peace. ;) Well, all bot runs happen from a configuration file and are therefore easy to repeat after tweaks, but I'd prefer to avoid cluttering up all those pages' histories with more bot edits than necessary. --Xymph (talk) 13:21, 8 October 2016 (CDT)

The only (minor) problem I see is how long the deathmatch table gets on Hexen. I am not sure if there's a good solution, though perhaps it would look less odd if Deathmatch (which is likely to always be the longest table) were placed to the left along the article margin rather than in the middle. --Quasar (talk) 19:32, 8 October 2016 (CDT)
I noticed that, though it depends to some degree on how much longer the middle table is. I tried it manually, and I'm inclined to like this better, but I can't tell whether that will be the case for all Hexen pages until they've been redone with DMMPST. A (very) minor issue now that the DM table doesn't include the widest cell (Keys & Puzzle items) of the SP/Cleric table above it, so its right border doesn't align anymore. Also, a (less) minor problem is that the DMMPST code loops through the modes in fixed order, and making in the Hexen order different requires a bit of a kludge (but a doable one). I don't want to swap the order for other games (e.g. Boom-enabled maps) because SP and Coop logically belong next to eachother. --Xymph (talk) 08:00, 9 October 2016 (CDT)
If we are kludging things for Hexen, it might also be possible to split the Hexen deathmatch column into two different columns? Like below. The advantage is that the single player already has three columns, so it makes both rows balanced. Might be better left as manual tweaks to do after bot input because the best way to break the column in two balanced sections probably varies on a case-by-case basis. --Gez (talk) 08:18, 9 October 2016 (CDT)
That's a good idea, though if we're manually kludging anyway, I'd rather not kludge in the code and keep the tables in logical order. So then DM is split over middle and right table, like so. As long as those columns aren't notably longer than the left one, I think the overall presentation of the data is fine. In exceptional cases we could still manually move Coop to the rightmost column. And for DM-only maps like Deathkings Hub 4 I was planning to prune (or not generate) the SP/Coop tables, and then the DM table could still be split in half. --Xymph (talk) 09:10, 9 October 2016 (CDT)

Feedback and leftovers[edit]

Wow, I'm blown away.  The bot seems to incorporate all the stated goals while keeping the table format (relatively) streamlined and the page load times unchanged.  I can't believe the remaining code fixes happened so quickly. My only comment right now — very nitpicky, sorry — is about the spelling of singleplayer, or is it single-player or perhaps single player?  I'm unsure how to research the Doom community's preference but I doubt anyone has raised the issue here; my non-scientific count (excluding map articles!) is 174 vs 63 vs 155 usages respectively.  FWIW folks.    Ryan W (usually gone) 22:19, 15 October 2016 (CDT)

From a quick search on the Doomworld forums: 1469 results for "singleplayer", 5876 results for the other two combined (search interface ignores the hyphen unfortunately). The /newstuff Chronicles use "single player" consistently. Overall my impression is that all three variants are widespread enough that whatever variant we use right now is fine. --Gez (talk) 05:00, 16 October 2016 (CDT)
Two spelling-oriented discussions on gamer forums (here, ignore the vote; and here) present arguments for each, and the gist seems to be that "singleplayer" is the least correct variant, but not incorrect (because language is dynamic). The reason I didn't put in a hyphen or space is that this header would then be a little asymmetrical with its most common Multiplayer counterpart, and I like symmetry. :) But language is certainly important on a wiki, so I would be fine with making a change now before the current spelling propagates too far. My bot scripts would allow rolling it out fairly painlessly in most page series (except the ones I made manual changes to afterwards), and updating the half-dozen single-level pages I've done would also still be manageable.
If we do agree to apply this change, now would be a good time to discuss a belated addition to the tables: the number of deathmatch starts would be valuable info in MP/DM tables (which I only realized while updating id Map01). One reason I didn't add this row during development is that it would probably have to go in a separate class (called "Technical" there, and "Working parts" in the former Heretic tables), making tables two rows longer (three if Teleport landings are included too, while we're at it). I wasn't comfortable with that, but now the missing info is bugging me a bit. What do you think? Should one or both be included? Could they be combined with another class to save a row?
Btw thanks for the kind words & comments, Ryan :) Since Gez initiated this topic, it would be interesting to know what he thinks of the current outcome as well.
Also, to clarify, the tables are generated by the tool, "the bot" is the collection of scripts used to check and (sometimes) add/update pages via my bot account. The tool code changes actually happened rather quickly, the scripts/framework coding took up most of my time in the past few weeks. --Xymph (talk) 06:26, 16 October 2016 (CDT)
To go in more details, my prescriptivist opinion is that "single-player" is the most appropriate because the hyphen turns it into an adjective. Single-player statistics. Without the hyphen, it's a player who is single, so it's about the player, not the whatever it is that is single-player. And the word "singleplayer" triggers my spelling checker so it's not a valid word. But my descriptivist opinion is that it doesn't really matter because all three forms are used frequently and understood unambiguously, so regardless of the form used the language is clear. If updating everything isn't a hassle, I vote for "single-player" though. Also the point should be placed on the wiki's style guide. --Gez (talk) 09:35, 16 October 2016 (CDT)
I vote for "single-player", too. It's the most natural-looking version to me. —The Green Herring(talk) 02:24, 17 October 2016 (CDT)
I agree with your dashing votes. :) But both of you skipped over the remaining open topic: adding more things like deathmatch starts and other functional items. As usual I have more on the matter than comfortably fits in this thread, so that's covered here. This takes Gez's opinion (above) that "it's better to err on the side of including things than on not including them" into account, but further feedback would be welcome. --Xymph (talk) 07:07, 17 October 2016 (CDT)
I previously included deathmatch spots for maps that were dedicated to deathmatch, such as the Game Boy Advance exclusives and idMap 01. I suppose having them as a general feature makes sense though, now that we have multiplayer thing tables. --Quasar (talk) 07:58, 17 October 2016 (CDT)
All discussed changes and miscellaneous items are included, and I've bot-updated a handful of single-level pages as a trial run. Any further suggestions before bulk updates commence? --Xymph (talk) 09:01, 24 October 2016 (CDT)

New DOOM monsters[edit]

If I'm not mistaken, the Possessed and the Unwilling are the same monsters (please correct if wrong). Why is Unwilling page still up? Also, should other variants of the possessed be counted as different monsters, or be included in an overall article on "The Possessed" like Zombie? --SuperShotgunPenguin (talk) 15:45, 4 May 2016 (CDT)

This is clearly debunked by the GameSpot exclusive "15 Minutes of Hell" gameplay video, where a distinct codex entry is gained for monsters known as The Unwilling, who I will note no longer look anything like the The Possessed. It seems this name was swapped at some point between E3 and now to a monster which more closely resembles the "Naked zombie" from Doom 3 and occurs in abundance in Hell. However we are still going to wait for the release of the game to adjust this because clarification - canonical clarification, not uneducated guesswork - is needed. --Quasar (talk) 11:17, 5 May 2016 (CDT)
It is quite likely also that the possessed have numerous minor variants. Unless some of them prove to be outstandingly unique, we may indeed handle them on the same article as subtypes. Examples of distinction:
  • Fat zombie, Fat zombie with wrench: Not worthy of distinction by separate articles.
  • Flaming zombie: Acts and looks so totally different from other zombies, he got his own article.

--Quasar (talk) 11:20, 5 May 2016 (CDT)

Screenshot above the map: where?[edit]

The other day while making the Doom2 map update sweep, I noticed that four times a single screenshot was placed above the map, but in three different ways: MAP20, MAP30, MAP31 & MAP32. And now in the actively updated UAC Ultra series, there are yet two other placements: MAP01: Dig (UAC Ultra) and MAP02: UAC in Exile (UAC Ultra) (same for 03-11, except 10 which has its screenshot in the usual section). What is the guideline, and if there isn't one yet (I'm learning ;)), what should it become? --Xymph (talk) 08:36, 6 May 2016 (CDT)

There is no rule, but, most articles are encouraged to have a single prominent "article-top" image at upper right. Generally this image will be selected to represent the page itself, such as in the mobile frontend search bar, and when pages from this site are shared to social media outlets. For most map articles that ends up being the map, but you can probably see how a screenshot does establish the mise en scene of a level more effectively than a bland outline of its linedefs can. Usually the reason it doesn't happen on map articles is due to the pesky upper righthand corner navbox templates that compete for that space. I have no real suggestion and I don't necessarily believe that all articles have to be uniform in this respect. If the navbox is too long, for example, it will end up pushing the screenshot, and then the map in the walkthrough, down too far. So that's to be avoided as an aesthetic issue when it would be present. --Quasar (talk) 09:48, 6 May 2016 (CDT)
I agree that a top-right screenshot has its benefits. Their appearance is indeed complicated by the navbox, the view mode (PC/mobile), the dimensions of the window or device screen, and the order/size of the boxes. For UAC Ultra map01 on my PC, the navbox and screenshot appear in that order above each other along the right edge of the window. But for maps 02-09 & 11, the screenshot is first in the source code and is shown in the top-right corner. The navbox appears left of it instead of below, thus crushing the opening paragraph into a narrow column. That looks ugly to me, so I fixed those pages. --Xymph (talk) 09:57, 19 May 2016 (CDT)

Sticky wicket[edit]

The new Doom seems to follow an Every Word Capped convention inside the game itself. So far I've been following the style of this wiki instead. But one thing that's always bothered me is Spider Mastermind and now that it seems it might be returning, what will its article be named - Spider mastermind (Doom 2016) or Spider Mastermind (Doom 2016)? The one not chosen should be a redirect, naturally, but we're also discussing what the stylistic treatment of the name within articles should be. If it's supposed to be a creature of unique character with a special status, "Mastermind" may well prove to be its title and should thus be capitalized (I've always felt that it was meant to be as such anyway, but I lost that argument against the majority). Do we have to hold off until the full codex is revealed to make this decision effectively? --Quasar (talk) 09:48, 6 May 2016 (CDT)

(Brainstorming) Expansion of the wiki's mission, or a wiki network[edit]

Quasar has mentioned some frustration on IRC a few times about the lack of active wikis for Quake. There are multiple, with varying degrees of scope (whole series, or just a single game), and none with a strong community to maintain them. There are even examples of id games without even as much popularity of that (for example: Rage) with very little hope of an independent wiki to spring around them. I just started thinking today, that it might not be the worst idea for us to expand out. Two possible solutions to this might be:

  • Changing the current wiki's scope to be inclusive of all id games, and some decisions would need to be made about how far that scope goes. I've had a short debate with Quasar on IRC about whether all id Tech 4 games might be included, being as relatively uncommon outside of id as id Tech 1 was. I believe everyone might agree that all the in-between engines were too popular to ever have the same focus (all Valve games, Call of Duty games, Ion Storm games, etc). This option would probably entail a branding change so that Doom is no longer the primary focus (side benefit: better results on Google? It could also be worse). It would even allow direct linking from topics such as all the engine articles.
  • A new network of inter-connected wikis, likely on MancuNET, where each game or series is maintained independently. This would allow the Doom Wiki to maintain the current branding, but we can still have a tight-knit community overseeing all the wikis, and still avoid the awkward link to id Tech 5 on Wikipedia when the Doom Wiki talks about id Tech 4 and 6. Questions might arise about which wiki certain articles should belong to. For example, would id Tech 4 be covered on the Doom Wiki, Quake Wiki, a meta-id-Tech Wiki, all/some of them? There are good arguments for all these options. We still would have branding issues: multiple Quake Wikis already exist in the wild. Perhaps we could get a consensus to fold them into our network, and reuse existing content?

I realize this is a bit of pie-in-the-sky thinking, but I'm not convinced of them being bad ideas. A very large disadvantage is that our current community is heavily focused on Doom, but I do believe we have a good overlap for fans of id Software in general, and we might be able to make such a thing work. All positive, negative, and alternative opinions on this are appreciated! --Chungy (talk) 18:37, 13 May 2016 (CDT)

IF we were to go that direction in the future, and I think there are higher priority subprojects here that need to be taken care of first, then I'd be looking to do it in the wiki farm or network direction, and have a NIWA-style setup with a central superwiki and many sister wikis with specific areas of coverage. And as discussed on IRC, we would not be breaking up this one in any way - it would remain covering everything Doom, and everything on the id Tech 1 engine. --Quasar (talk) 11:22, 14 May 2016 (CDT)
The quake wiki situation isn't great, but the quake community is an active one, I'd suggest if you were serious about trying to provide this, start participating in that community and ask them what they want or think. The two most active places on the web are Quaddicted (which incorporates it's own tumble-weed wiki of sorts) and func_msgboard. Spirit (who hosts Quaddicted) is a fairly active archiver, web wrangler, etc. and is well worth talking to about this.
I agree with Quasar that this isn't our highest priority, but also, I'd rather see our own hosting situation be improved a little before considering cloning it, how quickly could we set up a new doomwiki host from scratch? where are our backups? how many people are backing up the public content via the API (perhaps 0?) -- Shambler (talk) 08:04, 17 October 2016 (CDT)

Why blaster pistol, when the game doesn't refer to it as such?[edit]

I may be wrong here, but I have not found any case where the pistol has been referred to as blaster pistol in the new Doom, so why is the article titled Blaster pistol?

Thanks. --SuperShotgunPenguin (talk) 10:06, 14 May 2016 (CDT)

An editor added it with that name, and believe it or not I don't have the game yet! All my PCs and my laptop are too outdated to run it all, so I'm flying blind off what I can scrounge up from videos, forum posts, news articles, etc. If the official name is simply "pistol" then we can rename it to that, or else let me know what the official codex entry for the weapon is called and that's what we'll use. The existing title can remain as a redirect if enough people are likely to think it's called that because of its similarity to the Quake series weapons. --Quasar (talk) 11:20, 14 May 2016 (CDT)

Proposal: more general monster article-top disambiguator/navigational template[edit]

For the monster from Heretic, see Gargoyle. For other games, see:

The above is an example of a proposed replacement for Doom 3 also in and Doom 3 remake. Please provide input on the idea. It will allow linking to any increasing amount of monster(s) in the future if more games appear, without being as verbose as the current templates would be if they were to be chained, stacked, or wordily extended to be able to include the new Doom. --Quasar (talk) 22:49, 14 May 2016 (CDT)

I agree to this and have thought about this myself. It is a lot easier for navigation but the current one may be more user friendly and is, I believe, a convention in wikis. --SuperShotgunPenguin (talk) 14:42, 15 May 2016 (CDT)
Rather than duplicating the monster name, what about only the name of the game? Eg: Other incarnations of this monster: Doom 3Doom (2016) --Chungy (talk) 19:07, 15 May 2016 (CDT)
I was trying to avoid losing a lot of links to the game articles but I suppose it's not a big deal. However, if we were going to do that, I'd actually just prefer to drop the description parameters and have something like this: Other incarnations of this monster: Imp (Doom 3)Imp (Doom 2016) - Now you can see both the monster name and the game it is for w/o repeated hyperlinks getting in the way. Note this won't always be strictly repetitive - the new arch-vile equivalent in Doom 2016 is called the Summoner (and was still called the Arch-vile as late as the beta). --Quasar (talk) 10:19, 16 May 2016 (CDT)
Makes sense. What about monsters (or things, more generally) that have the same name but aren't different incarnations of the same concept? E.g. the Heretic gargoyle is also sometimes called an imp, the stalker could refer to Hexen's swamp dwellers or Strife's spider drones, the bishop can be the Strife boss or the Hexen mook, etc. --Gez (talk) 11:45, 16 May 2016 (CDT)
That's a problem I didn't think about and thus didn't set out to solve. The template could be given an extra disambiguation parameter which would handle current cases where this matters (there will never be sequels to Heretic/Hexen/Strife with any likelihood, so there's nothing to link to for other "incarnations" of those creatures). But if it becomes necessary in the future to have two- or three-way disambiguation, this template can't possibly handle such cases. There would either have to be a different template, two templates, or the special-case text would have to be entered directly into the article. --Quasar (talk) 12:24, 16 May 2016 (CDT)
Heretic got a sequel (archived 🏛) and Hexen a sequel (archived 🏛) with an expansion (archived 🏛), but all Quake (II)-engine based. Anyway, I found your initial template not very clear, the bullet doesn't provide enough separation between the groups of hyperlinks, but your latest simplified version looks clean. --Xymph (talk) 14:27, 16 May 2016 (CDT)
(Unindenting a bit) You're right, of course, but I meant ones we would have scope to cover here ;) For that to be the case they'd have to be based on id Tech 1, unless we changed our stance toward the existing ones. I'll go ahead and revise the template to adhere to the above suggestions and we can go from there. --Quasar (talk) 15:07, 16 May 2016 (CDT)
Thanks to lack of input this was never carried forward and now we have work being done that is going against the ideas presented here. We need to finalize these plans now. --Quasar (talk) 17:19, 19 October 2016 (CDT)

are Possessed Soldiers separate enemies from the Possessed or not.[edit]

I understand that as the game has just been released, it will take a while to update and create articles but one thing that was bothering me, and depressingly I have nothing else to worry about, is whether the various types of possessed enemies (possessed soldiers, guards etc.) should have their own links on the Doom (2016) monsters template, or be linked under a general article of "The Possessed" like the Zombies from Doom 3. the codex entries count them as different, but the Monsters section on the Doom (2016) article links them underneath. --SuperShotgunPenguin (talk) 14:31, 15 May 2016 (CDT)

It'd help me make my mind up if I could even find a comprehensive list of the subtypes anywhere and a description of their behaviors. The current vacuum of details on the games' monsters is pathetic. --Quasar (talk) 16:04, 15 May 2016 (CDT)
Seeing as this wiki is using the codex entries for naming like "Combat shotgun" over just "Shotgun" and "Pistol" over "Blaster pistol", I thing that we should follow this all the way and have each codex entry as a seperate type and have no subtypes, it would result in a lot of links on the Doom (2016) Monsters template but it would settle this issue. Any other ideas? --SuperShotgunPenguin (talk) 16:18, 16 May 2016 (CDT)
Just to clear this up, I know enough about the game now to see how different the various possessed subtypes are and I do agree they should have their own articles, as they're at least as different as the zombieman, shotgun guy, and chaingunner of the original series, or zombies vs zsecs vs commandos in Doom 3. They're not just minor variants like "possessed swinging a wrench" or "possessed with slightly different texturing," like most of the Doom 3 zombie subtypes were. --Quasar (talk) 18:36, 11 June 2016 (CDT)

Doom 2016 Screenshots![edit]

I captured some screenshots last night from the new doom for doom wiki. They may be useful, may be not:

Hope this helps for article creations. —The preceding unsigned comment was added by SuperShotgunPenguin (talkcontribs) .

YouTube embedding change[edit]

YouTube is now requiring a minimum size of 480x270 for video embeds.[4] If you ask me, it's a little bit large but, without it, the player now needlessly disables both the volume control and the time progress indicator. This is bad for the end user so having the larger videos will have to do for now. --Quasar (talk) 10:29, 21 May 2016 (CDT)

Idgames template zoo[edit]

I have deprecated {{ig2}} and its umpteen aliases because they only allow linking by id, which is a practice we need to discontinue. These IDs are volatile; if a file is deleted from the database, it is not possible to figure out what file it was actually pointing to as that row will be physically removed from the Doomworld DB. There has been discussion in the past about the entire series of IDs being volatile in addition, such that if the DB had to be rebuilt from scratch in case of a disaster by scanning /idgames anew, the IDs would come out totally different, scrambling every single link to them in a debacle similar to what happened when AtomicGamer changed their file layout. Likewise, I have deprecated the id argument to the suggested replacement {{idgames}} template. We need to re-evaluate the entire set of these idgames templates as there are, I feel, too many options. I never know which one(s) to use in any situation and always have to open them all up to find the correct one. --Quasar (talk) 16:04, 10 June 2016 (CDT)

Having experienced the same, I fully agree the zoo needs to be cleaned out. --Xymph (talk) 16:21, 10 June 2016 (CDT)

Doom canon storyline[edit]

OK, so I'm over obsessive with the canon of any fictional series, and no more so with Doom. Does this wiki define a canon story line and if so what is it. e.g. are Doom 3 and 2016 part of the same universe as the original games. If it does not have a canon storyline, then this wiki needs to make it obvious and clear that there is no canon, Thanks. —Preceding unsigned comment added by 86.158.175.137 (talk) 13:01, 18 July 2016 (CDT)

Our job is to objectively interpret the games as they present themselves and not to draw any unwarranted or unsupported conclusions or connections that are not widely considered to exist or to be obvious by community standards. It is unknown if Doom 3 and Doom 2016 have a canonical connection. There are only subtle hints in the latter game itself that there could be one, and these could have easily just been intended as easter eggs by the developers. Without "Word of God" from the devs on the issue, we must simply report the existence of those items and the possibilities of what they represent (ie., both viewpoints - that they may indicate a connection, or that they are there just "for fun" to remind the fans about the previous entries in the series). Unsupported speculation is regularly removed and reverted from articles here, and on the whole we maintain a particularly high encyclopedic standard for our content. Fan fiction is never acceptable beyond articles about notable fan fiction works written from a real-world context. --Quasar (talk) 13:29, 18 July 2016 (CDT)
Is there any confirmed canon? —Preceding unsigned comment added by 86.158.175.137 (talk) 13:31, 18 July 2016 (CDT)
Not beyond individual sub-series. Ie., amongst official products, Doom II follows Ultimate Doom (with some retcons involved), and No Rest for the Living, Final Doom, and Doom 64 follow Doom II (in what order or combination they are co-canonical is unspecified and unknown). Doom II RPG makes references to some other games in the series, and also to Wolfenstein RPG, but I am not terribly familiar with it so I cannot speak about them in detail. In the Doom 3 timeline, Doom 3 happens first, at the same time as The Lost Mission and Doom Resurrection; Resurrection of Evil happens 2 years after it. There are again only easter egg like references to the original series at best in Doom 3, such as the appearance of the ancient civilization's hero resembling the original Doom marine (and therefore also bearing heavy resemblence to the artwork in Doom 2016 showing a similar hero fighting the same kind of demons yet again, but with his bare hands versus the Soul Cube). Beyond these sub-series, any firm connections are mostly conjectural. --Quasar (talk) 13:40, 18 July 2016 (CDT)

Thing data tables[edit]

While waiting for feedback on DMMPST development – as I am now, Gez and Quasar ;) – I've been updating and adding Thing data tables for items, weapons and monsters. Three details I'm wondering about:

  1. Monsters are normally shown with a Width attribute, e.g. Imp; the others with Radius, e.g. Backpack. Why the difference? It can lead to mixups, i.e. the Imp's projectile is listed with width 6, but that is actually the radius value and its width should be 12. The same goes for other monster's projectiles.
    I believe DeHackEd was used to attain the values, and that may be (part of) the source for the mixups, as the value 16 that it shows is indeed a radius, mislabeled as width. Confusion about that seems to be nearly as old as this wiki (first sentence).
    The game internally defines everything by radius. Wouldn't it be more clear and consistent if Thing tables all use the same attribute, and if so, which one?
  2. Monster tables include a Bits value in decimal and a list of bits composing that value, copied directly from DeHackEd. The source code calls these Flags, which I find a better description, especially since Heretic, Hexen and Strife have two sets of them. Also, the decimal value does nothing to help understand how the field is composed, using hex (8 digits with leading zeroes) would make those one or two fields much clearer. Are there objections against changing these two aspects?
  3. For weapons, how is "Shots per minute" determined?

Background: While working on the item and ammo tables, most of the data could fairly readily be obtained from the source code's info.c. For weapons and monsters the ZDoom wiki also proved most useful, but altogether the process became rather time-consuming and error-prone. Also, at first it wasn't clear to me how some values (such as monster speeds per second) were obtained, so I needed to dig deeper. Therefore, rather than using an indirect approach like DeHackEd's, I created a C program built together with info.c (and as many Doom .c and .h files as needed to make it compile) that directly extracts information from the mobjinfo, state, sprite and sound tables. I'm planning similar tools for Heretic, Hexen and Strife. The output is in plain text and not in wiki-table format as some attributes (like damage formulas) cannot be obtained this way, but that serves well enough to double-check (and correct, if needed) all Thing data tables in the long run. --Xymph (talk) 15:30, 29 August 2016 (CDT)

Vanilla Strife does not have two flag bitfields. Be sure you are not looking at the Strife: Veteran Edition source code, because we added a flags2 field in that port to support some new internal features we needed. Chocolate Strife is the appropriate point of reference. --Quasar (talk) 13:41, 1 September 2016 (CDT)
Thanks for the heads-up. I went for the latest-version approach, but reverted to the chocolate codebase now. For the other three games I'm using the original, vanilla codebases.
Given that this is your only feedback, I'll take it that you're okay with whatever the outcome of #1 above (I'm choosing Radius), and with "no" to #2. --Xymph (talk) 15:46, 1 September 2016 (CDT)
I didn't really have time to review the whole thing earlier to be honest but, I think selecting radius is the best, yes, as those values are what you'll find in the code and can be double-checked by anybody at a glance w/o having to be doubled. The original logic behind decimal flags values is because of how DeHackEd displayed them, yes. I would rather have the value in both bases, honestly, if it's practical, but I'm not sure w/o seeing it in an expansion. --Quasar (talk) 16:46, 1 September 2016 (CDT)
I made the first data table edit based on the above choices, please check out its Flags representation. I put hex first because that makes sense there, but then this field uses the reverse order of the ID# field (where decimal makes sense to go first). Not really happy with that, my solution would be to just drop the Flags decimal value. Any other suggestions?
I also moved up Mass below the other physical characteristics – it probably was below the pain attributes only because DeHackEd ordered them that way. And reaction time needed its unit. --Xymph (talk) 07:38, 13 September 2016 (CDT)
Looking at it, I think "ID #" ought to be renamed to something more accurate, like "Editor number". Maybe it's just me but to me the ID would be the thing's order in the mobj class table (for which there are enum constants such as MT_CYBORG in the source code). Dehacked also refers to thing types by that same number (e.g. the lost soul in Dehacked is "Thing 116"). ID is just too generic and ambiguous, whereas "editor number" is clear that it's the value that matters in the editor. --Gez (talk) 08:01, 13 September 2016 (CDT)
Most other data tables use "Thing type" for that field, and this inconsistency and "ID #" being too vague have been bugging me too. Using "Thing type" for monsters would be practical – for avoid having to update the field name in all the item tables – but "Editor number" is indeed the most accurate name.
Regarding the hex/dec Flags, Jon suggested on IRC to use "some wizzy javascript" to allow users to toggle the Flags representation. I'm not fond of adding that kind of complexity for a relatively minor bit of info. While much of the complexity can probably be cornered into a template, some visual cue needs to be added to the field to show the user that the value can be toggled, and such that it looks good in all skins. Additionally, we already know from the maptabs template that such things are tricky to get working on mobile.
The only minor benefit I see in keeping decimal Flag values around at all is to allow users to compare them to DeHackEd's output, but that tool should never have used such an impractical representation in the first place, IMHO, and I see little reason to keep accommodating that. --Xymph (talk) 09:29, 16 September 2016 (CDT)
After further thought about that ID# field, "type" is also how it's called on the Thing page and in the mapthing_t structs in the source code. Together with the practical benefit of not having to edit-for-consistency most weapon/ammo/item tables, I think "Thing type" is good enough a description for monster tables too.--Xymph (talk) 07:20, 19 September 2016 (CDT)
#1: yes, go with radius. #2: hexadecimal is certainly more useful and should be prioritized. #3 I suppose it has to be extrapolated from the refire delay in tics between two shots with the weapon and knowing there are 2100 (35*60) tics in one minute. For example if you hold fire with the pistol, it shoots every 14 tics (first time 4 tics in the fire animation, then another ten tics before looping back to the beginning of the animation if you hold fire). 2100/14=150, and the pistol article says 150.0 shots per minute. QED. --Gez (talk) 18:43, 1 September 2016 (CDT)
Wow, another great idea.  IIRC you should be able to get damage ranges by including the attack functions and P_Random() (easy for me to say of course!).  Ambiguity arises only when damage is not completely calculated within one tic, e.g. a BFG hit.
Shots per minute was determined by manually stepping through attack sequences to count how many tics constituted a complete loop.  Gez has described what we were aiming for, but there were cases when two editors obtained different results, so for all I know there is some interpretation involved.  I believed that monsters should have values also (including stochastically computed rates for attacks that don't loop, e.g. zombieman or mancubus), but that research remains incomplete.  HTH.    Ryan W (usually gone) 19:23, 1 September 2016 (CDT)
For monsters, it's a fool's errand, it's random and depends on far too many external factors (notably skill level and distance between monster and target) to be be easily and meaningfully translated into a rate of fire statistics. --Gez (talk) 06:06, 2 September 2016 (CDT)
Thanks for your inputs. I implemented Shots/Min calculations for Doom and Heretic, and for some weapons the attack cycle is a little more complex than the pistol. For starters, if the "fire" action function is called twice during the cycle – like for chainsaw and chaingun – the firing rate is doubled, which is logical. Also, it appears that the tics specified for the final attack state, which invokes the A_ReFire action function, are not included in the cycle. After coding on that assumption, my calculations return the same numbers as listed in the wiki for all Doom weapons. For Heretic, I got different numbers for some of the weapons until I realized that a refiring cycle starts at the weaponinfo's holdatkstate rather than atkstate.
As for including and invoking the attack functions themselves to collect even more information than just from the tables, that seems a big stretch due to the wide variety of activity undertaken in them and the number of other functions they invoke in turn, which would need to be stubbed somehow. And that still wouldn't allow determining damage formulas for weapons in a reasonably convenient manner (if at all). --Xymph (talk) 16:47, 5 September 2016 (CDT)
Yes, the tics specified for the state which calls A_Refire do not matter if you hold fire. Here's the thing about state functions -- they're called whenever the actor enters the state (so they're called at tic 0 of the state). This has an interesting corollary that if a state isn't entered, the function isn't called. This may seem obvious, but when actors are spawned, they're spawned directly into their spawn state, in other word, they do not enter it, so actors never perform the function of their spawn state when they are spawned. (If they later loop back to their spawn state for any reason, they'll run the action normally of course.)
Anyway, the A_Refire action is simple: if the player is holding fire, jump back to the Fire state. Otherwise, do nothing. So if the player is holding fire, the weapon immediately jumps back to the fire state, and the state calling A_Refire is exited instantly, lasting a total length of 0 tics. If the player isn't holding fire, the weapon doesn't do anything special and the state runs for its normal duration before being followed by the next state. This is true of all functions performing a state jump, including those added by MBF or ZDoom. --Gez (talk) 17:55, 5 September 2016 (CDT)
Thanks for further clarification. --Xymph (talk) 07:38, 13 September 2016 (CDT)

Unindenting for new sub-topic:
The descriptions of Thing flags in the wiki, typically only listed for monsters, were probably taken from DeHackEd. But after comparing those to their enum names and comments in the source code, I sometimes found the original descriptions inaccurate, and came up with new/changed ones for my DMINFO & HTINFO tools (work on their Hexen and Strife siblings hasn't begun yet). Here are tables of the old and new descriptions – when making my next update/addition sweep over all thing data tables, I intend to use the latter. Feedback on the choice of words, upper/lowercasing, etc. before that happens is welcome. --Xymph (talk) 07:20, 19 September 2016 (CDT)

Assuming this didn't significantly progress w/o feedback already, I'd prefer for "Sentence casing" to be used, as that is our typical style for everything. --Quasar (talk) 08:06, 17 October 2016 (CDT)
Fine, done. I considered Mobj a proper noun (for this list anyway) and kept that capitalized, along with first words inside parentheses (for legibility).
And no, little progress was made here as DMMPST and the bot scripts kept me plenty busy. :) --Xymph (talk) 08:56, 17 October 2016 (CDT)
Note that we have an article for mobj so it should be linked. --Gez (talk) 09:07, 17 October 2016 (CDT)
Good point, then I lowercased it as well. --Xymph (talk) 09:38, 17 October 2016 (CDT)

Map thumbnail dimensions[edit]

Yes, another new topic. :) A bot script in development to address the issue of replacing map caption strings can also update the thumbnail dimensions. The default width is 300px but different widths are in use on quite a few map pages. Sometimes they allow a thumb to fit into a page better, sometimes they vastly under-size or over-size the image, leading to very unbalanced pages. I've explored an approach that aims to result in a reasonably consistent user perception of map thumbnails. The algorithmic approach can be added to the script soon, and then rolled out – eventually – on all map page series. Two questions remain:

  1. Is there a reason not to apply this approach?
  2. What would be a suitable upper limit (in px) for width, height, or both? I'm undecided between 360 and 390px.

--Xymph (talk) 07:45, 24 October 2016 (CDT)

  1. Evidently not. :)
  2. I decided on max. 360px for landscape and max. 390px for portrait, because the former affect the visual top-down flow of a map page more (narrowing down the neighboring paragraph) than the latter (side-barring along multiple paragraphs).
--Xymph (talk) 10:24, 31 October 2016 (CDT)
Thumbnail dimensions for stock levels (and some two dozen megawads) have now been standardized as above using a script and my bot account (and occasional manual edits). More mega/pwads to follow as time permits. --Xymph (talk) 06:57, 6 November 2016 (CST)

Attack of the robotic fans[edit]

Three times now we've had this page blanked by weird spambots who seek to compliment our "blog" and its "disallowed style" or some other random nonsense. Should we protect the page? --Gez (talk) 08:08, 14 November 2016 (CST)

Given this is supposed to be the main discussion portal, including for anons, that's a difficult sell. I am not sure how these are getting past all of the AbuseFilter rules. --Quasar (talk) 09:03, 14 November 2016 (CST)
Indeed.  I take it that bots haven't learned how to confirm edits (i.e. the blanking filter only warns and tags)?    Ryan W (usually gone) 10:50, 14 November 2016 (CST)
Some do but most don't - most assume the successful HTTP submit action is evidence that they spammed and they immediately move on to their next victim. --Quasar (talk) 11:01, 14 November 2016 (CST)
For whatever reason the blanking filter was restricted to main space. I have removed that. --Quasar (talk) 09:40, 14 November 2016 (CST)
This page should stay the way it is. It is relatively easy to revert whatever crap someone replaced it with. Plus, it's only been what? Three times? If it keeps happening throughout the month, then I suppose some kind of protection should be added. --Voros (talk) 10:25, 14 November 2016 (CST)

Map view licenses[edit]

Taking it here from IRC. Map view templates exist for Doom-series games (-doom), other commercial games (-comm) and user PWADs (-pwad and friends). What should be used (or newly created) for commercial PWADs like The Lost Episodes of Doom and the Wraith sets (Hell To Pay and Perdition's Gate)? --Xymph (talk) 13:00, 14 November 2016 (CST)

Don't we discourage "newly created" because the upload form is already bloated and confusing enough?  :>   (That said, I doubt we foresaw this situation in 2007.)  The number of such WADs is low enough that I hope we can make do with wording tweaks in the existing templates, at most.
I personally am most interested in long-term maintainability.  A community-based developer might relicense the work later, including shovelware distributed without permission; a commercial publisher (especially if defunct) almost never does; and Bethesda will continue to be their warm and fuzzy selves.  Therefore, three possible tags: 1 2 3.  Does that make any sense?    Ryan W (usually gone) 19:30, 14 November 2016 (CST)

MAP10 or MAP11 for episode 1 templates?[edit]

We have a proposal to standardize some map navboxes using automated edits.  Among other things, this means deciding how many maps are in "episode 1" of Doom II-like WADs.

I always thought MAP11 was widely accepted in the Doom community, as implied here, because of the sky textures and text screens.  Yet, our contributors have independently created templates both ways, as the above category shows.  Previous on-wiki discussion ranges from halfhearted to nonexistent ( 1 2 3 ).  My own mass edits unfortunately used MAP10 simply to follow the majority of existing templates; in hindsight I should have created this thread first.

If navboxes have small links to all levels at the bottom (which I think is our consensus), then the impact to readers is quite minor either way.  I can speculate that MAP10 may have been used a decade ago for ease of typesetting, to keep the three longest templates the same size.  That kind of effort is well-intentioned but pointless IMO, due to the huge variety of screen/window dimensions and skin settings.  If the in-game experience indicates MAP11, we should use MAP11.

Presumably the bot could skip "ultramodern" cases such as hubs or script-based navigation, which may redefine episodes or allow more than 30 non-secret maps.

Ideas, opinions, flames?    Ryan W (usually gone) 14:43, 24 November 2016 (CST)

Thanks for the round-up. The modern case is indeed what I was wondering about: do such Doom II megawads still follow the sky-based episode model? If those instead allow to define any sky with any map, then it seems to me that those navboxes are best organized by the default 10/10/10/2+ maps grouping. Either way, the bot script hasn't been written yet pending input on this and the other topic, so I don't know yet how to deal with this automatically or with manual input. --Xymph (talk) 04:36, 25 November 2016 (CST)
I'd say use the episode approach generally (1-11), but keep in mind exceptions for wads that use different episodes (e.g. Scythe uses 10-level episodes, its sequels use 5-level episodes; wads such as Valiant and Ancient Aliens even use MAPINFO to separate episodes in supporting ports). Map compilations with no real episode or storytelling thematic can also be split in even-sized chunks for convenience (e.g. any sort of mapset made for multiplayer competition). Basically my idea is to go with "whatever makes the most sense in this case" rather than a robotic, one-size-fits-all approach. --Gez (talk) 08:24, 25 November 2016 (CST)
I agree that wiki info should reflect the source material as accurately and completely as feasible. That means the bot script to create navboxes may become more complex, so I'll have to see how far I can take that. Parsing MAPINFO would probably be a bridge too far, but I can work off the info on the WAD's overview page. So for 5-10 level episodes, that would imply more but shorter navboxes – but how should the other maps & episodes be represented? Ah, that's already being discussed elsewhere.
Reminder to all interested editors: please comment on the font size topic as well. --Xymph (talk) 07:03, 28 November 2016 (CST)
Most existing DoomII-type navboxes have now been updated to the standard sky-based MAP grouping (unless a different episodic grouping is dictated by the source material), therefore this topic has been wrapped up. --Xymph (talk) 15:27, 27 January 2017 (CST)

Editdoom x wads x new players[edit]

A long time ago I used Editdoom to edit fazes (WAD) of the game Doom and shared with friends. Today I am returning to this fun and I would like to know if this is currently used, which version is the best and has been interested in this practice. Thank you, awaiting —The preceding unsigned comment was added by Webdantas (talkcontribs) 22:54, 27 November 2016.

I've never heard of something called "editdoom". I can only suggest taking a look at SLADE 3 and GZDoom Builder. --Gez (talk) 05:32, 28 November 2016 (CST)

Affiliation disclaimer[edit]

I think in light of recent events that we're not going to be able to avoid having a visible disclaimer somewhere specifically stating that we are not affiliated with nor endorsed by ZeniMax, Bethesda, or id Software. Suggestions on how to incorporate this into the site w/o it being an obnoxious element will be appreciated. --Quasar (talk) 09:33, 2 December 2016 (CST)

We already have a link to that in the footer on every page, just not with Monaco for some reason.  Hmm, maybe this should be mentioned in the terms of use also?    Ryan W (usually gone) 11:19, 2 December 2016 (CST)
The DoomRL tweet mentions non-visible content such as meta keywords.  Would an HTML comment be a good idea too?    Ryan W (usually gone) 11:34, 2 December 2016 (CST)
I am afraid that a below-the-break link that requires a click doesn't probably meet the standard. --Quasar (talk) 11:59, 2 December 2016 (CST)

Navboxes wrap-up[edit]

In recent months several aspects of navboxes for map pages were discussed:

  1. Font sizes of header, map names, and numbered 'other' maps on desktop and mobile
  2. Grouping classic Doom II-megawad maps by sky-based episodes
  3. Organizing 'other' maps for modern episodic Doom II-megawad maps

This new topic aims to tie up these topics and any loose ends.

I've written a new script to generate various types of navboxes that takes the outcome (if any) of the above topics, and further brainstorming on IRC, into account. Its results are sandboxed here. They use the CSS class dw-navvariable and family that Quasar recently created as per topic #1.

The main differences to current navbox styles are:

  1. The header ("<wad name> levels") is in normal font, not 'larger' (see C, E, J).
  2. Names for Doom(1)-style episodes have remained in normal font (see E).
  3. The active list of named maps is in 'smaller' font on desktop but 'normal' on mobile (all).
  4. The classic Doom II-type area of other, numbered maps uses a different background than the active list (see G, H, I).
  5. For modern episodic Doom II series (see J):
    1. the episode names aren't linked to another template;
    2. the active episode name uses normal font and the other ones are 'smaller';
    3. the episodes have separator bars (Quasar's suggestion);
    4. the maps in the other episodes are included as 'smaller' numbers for quick navigation as per topic #3.

Some layout details are still controlled in style divs but can be moved to the CSS files once sufficient consensus has been reached. So, does anyone object to the structuring and styling of all these types of navboxes? And if so, what would you suggest to change?

A new idea: for Doom(1)/Heretic multi-episode navboxes, a single line of small map numbers could be added to the non-active episodes to allow quick navigation, just like for Doom II style boxes (item 5.4). I.e. "E1M 1 2 3 ... 9" or "E1 M1 M2 M3 ... M9". Would that meet with approval or opposition?

Once that's settled, I will regenerate all existing Doom/Doom II/Heretic navboxes using these styles. Per topic #2 the existing 01-10 / 11-20 boxes can also be regenerated as 01-11 / 12-20 boxes unless the megawad explicitly specifies another grouping. (The existing navbotBot.php script can then apply the renamed boxes to the 20 pertaining map pages.) Are there objections to that?

Finally, two nitty-gritty details:

  1. In the header of existing navboxes sometimes the word "levels" is used (A-D, G) and sometimes "maps" (E-F, H-J); and the same inconsistency happens in reference to Secret map(s)/level(s). I propose to use "levels" - okay?
  2. On map pages the navbox can be placed above or below the {{map|}} template, which affects their relative alignment and whether or not the slot description line wraps next to the navbox in narrow(er) windows. What would be the preferred template order?

A final observation: the generated navboxes can of course be manually adjusted afterwards, like the Obituary one. --Xymph (talk) 13:46, 21 December 2016 (CST)

Some opinions:
  • For Ult. Doom and Heretic, I'd be in favor of just listing the other episode maps as M1, M2, M3, etc. The E1 part is kinda redundant with the episode name being just above.
  • Map vs level? I'd be more in favor of "map" because it's shorter and I think more generally used than "level" in the Doom community. Though it seems this wiki has chosen level and level editor, but then again it's not entirely consistent since we have things like Category:PWADs with maps and Category:Map views. No strong opinion either way but the map slots themselves are clearly called MAPxy or ExMy; not LEVELxy or ExLy.
  • Template order: I think Hell Keep looks better than Foray, so I'd say above.
  • Other points: no real idea right now. --Gez (talk) 16:52, 21 December 2016 (CST)
  • Listing other episode maps, agreed: see E1-E3 in the current sandbox.
  • Sometimes the longer "levels" helps to beef up the box a bit (e.g. Galaxia), and level is indeed a reason why I proposed to use that, but usually a long wad name makes the shorter "maps" preferable, so I'm fine with that too. Of the existing navboxes, the vast majority already uses "Secret maps" (although Doom II is one of the exceptions).
  • Placing navbox above {{map|}}, agreed as well.
In the past two weeks Quasar and I worked on and off to tune the navbox styling of wikicode/HTML in tandem with CSS to look good and consistent on desktop and mobile. The current sandbox has the result, which will be final (and deployed to all existing Doom/Heretic navboxes in due course) unless additional suggestions are made over the next few days. --Xymph (talk) 12:27, 9 January 2017 (CST)

FWIW after the fact, endorsing these improvements, and applauding those who contributed ideas and effort (also see threads linked at the top).  I'm no graphic designer, and even if I were, the variety of browser configurations and display dimensions seems intractable.  Therefore, in a bot project, consistency is IMO a better investment than particular "parameter" choices.  It appears that consistency has been achieved, perhaps excepting edge cases that neither the bot nor anyone else remembers offhand.  :>

All that said, it is great that CSS changes were hashed out on behalf of mobile readers (probably everyone but me).  I also noticed how much better the navbox looks above the disambig template — why did I ever do it the other way [5]?

Apologies if I've missed any details, despite Xymph's thorough explanation, due to not reviewing every template update manually (tangent: I agree with some others that retrospective reading should be easier [6] [7]).    Ryan W (usually gone) 14:20, 4 March 2017 (CST)