Doom Wiki:Central Processing/2016

__NEWSECTIONLINK__

This is the central discussion forum for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads. For extended discussion on long-range "to do" issues and project planning, please also visit our Request For Comment hub.

Link archiving
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
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
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?
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...
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
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. --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
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: --Quasar (talk) 01:14, 3 March 2016 (CST)
 * 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.

Console map articles: going forward
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)

--Quasar (talk) 05:38, 17 March 2016 (CDT)
 * 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.


 * For the SNES case, Ledmeister seems to have them, 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
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?
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: Another used on E2M6 - E2M8, E3M1 - E3M9, E4M2 - E4M8 (and ditto D2 mishmash): 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)
 * 1) Walkthrough
 * 2) Essentials
 * 3) Other points of interest (optional)
 * 4) Secrets
 * 5) Bugs (optional)
 * 6) Demo files (optional)
 * 1) Strategy
 * 2) Walkthrough
 * 3) Other points of interest (optional)
 * 4) Secrets
 * 5) Bugs (optional)


 * 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?
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
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
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: 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)
 * Baron
 * Ogre
 * Bruiser Brothers
 * Barons


 * 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. .  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.      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?
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?
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)

Backups, dumps, archives, etc.
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 . 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
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 category and distribute them properly into  and. --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
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: Currently, my idea would be to list the table multiple times: 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 ∞.
 * 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)
 * 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)

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 &mdash; 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  with no discussion, so the "reasoning" was probably that some people like barrels.  (It happens .)  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)

New DOOM monsters
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:

--Quasar (talk) 11:20, 5 May 2016 (CDT)
 * 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.

Screenshot above the map: where?
The other day while making the Doom2 map update sweep, I noticed that three times a single screenshot was placed above the map, but in three different ways: 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)

Sticky wicket
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
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)

Why blaster pistol, when the game doesn't refer to it as such?
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
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 3 • Doom (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) &bull; 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 and Hexen a sequel with an expansion, 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)

are Possessed Soldiers separate enemies from the Possessed or not.
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)