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)

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)